ISO/IEC 27001 Controls for AI Deployments

Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser

This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.

Most of what secures an AI deployment is ordinary information security applied to a new kind of asset: access control, logging, cryptography, supplier management, incident response. ISO/IEC 27001:2022 and its Annex A cover that ground well, and an organisation with a working ISMS is most of the way there. What it does not cover is the AI-specific attack surface — prompt injection, training-data provenance, model extraction — and naming that gap honestly is more useful than stretching a control to fit it.

What transfers unchanged

An inference endpoint is a service. The controls that secure a service secure it:

• Access control. Every caller of the model endpoint authenticates and is authorised. This sounds obvious and is the most frequently found real misconfiguration in self-hosted deployments — model servers commonly default to listening broadly, and an internal LLM on an open port is a data-exfiltration path with a chat interface attached.
• Network placement. The model server belongs behind a gateway on an internal interface, not bound to all interfaces because that was the quickstart command.
• Logging. Annex A's logging control applies exactly as to any other system, and the AI Act's record-keeping duty for high-risk systems sits on top of it.
• Cryptography and secure configuration. Standard practice, standard controls.
• Supplier relationships. Relevant whether you use a managed API or download weights from a model hub — in the second case the supplier question is about provenance and integrity of the artefact.
• Incident management. The procedure transfers; what counts as an incident does not, which is the next section.

The gaps, named rather than papered over

ISO/IEC 27001:2022 predates the deployment pattern this site is about, and three gaps are real:

Prompt injection has no Annex A control. Our mapping records this as a structural gap rather than mapping it to secure coding, which is the nearest neighbour and is not close. A retrieval system reads documents it does not control; those documents can contain instructions aimed at the model; the model has no reliable way to distinguish them from your instructions. That is an architectural property, not a coding defect, and the control is to constrain what the model is *able* to do rather than to filter what it reads. This is precisely the space ISO/IEC 42001 and CSA AICM exist to cover.

An AI incident may involve no security failure. ISO/IEC 27001's incident controls trigger on security events. A system working exactly as built, with no compromise of any kind, can still produce a harmful output — a confidently wrong answer acted on, a biased ranking, a disclosure of something that was legitimately in the corpus but should not have surfaced to that reader. Your incident definition needs widening before your incident process is useful here.

Data governance in Annex A is about protection, not representativeness. The controls ask whether data is classified, handled and protected appropriately. An AI deployment also has to ask whether the data is *relevant and sufficiently representative* for the people the system is used on — a question about fitness for purpose that the security standard does not pose.

Recording these as gaps is deliberate. A mapping that forces prompt injection onto a secure-coding control tells a reader they are covered when they are not, which is worse than telling them nothing.

The self-hosting security trade

Running models yourself removes one class of risk and adds another, and an honest assessment counts both.

Removed: third-party data exposure in the inference path, dependency on a vendor's retention and change-control decisions, and the transfer analysis that comes with sending content to a processor in another jurisdiction.

Added: you now operate an inference service, and it is yours to secure. The endpoint, the retrieval corpus, the model artefact and the GPU host are all assets someone must own. The corpus is the underrated one — a retrieval index frequently ends up containing material with broader access than the index itself, so the assistant becomes a query interface over documents its users could not otherwise open. Access control on the retrieval layer, not just on the endpoint, is the control that addresses it.

Deployment controls that relate to ISO/IEC 27001

Annex A identifiers with our own descriptions. ISO's control text is copyrighted and sold; this repository stores identifiers and mapping metadata only. Note the structural gap recorded against prompt injection — it is a finding, not an omission.

Assess a specific deployment

The generic answer is on this page. The specific one depends on what your system is for, who it affects and what it decides — which is what the assessment asks about.

Create Compliance Profile →

Automated assessment based on the information you provide. Not legal advice, certification or an audit.

Frequently asked questions

Keep going

• On-premise LLM deployment — the production architecture
• Air-gapped LLM deployment — who actually needs it
• ISO/IEC 42001 and AI Deployment Governance
• CSA AI Controls Matrix for LLM Deployments
• SOC 2 and AI Deployment Controls
• AI Compliance & Deployment Readiness — the full hub