Your ISO 27001 system was probably designed before anyone in your business used AI, and AI is in the business now. Although the standard does not mention AI anywhere, an AI tool is a supplier, an account and a route for information to leave, and the system you already run has requirements for all three. Most of that system now has AI in scope whether or not anyone has updated it.
We run our own ISO 27001 system, and what follows is how we read the standard against AI use, for your certification body to confirm. Every certificate is now issued against the 2022 version of the standard, since the transition from the 2013 version closed in October 2025, so the references below use the 2022 numbering.
Start with context and risk
Two parts of the main clauses are where AI enters the system.
The first is context. Clause 4 asks you to understand the parties with an interest in your information security and what they require. If your clients have started asking how you control AI, in a questionnaire or a contract, that is a requirement from an interested party, and it belongs in the record.
The second is risk. The risk assessment in clause 6.1.2 has to cover the AI tools in use, and the risk treatment in clause 6.1.3 has to say what you are doing about them.
Where you now rely on a control for AI that you did not rely on before, the Statement of Applicability has to reflect it. Clause 6.3, added in the 2022 version, asks for changes to the system itself to be planned, and bringing AI into it is that kind of change.
The Annex A controls AI touches
Most of the work sits in controls you already operate, although AI changes what they have to cover.
- Inventory, 5.9. Each AI tool, the type of account it runs on and its owner belong on the asset register. The tool register that an AI policy calls for is this control applied to AI.
- Acceptable use and classification, 5.10 and 5.12. The rule on what may go into an AI tool is your classification scheme applied to a new destination. If client documents are confidential, the policy has to say what that means for a chat window, and the data list in what an AI policy should contain is the place to say it.
- Suppliers and cloud services, 5.19 to 5.23. AI vendors are cloud suppliers, assessed like any other: what their terms say about training on your data, how long they keep it, which subprocessors they use and where it is held. Their terms change often, so review them under 5.22 more frequently than you would for most suppliers.
- Access, 5.15, 5.18 and 8.3. A connected tool can open whatever the signed-in person can open. A permissions review before connection is access control evidence, and what Copilot can already see has four checks that feed it.
- Identity and leavers, 5.16 and 6.5. Business accounts under company sign-in sit inside identity management and are removed when someone leaves. A personal account on a work email address sits outside both, which is why moving people off them is itself a control.
- Awareness, 6.3. Training has to cover the AI rules, because people make the call about what goes in several times a day. AI literacy sets out what each group needs.
- Data leakage prevention, 8.12. If it is in your Statement of Applicability, AI chat sites, browser extensions and note-takers are channels it now has to consider.
- Logging and monitoring, 8.15 and 8.16. Decide what you can see of AI use. Business tiers record more than personal ones, so find out what yours keeps before an auditor asks.
- Incidents, 5.24 to 5.28. Client data pasted into a personal AI account is an information security event. People need to know it is reportable and that reporting it will not get them into trouble.
- Legal and privacy, 5.31 and 5.34. Contracts with clients may limit what you can put into third-party tools, and personal data brings data protection obligations. Your advisers tell you what applies, and the system records how you meet it.
If you build AI into your own software, the secure development controls from 8.25 to 8.28 apply to that work as well. AI security for a business that uses AI tools puts the threats behind these controls in one place.
Questions to be ready for
An auditor can ask about AI under any of the controls above. These are the questions we would want a client to be able to answer with a document rather than a description:
- Which AI tools are in use, and where are they on the asset register?
- How was each one assessed as a supplier, and when was that last reviewed?
- What may go into them, and how do your people know?
- What can each connected tool reach, and who checked that before it was connected?
- What happens to a leaver's AI accounts on their last day?
- Has there been an AI-related event, and what was done about it?
A business that can answer all six in writing has extended its system to cover AI.
Where ISO 27001 stops
ISO 27001 protects your information. It does not ask whether an AI system's output is fair, whether a person reviews a decision it makes about someone or how its effect on people is assessed. For a business that only uses AI tools from suppliers, those questions are mostly answered by the policy's rule on human review. For a business that builds AI into a product or makes decisions about people with it, they are the ground ISO 42001 covers.
Where this fits
The outputs of Govern map onto these controls.
| Output of Govern | Control it evidences | Annex A |
|---|---|---|
| The tool register | Inventory | 5.9 |
| The written policy | Acceptable use and awareness | 5.10 and 6.3 |
| Sign-in under your company account | Identity and leavers | 5.16 and 6.5 |
| The permissions review | Access | 5.15, 5.18 and 8.3 |
Before any of that, the readiness snapshot finds the tools that belong on the register. We build those controls and the evidence behind them. Certification is your certification body's decision, and Guardrails lists what we do and do not claim.