Does ISO 27001 cover AI governance? What it does and does not

When enterprise buyers start asking an AI SaaS vendor about ISO 27001, the product team often assumes this is a proxy question about the model itself - hallucination rates, fairness benchmarks, alignment controls. It is not. ISO 27001 is an information security management system standard. It says nothing about whether a language model is safe, unbiased or EU AI Act compliant. What it does cover is the organisational and technical controls around how data moves into and out of that model, who can access it, and whether the vendor can produce documented evidence when a buyer or auditor asks.

Understanding what falls inside and outside the standard's scope is essential before you start any readiness work. Treating ISO 27001 as a broad AI governance shield will leave serious gaps. Treating it as irrelevant to AI products is also wrong - buyers are using it as a qualification gate precisely because it answers questions they cannot easily answer from a vendor's marketing page.

What ISO 27001 does not cover

The standard does not assess model behaviour in any form. It will not tell a buyer whether your model:

• Produces outputs that discriminate against protected groups.
• Meets the obligations of the EU AI Act for high-risk AI systems.
• Stores or surfaces training data in ways that breach copyright.
• Hallucinates at a rate that creates professional liability.

Those are real concerns, and there are emerging frameworks to address them - the EU AI Act's conformity assessment regime, NIST AI RMF, ISO/IEC 42001. An ISO 27001 certificate does not substitute for any of them. If a buyer's procurement questionnaire treats the certificate as evidence of AI Act compliance, that is a misread of the standard, and you should correct it rather than allow the assumption to stand.

What ISO 27001 does cover, and why buyers care

Enterprise buyers who gate on ISO 27001 are asking a narrower, more answerable set of questions. They want to know whether the vendor has documented controls and evidence for:

Access to customer data. Who inside the AI vendor's organisation can read, export or query data that customers have submitted - including the prompts, files and context passed to the model. Annex A controls around access management and privileged access apply directly.

Sub-processor chain. When customer data leaves the vendor's own infrastructure to reach a foundation model API - OpenAI, Anthropic, Google, a self-hosted provider on a cloud platform - that provider is a sub-processor. Buyers with data processing agreements in place will ask whether the vendor has assessed and documented those sub-processors. ISO 27001 clause 8.1 on operational planning and Annex A controls on supplier relationships require exactly this.

Data retention and deletion. How long does the vendor keep customer data? Are prompts and inference logs retained, and for how long? Can customer data be deleted on request? These questions map to information classification and asset management controls in the standard.

Incident response. If there is a breach, does the vendor have a documented process and can they notify within the timeframes their contracts require? Annex A's incident management controls are evidence that the vendor has thought this through.

Audit evidence. The meta-question underneath all of this is: when you say you do these things, can you show a record that you did them? ISO 27001 requires documented procedures and evidence of implementation. That is what survives a buyer's due-diligence questionnaire.

Where the boundary sits in practice

A useful way to think about it: ISO 27001 covers the pipeline, not the model. It governs how data flows to and from the AI system, who can touch it along the way, and whether decisions about that flow are documented and reviewed. It does not govern what the model does with the data during inference.

For an illustrative example, consider a legaltech SaaS that passes matter documents to an LLM for summarisation. ISO 27001 asks: who has API credentials, is the sub-processor documented, how long are summaries retained, and what happens if the API logs the input. It does not ask whether the summary is accurate or whether the model was trained on data that creates conflict-of-interest risks.

This boundary matters when scoping your ISMS. The assets and processes in scope are the ones that store, transmit or process customer information. The model itself, if hosted by a third-party API provider, is a sub-processor asset - your controls are contractual and procedural, not technical controls over the model's internals.

How to position ISO 27001 to buyers honestly

When a buyer asks "are you ISO 27001 certified?" in the context of AI governance, the right answer is layered:

• The certificate covers our information security management practices: access, data handling, sub-processor oversight, incident response.
• It does not certify the AI model's behaviour, fairness or regulatory compliance under the EU AI Act.
• If you have specific AI governance requirements beyond information security, those need to be addressed separately.

Buyers who understand procurement will respect this precision. Buyers who are conflating ISO 27001 with AI governance need to be corrected - not because it protects you legally, but because allowing the misunderstanding to persist means you will be held to an obligation the standard was never designed to document.

The ISO 27001 controls that carry most weight for AI SaaS

In practical terms, the Annex A controls that enterprise buyers look at hardest in the AI SaaS context are:

• A.8.3 / Information access restriction - who can access customer data and model outputs.
• A.5.19-5.22 / Supplier relationships - how you assess and contract with LLM API providers.
• A.8.12 / Data leakage prevention - controls over prompt and output data leaving your environment.
• A.5.34 / Privacy - how your data handling aligns with your stated retention and processing purposes.
• A.5.24-5.28 / Incident management - documented process for security events, including data involved in inference pipelines.

Getting these controls evidenced and linked to your AI product's actual architecture is where readiness work concentrates.

Where Kellwick fits

Kellwick works with AI SaaS companies to get ISO 27001 controls evidenced in a way that maps to how their products actually process data - including the sub-processor chain that runs through LLM APIs. If you are navigating a buyer's security questionnaire or preparing for certification and want an honest view of where the gaps are, learn more about our AI SaaS advisory.