Resources
Security & trust
This pillar translates the CSA AI Controls Matrix for an organisation that uses AI services without building them. It separates what you must do yourself (policy, inventory, oversight, training) from what you must require and check with your providers.
General recommendations: the assessment selects those that match your situation and ranks them by priority.
AI acceptable use
The first risk is not technical: it is employees pasting a contract, a customer file or source code into a public assistant. A short policy, known to everyone, that says which tools are authorised, with which data, and what is done with the results, covers the essentials.
What we recommend
- Write and circulate a one- to two-page AI acceptable use policy based on the template provided: authorised tools, prohibited data, mandatory human review, point of contact. Have it signed or acknowledged.
- Offer an approved alternative to consumer tools (an enterprise version of an assistant, with a guarantee that data is not reused) and communicate about it: it is the most effective way to reduce shadow AI.
- Set up a simple way to request approval for a new AI tool (form, ticket) with a committed response time, so that the official route is faster than working around it.
- Schedule the annual review of the policy in the governance calendar and include newly detected uses.
AI inventory
You cannot govern what you cannot see. A register of AI systems and uses — tool, provider, purpose, data processed, internal owner — is the foundation for everything else: AI Act compliance, cost control, incident response.
What we recommend
- Create the register of AI uses from the template provided: one line per tool or use, with provider, purpose, data processed, owner and risk level. Fill it in by asking each department (30 minutes per team is enough).
- Appoint a business owner for each use in the register and plan a six-monthly review (additions, discontinuations, changes of provider).
- For each application that includes AI, document its bill of materials (models, versions, external services, data sources) and require it from your providers at purchase and at each major update.
Data protection in AI use
What you send to an AI service may be stored, used to train the model, read by a subcontractor or hosted outside Europe. The issue is handled at three levels: what users are allowed to send, what you negotiate with the provider, and what you do with production data in projects.
What we recommend
- For each tool in the register, fill in three columns: data retention, reuse for training (yes / no / can be disabled), hosting location. Switch to enterprise offers where the answer is unfavourable.
- Complete the GDPR record with processing that involves AI and check that a data processing agreement is signed with each provider concerned. Use the provider checklist provided.
- Carry out a data protection impact assessment (DPIA) for AI uses that process sensitive data, using the CNIL guidance. With support, it can be completed in a few days.
- Set a simple rule for projects: no production data in development without the data owner's approval and without pseudonymisation; provide dedicated test datasets.
Pre-deployment impact assessment
Before enabling an AI feature in business software or launching a project, a proportionate assessment (who it is for, what data, what risks of error, what obligations) avoids unpleasant surprises. The AI Act makes it mandatory for high-risk uses; the AICM recommends it for all.
What we recommend
- Adopt the one-page AI use assessment grid provided as a mandatory step before any go-live, and apply it retroactively to the most sensitive uses already in place.
- For uses that are high-risk under the AI Act, conduct a structured impact assessment (fundamental rights, ISO/IEC 42005) before the 2 December 2027 deadline. It is an exercise that benefits from being scoped by a specialist the first time.
- Include an AI threat analysis (OWASP Top 10 for LLM Applications style method) in the design of every project that integrates a model, and repeat it at each major change.
Human oversight
When AI influences a decision about a person (candidate, customer, patient, student), someone must be able to understand, challenge and correct it. This is not only a requirement of the AI Act and the GDPR: it is what protects the organisation when the model gets it wrong.
What we recommend
- List the decisions concerned and define for each: who approves, on what criteria, and how the approval is recorded. Use the oversight matrix provided.
- Add to communications with the people concerned (candidates, customers) a mention that AI is involved and a simple way to request a human review.
- Define a policy of authorised actions for each agent (allow list, caps, human approval above a threshold) and enforce it technically, not just by instruction.
Bias and fairness
A model that sorts CVs or scores customers can reproduce past discrimination without anyone intending it. The customer of the service bears the legal responsibility. So you need to ask the provider what it has tested, and check for yourself on your own cases.
What we recommend
- Ask the provider for its fairness testing documentation (questions provided) and keep the answer in the file for that use.
- Set up a simple quarterly review of outcomes by group of people with an alert threshold; commission an independent fairness audit for the most sensitive uses (recruitment, credit).
Explainability and transparency
Being able to explain why the tool produced a given result is necessary to answer a customer, an employee, an auditor or a judge. The expected level of explanation must be defined in advance and required from the provider.
What we recommend
- Check and correct user information within 30 days: a visible notice on chatbots and voice assistants, labelling of generated content that is published. This obligation is already in force.
- Require a model card or system card from each provider and file it with the register of uses; for sensitive uses, set out the expected level of explanation in the contract.
Governance and accountability
Someone must be accountable for AI in the organisation: deciding on requests, tracking risks, reporting to management. In an SME it is a designated lead; in a mid-sized company, a committee bringing together business units, IT, legal and HR.
What we recommend
- Appoint an AI lead with a one-page mandate (role, scope, time allocated, reporting line) and have management announce it.
- Create a cross-functional AI committee (or add an AI item to an existing committee) with terms of reference, a quarterly schedule and a decision log.
- Have management set out a one-page AI policy: ambitions, red lines, risk appetite, principles (transparency, human oversight, data protection). A two-hour workshop is usually enough.
AI literacy and training
Since February 2025, the AI Act has required staff who use AI systems to have a sufficient level of AI literacy. Beyond the obligation, it is the most cost-effective measure: a trained employee does not paste confidential data into a public tool and can spot a wrong answer.
What we recommend
- Roll out a 45-minute awareness session for all users based on the material provided, and keep a record (attendance list): this is the evidence expected under Article 4 of the AI Act.
- Build a training plan by audience (everyone, exposed roles, developers, management, decision reviewers) with annual refreshers.
AI supplier requirements
Most of the AICM's 247 controls are carried by your providers. Your role is to ask them the right questions before buying, obtain written commitments and check periodically. The CSA's STAR for AI registry publishes some providers' self-assessments (AI-CAIQ): it is a free and valuable source.
What we recommend
- Adopt the AI provider questionnaire provided (20 questions derived from the AICM) as a mandatory step before any purchase; send it retroactively to your three most critical providers.
- Include a set of AI clauses in your contracts and purchasing terms (data, location, incidents, reversibility, model changes, subcontractors); have a lawyer review them the first time.
- Check the CSA STAR for AI registry for your main providers and ask those that are not listed to complete an AI-CAIQ or equivalent.
- For each integrated AI service, define a fallback plan (degraded mode without AI, alternative provider, data export) and test it once a year.
Identity, access and endpoints
AI services are applications like any other: named accounts, strong authentication, access removed when people leave, no uncontrolled browser extensions. These rules probably already exist in your organisation; the point is to apply them to AI tools too.
What we recommend
- Connect approved AI tools to your directory (SSO) and include their removal in the leavers' process; prohibit free accounts created with a work email address.
- Draw up a list of authorised AI extensions and applications on workstations and enforce it through your device management tool where possible.
Logging and monitoring of AI use
For your own applications that integrate a model, you must be able to answer after the fact “who asked what, and what did the system reply”. This is the basis for investigating an incident, detecting misuse and proving human oversight.
What we recommend
- Enable and review quarterly the usage logs in the admin consoles of your AI services (active users, volumes, features used): they are also a source for tracking costs.
- Systematically log, for each in-house AI application, requests, responses, user ID, model version and timestamp, with a defined retention period and restricted access.
- Define a few anomaly indicators (volume per user, injection patterns, outputs containing sensitive data) and connect them to your existing monitoring.
Guardrails and AI application security
An application that connects a model to your data and your users is exposed to AI-specific attacks: prompt injection, data extraction through the model, bypassing of instructions. Technical guardrails and regular testing are needed.
What we recommend
- Put input and output guardrails in place (validation, filtering, separation of instructions and data, limits on actions) for every application that integrates a model, based on the ANSSI recommendations and the OWASP LLM Top 10.
- Apply the principle of least privilege to the model: document searches respect the user's permissions, no secrets in system prompts, isolated test environments.
- Include AI scenarios in your annual penetration tests and organise a red-teaming exercise on the most exposed application.
Autonomous AI agents
An agent that sends emails, changes data or triggers payments needs explicit boundaries: what it is allowed to do, with which accounts, up to what amount, and what requires a human.
What we recommend
- For each agent in service, write a boundaries sheet (mission, accounts used, authorised actions, caps, required human approvals, shutdown procedure) and enforce it technically.
- Log all agent actions with the ability to undo them; appoint someone responsible for monitoring and test the emergency shutdown procedure.
AI incidents and resilience
A data leak through an assistant, a wrong answer sent to a customer, a tool that changes behaviour overnight: these are incidents. They must be reported, handled and, for some uses, notified to the authorities.
What we recommend
- Add an “AI incident” reporting channel (address or form) and announce it in the policy; define who handles reports and within what timeframe.
- Extend the existing incident procedure to AI cases and notification obligations (data protection authority within 72 hours for a data breach; provider and supervisory authority for a high-risk use).
- Document a degraded mode for each critical AI use and test it during an annual exercise.
Open models and in-house development
Hosting an open-source model or training one yourself shifts to you responsibilities normally carried by the provider: model provenance and licence, file integrity, data quality and relevance, version management.
What we recommend
- Set up an assessment sheet for every open model (source, licence, vulnerabilities, file hashes, security tests) and an internal repository of approved models.
- Document each training dataset (datasheet: origin, rights, processing, limitations) and check its integrity (hashes, restricted access).
- Check with a lawyer whether your changes to models alter your status under the AI Act (from deployer to provider), which triggers additional obligations.
Frameworks
- AI Controls Matrix (CSA)
- AI Act
- ISO/IEC 42001
Where does your organisation stand?
The assessment evaluates these points for your organisation and ranks the actions by priority. Free, about 15 minutes, no account needed.