Three groups now ask how you govern AI: regulators, who want named accountability and traceable records; auditors, who want a management system with evidence that controls operate; and customer security reviews, whose questionnaires now carry an AI section. All three want records of what your AI actually did — a policy document on its own satisfies none of them.
AI governance stopped being theoretical the day it showed up in a questionnaire. Three distinct groups now ask, and they want different things.
| Asker | What they’re worried about | What satisfies them |
|---|---|---|
| Regulator | Accountability and harm | A named owner, documented decisions, records that let an outcome be traced and remediated |
| Auditor | Whether governance actually operates | A management system: scope, assessed risks, controls, and evidence the controls run |
| Customer security review | Their data inside your AI | Straight answers about models, data flows, output review and failure handling — with evidence behind them |
The regulator’s question is accountability. When an AI-assisted decision goes wrong, they want to find a person who owns it, a record of what the system did, and proof the organisation could detect and correct the harm. Statements of principle don’t survive that conversation; records do.
The auditor’s question is operation. An auditor doesn’t assess whether your AI is good — they assess whether your governance of it runs: AI systems in scope, risks assessed, controls chosen, and evidence that the controls operated last month, not just on the day the policy was signed. It’s the same discipline ISO 27001 applies to information security, pointed at AI.
The customer’s question is the bluntest, and it arrives first for most companies: “what does your AI do with our data?” Security review questionnaires now carry an AI section asking what models you use, what data reaches them, who checks the outputs, and how you’d know if something went wrong. A vague answer doesn’t end the question — it multiplies the follow-ups, and the deal waits while you scramble.
ISO 42001 is the AI management system standard — ISO 27001’s sibling. Same machinery — scope, risk assessment, controls, audit, continual improvement — aimed at AI systems instead of information security generally. It exists precisely because the three askers above kept getting policy documents when they wanted management systems.
For most organisations it isn’t the starting point. If you already run an ISO 27001 ISMS, AI systems can be brought into scope today: add them to your asset inventory, put AI-specific risks through your existing risk assessment, and apply the same evidence discipline. ISO 42001 becomes worth pursuing when AI is your product, or when customers start naming it in reviews. ISO 27001 for AI companies works through that sequencing.
Underneath either standard sits the same non-negotiable: records. Every asker eventually lands on one test — show me what this AI system did. If you can’t produce a trail of inputs, actions, outputs and approvals, no certificate answers the question.
That ordering matters for budget. Build the audit trail first, because it’s the evidence every asker shares and the slowest thing to retrofit — you can’t reconstruct records you never captured. Then assign ownership: one named person accountable for AI use, with decisions written down. The policy comes last, describing what already runs. Done in that order, a certificate later is paperwork over a working system. Done in reverse, it’s paperwork over a gap.
Writing an AI policy and stopping.
The policy is the easy artefact — a page of principles about responsible use, signed and filed. But every asker on this page wants records of what your AI systems actually did: which model saw which data, what it produced, who approved the action that followed. A useful test: pick one AI-assisted decision from last month and try to reconstruct it end to end. If the answer lives in someone’s memory rather than a log, you have a statement of intent, not governance — and a questionnaire or audit will find that gap before you do.
We hold an unusual position here: we run AI agents inside our own security operations, so we had to solve AI governance for ourselves before offering it to anyone. Every agent session is logged — inputs, actions, verdicts — into the same platform that handles our customers’ security evidence, and our AI security capability applies that discipline to the AI in your environment. We’re ISO 27001:2022 certified, with AI systems inside that scope. When a review asks how your AI is governed, the answer is a record you can produce, not a paragraph you wrote.
Do we need ISO 42001 certification?
Probably not yet. ISO 42001 is the AI management system standard — ISO 27001’s sibling — and most of today’s asks are satisfied by ISO 27001 with AI-specific risks and controls added. ISO 27001 for AI companies covers when 42001 becomes worth pursuing.
What does the AI section of a security questionnaire ask?
In practice: what AI systems and models you use, what customer data reaches them, who reviews their outputs, how access is controlled, and how you’d detect and handle an AI system misbehaving. Answers need evidence behind them, because follow-up questions ask for it.
Is AI governance a legal requirement?
It depends on your jurisdiction and sector, and obligations are tightening. What’s consistent everywhere is the shape of the ask: a named owner, documented decisions, and records that let you reconstruct what an AI system did and why.
Can our existing ISO 27001 ISMS cover AI?
Largely, yes. AI systems are information systems: put them in scope, add AI-specific risks to your risk assessment, and apply the same control and evidence discipline. What most ISMSs lack is the audit trail of AI activity itself — that gap has its own guide.
How do we prove what an AI system actually did?
With an audit trail captured at the time: inputs, actions, outputs and approvals, logged and retained like any other security record. How do you prove what an AI system actually did? covers what that trail needs to contain.
