The short answer
ISO/IEC 27001 contains no control that mentions artificial intelligence, machine learning or large language models. That is not a gap you have to work around — it is the reason the standard already applies. To an ISMS, an LLM assistant is an externally provided cloud service that your staff transfer classified information into, and the standard has a great deal to say about that.
Roughly a dozen Annex A controls carry the weight. The question at audit is not whether you allow AI tools. It is whether the ones your people are already using appear in your risk assessment, your Statement of Applicability and your supplier register — and whether the answers are dated.
Why there is no AI control
The 2022 revision restructured Annex A into 93 controls across four themes: organisational (A.5), people (A.6), physical (A.7) and technological (A.8). It is deliberately technology-neutral. Controls describe outcomes, not products, which is why a tool that did not exist when the text was drafted is in scope the moment someone pastes something into it.
This cuts both ways. You get no exemption because the standard is silent, and no ready-made checklist either. What you get is a requirement to think about it, and to write down what you thought.
Start with the clauses, not Annex A
The common mistake is to open Annex A and start mapping controls. Annex A is a reference set you select from. The obligations live in clauses 4 to 10, and an auditor will get there first.
Clause 4.3 — scope of the ISMS. Is the tool inside your boundary? If developers use it on in-scope systems with in-scope data, it is in scope, whether or not procurement knows it exists.
Clause 6.1.2 — risk assessment. There has to be an identified risk with a named owner. “Confidential source code disclosed to a third-party model provider and retained beyond our control” is a risk statement. “AI” is not.
Clause 6.1.3 and the Statement of Applicability. Every Annex A control is included or excluded with a justification. If you excluded A.8.12, data leakage prevention, and your developers are pasting into a chat window, that exclusion now has to survive a question.
Clause 8.1 — operational planning and control. The distance between what your policy says and what actually happens on the laptops. This is where AI tooling usually generates the finding, not in the Annex A mapping.
The controls that actually bite
A.5.23, information security for use of cloud services. New in 2022 and the most load-bearing control here. It covers acquisition, use, management and exit for cloud services. An LLM API or assistant is a cloud service, and this is where retention, residency and the exit question — can you get your data deleted when you leave? — properly belong.
A.5.19 to A.5.22, supplier relationships. A.5.19 requires a process for the risks of a supplier handling your information. A.5.20 requires the relevant requirements to be in the agreement. A.5.21 extends this to the ICT supply chain, which for AI tooling means the sub-processors behind your vendor — including the model provider, when the tool you bought is a wrapper around someone else’s API. A.5.22 requires you to monitor and review supplier service delivery, which here means re-reading terms that providers revise without telling you.
A.5.12 classification, A.5.13 labelling, A.5.10 acceptable use, A.5.14 information transfer. This quartet is what turns “be careful with AI” into something enforceable. Classification establishes what your data is. Acceptable use governs what may be done with assets. Information transfer covers rules for moving information out of the organisation, and a prompt is a transfer. The dependency runs in one direction: you cannot write “no Confidential data in unapproved tools” if nothing in your organisation is marked Confidential.
A.5.34 privacy and protection of PII, A.5.31 legal and contractual requirements, A.6.6 confidentiality agreements. The interface with GDPR and with your client contracts. A.6.6 is the one that catches consultancies — an NDA restricting disclosure to third parties does not carve out a model provider because the disclosure was convenient.
A.8.11 data masking, A.8.12 data leakage prevention, A.8.10 information deletion. The technical layer, and where the awkward part lives. More on A.8.10 below.
A.8.15 logging and A.8.16 monitoring activities. Unapproved tools. You cannot claim a control over software you have no way of seeing, and an auditor asking “how would you know?” is asking about these two.
A.6.3 awareness, education and training. Generic security awareness will not cover this. Staff need to know what the tools transmit beyond what they typed, which is a narrower and more surprising subject than most training covers — see what your AI coding extension sends and the nine-point check before pasting code.
Development controls: A.8.4 access to source code, A.8.25 secure development life cycle, A.8.28 secure coding, A.8.30 outsourced development, A.8.33 test information. A.8.33 is the quiet one — the fixture file with real customer data in it becomes model context the moment the assistant reads the repository. A.8.30 is arguable: whether a code-generating assistant amounts to outsourced development is a position you should hold deliberately rather than improvise if an auditor raises it.
Where the standard and the tools genuinely collide
A.8.10 requires information to be deleted when it is no longer required. That is straightforward on storage you operate. It is hard when a provider retains inputs for abuse monitoring on a schedule you did not set and cannot interrupt.
If your provider offers no deletion mechanism for that pipeline, you do not have the control. There are two honest responses. Either move to a tier or product that offers zero retention and get it in writing, or record the gap as an accepted risk, with an owner, a justification and a review date. What you cannot do is claim A.8.10 in your SoA and hope nobody reads the provider’s terms.
A.8.11 has the same shape. Masking after the prompt has been sent is not masking; redaction before submission is the only point you control.
What you should be able to produce
Nothing here is exotic. It is the documented information the standard requires anyway, aimed at a specific class of supplier:
- SoA entries for the controls above, with the justification that reflects AI tooling rather than a generic one written in 2021.
- A risk assessment entry naming the tool and the data class, with an owner.
- A supplier record per tool: legal entity, tier in use, whether a DPA is signed and accepted, the sub-processor list or its absence, retention, and the date the terms were read.
- The acceptable use policy, plus acknowledgement records — clause 7.2 and 7.3 want competence and awareness demonstrated, not asserted.
- Configuration evidence. Exclusion patterns committed to the repository beat a policy stating that developers will be careful.
- A review record showing A.5.22 is real: someone re-read the terms on a date, and here is what changed.
The supplier record is the one that fails most often, because it is the one nobody owns.
ISO 27001 is not ISO 42001
Two distinctions worth keeping straight.
ISO/IEC 42001:2023 specifies an AI management system, and it is aimed at organisations that develop, provide or deploy AI systems. If you are a consumer of someone else’s LLM, 27001 is the standard that governs you. 42001 is something to look for in your provider, not something you need to certify against because you bought a coding assistant.
And your provider’s certificate is not your control. An ISO 27001 certificate covers a defined scope, printed on the certificate itself. Ask for it, then read the scope statement — a certificate covering a corporate network is not a certificate covering the inference platform your prompts land on. The same applies to a SOC 2 report, where the system description tells you what was actually examined. This is one of the ten checks in how to judge an AI provider.
What ISO 27001 will not do for you
It will not tell you which tool to approve. It is a management system standard: it requires you to identify risk, decide, document the decision and review it. A coherent, documented decision to permit a tool passes. An undocumented ban that everyone ignores does not.
It also predates the failure modes specific to these systems. There is no Annex A control for prompt injection, and mapping it to A.8.26, application security requirements, is defensible — but that is your reasoning, not the standard’s, and you should be able to explain it as yours.
Control titles and numbering here are from ISO/IEC 27001:2022 Annex A; check them against your own copy, and treat your certification body’s interpretation as governing over any reading of mine.
Where to start
If you do one thing this week: list the AI tools your organisation actually uses — ask people, do not infer it from procurement records — and add each one to the supplier register with the tier, the date the terms were read and the name of an owner. In my experience the register is where this either becomes manageable or stays permanently invisible, and building the first version of it takes an afternoon.