ISO 42001: AI Governance You Can Prove
ISO/IEC 42001 is the first certifiable AI management standard, and it is already showing up in enterprise procurement. Here is what the standard actually requires, which Annex A controls bite hardest when you buy AI instead of build it, and how to produce the evidence an auditor will ask for.
The question arrives in a vendor security questionnaire, usually somewhere after the SOC 2 section: "Describe your AI governance program. Do you maintain an AI management system aligned to ISO/IEC 42001?"
For most CIOs and CISOs, the honest answer is a paragraph about an acceptable-use policy circulated last year and a promise to follow up. That answer is getting harder to give. AI governance has moved from principles decks to audit scope, and ISO/IEC 42001 is the standard doing the moving.
This guide covers what ISO 42001 actually requires, how it differs from ISO 27001 and SOC 2, which controls hit hardest for organizations that use AI rather than build it, and the practical problem nobody warns you about: almost every control in the standard needs evidence you cannot produce without a control point in front of your AI traffic.
What Is ISO/IEC 42001?
ISO/IEC 42001:2023 is the international standard for an AI management system (AIMS). Published in December 2023, it is the first certifiable AI governance standard — an accredited body can audit your organization and issue a certificate, exactly the way ISO/IEC 27001 works for information security.
It specifies requirements for establishing, implementing, maintaining, and continually improving a management system for AI. Critically, it applies to any organization that develops, provides, or uses products and services that rely on AI. You do not have to train models to be in scope. Deploying someone else's is enough.
The structure will look familiar to anyone who has been through an ISO audit:
- Clauses 4–10 are the management system requirements: context of the organization, leadership, planning, support, operation, performance evaluation, and improvement. This is the Annex SL high-level structure shared by ISO 27001, ISO 9001, and the rest of the family.
- Annex A is the normative set of 38 controls organized into nine areas (A.2 through A.10), covering everything from AI policy to data provenance to third-party relationships.
- Annex B provides implementation guidance for each control, Annex C catalogues AI-related organizational objectives and risk sources, and Annex D addresses sector-specific application.
Certification follows the usual path: define your scope, produce a Statement of Applicability justifying which Annex A controls you apply and which you exclude, pass a Stage 1 documentation review and a Stage 2 audit of operating effectiveness, then hold the certificate on a three-year cycle with annual surveillance audits.
Why It Landed on Your Desk This Year
Four pressures converge, and they arrive in a predictable order.
Procurement moved first. Enterprise buyers have started adding AI governance clauses to vendor questionnaires, and ISO 42001 is becoming the shorthand answer the way SOC 2 became shorthand for SaaS security. Once one large customer asks, the requirement propagates down the supply chain within a quarter.
Regulation is close behind. The EU AI Act's obligations are phasing in across 2026 and 2027, and sector regulators, data protection authorities, and frameworks like India's DPDP Act are converging on the same expectations: documented accountability, risk assessment, and records. ISO 42001 certification is not, by itself, a presumption of conformity with the AI Act — that role belongs to harmonised European standards — but the management system it forces you to build is the same scaffolding those obligations require.
Boards and insurers want an owner. "Who is accountable for AI risk in this organization?" is now a board-minutes question. A certified management system is the cleanest available answer, because it names roles, assigns responsibilities, and produces evidence on a schedule.
And the internal reality is uncomfortable. You are being asked to govern something you largely cannot see. Employees are using AI through personal accounts, browser extensions, embedded copilots in tools you already pay for, and increasingly through agents that act on their behalf. The governance gap is not that policies are missing. It is that nothing enforces them and nothing records what happened.
ISO 42001 vs. ISO 27001 vs. SOC 2
These three get conflated constantly. They answer different questions.
| ISO/IEC 27001 | SOC 2 | ISO/IEC 42001 | |
|---|---|---|---|
| Governs | Information security | Service controls at a provider | AI systems across their life cycle |
| Core question | Is our information protected? | Can we attest our controls operated? | Is our AI governed, assessed, and accountable? |
| Unit of risk | Confidentiality, integrity, availability | Trust services criteria | Impact on individuals, groups, and society |
| Output | Certificate | Attestation report | Certificate |
| Covers AI users? | Indirectly | Indirectly | Explicitly — providers and users |
| Distinctive demand | Asset and access control | Evidence of control operation | Impact assessment, data provenance, responsible use |
The most important row is the last one. ISO 27001 asks whether data is protected. ISO 42001 asks something that no security standard asked before: what does this AI system do to the people affected by it, how do you know, and who decided that was acceptable?
The good news for anyone already certified: because 42001 shares the Annex SL structure, you can integrate it into an existing ISO 27001 management system and reuse the internal audit programme, management review cadence, corrective action process, and document control. The scaffolding transfers. The AI-specific controls do not.
What the Standard Actually Asks For
The nine Annex A control areas are where implementation lives. In plain terms:
- A.2 — Policies related to AI. A documented AI policy, aligned with your other policies, reviewed on a defined cadence.
- A.3 — Internal organization. Named AI roles and responsibilities, and a working channel for people to report concerns about AI systems.
- A.4 — Resources for AI systems. Documented data, tooling, compute, and human resources that your AI systems depend on. In practice: an inventory.
- A.5 — Assessing impacts of AI systems. A defined process for AI system impact assessment, records of those assessments, and explicit consideration of impacts on individuals, groups, and society.
- A.6 — AI system life cycle. Responsible design, development, verification, deployment, operation, monitoring, technical documentation, and event logging.
- A.7 — Data for AI systems. Data management, acquisition, quality, provenance, and preparation — including the personal data flowing through prompts.
- A.8 — Information for interested parties. Documentation for users, external reporting, incident communication, and information for authorities.
- A.9 — Use of AI systems. Processes for responsible use, defined objectives for that use, and enforcement of intended use.
- A.10 — Third-party and customer relationships. Allocating responsibilities across the AI supply chain, managing suppliers, and handling customer obligations.
Read that list again with one filter applied: how many of these can you evidence today without instrumenting AI usage?
The Trap: You Are an AI User, Not Just a Builder
ISO 42001 distinguishes roles across the AI value chain — providers and producers who build systems, customers and users who deploy them, partners, and the AI subjects affected by the output. Most mid-market and enterprise organizations sit squarely in the user category. You are not training foundation models. You are routing your workforce through OpenAI, Anthropic, Microsoft Copilot, a dozen embedded AI features, and a growing population of agents.
Teams read that and assume the standard is mostly someone else's problem. The opposite is true. Being a user shifts which controls apply, and the ones that land are the operationally hardest to evidence:
- A.9 — Use of AI systems. You have to show that AI is used within defined objectives and intended use. Not that you published a rule. That the rule holds.
- A.10 — Third-party relationships. You have to show which providers process what, and how responsibility is allocated between you and them.
- A.5 — Impact assessments. You have to assess the impact of AI systems on real people — which requires knowing which systems are in use, by whom, on what data.
- A.6 — Operation, monitoring, and event logs. You have to keep records of AI system operation. An invoice from a model provider is not a record of operation.
- A.7 — Data for AI systems. You have to govern the data entering the system. The prompt is the data pipeline.
Every one of those controls asks a question about behaviour, not intent. And behaviour is exactly what an unmediated AI stack does not record.
Get Audit-Ready Evidence
Book a demo of SecuriX and we'll show you the exact logs, policy decisions, and reports an ISO 42001 auditor asks for.
The Evidence Gap
Auditors do not grade policy documents. They sample evidence, over a period, and test whether the control actually operated. This is where most AI governance programmes fail their first internal audit — not because the policies are bad, but because there is no system of record.
Here is the gap, control by control:
| The auditor asks for | Without a control point | With an AI gateway in front |
|---|---|---|
| An inventory of AI systems in use | A spreadsheet last updated two quarters ago | A live registry of every model, provider, and application routed |
| Evidence the AI use policy is enforced | A training deck and a signed acknowledgement | A policy decision recorded on every single request, allow and deny |
| Records of AI system operation and event logs | Provider invoices and console screenshots | An immutable prompt, response, and tool-call log attributed to an SSO identity |
| Protection of personal data in AI inputs | "We instructed employees not to paste PII" | Classification and redaction before egress, with incident records |
| Supplier and third-party control | A signed DPA in a contracts folder | Per-provider routing rules, model whitelists, and a record of what data each provider was permitted to see |
| Inputs to impact assessments | Interview notes and estimates | Actual usage by team, use case, data class, and volume |
| Concern and incident reporting | A shared inbox | Anomaly and DLP incidents routed by webhook into your SIEM and ticketing |
The pattern is consistent. The left column is achievable in a month of documentation work. The right column is impossible to produce retroactively — which is why the sequencing matters. Instrument first, then write the policy the instrumentation can actually enforce. Teams that do it the other way round spend Stage 2 explaining why their evidence sample is empty.
Where SecuriX Fits
Let us be precise about this, because the market is full of vendors implying otherwise: no product makes you ISO 42001 certified. Certification audits your management system — your scope, leadership commitment, risk process, internal audit, and corrective actions. That is organizational work, and it belongs to you.
What a product can do is make the operational controls enforceable and, more importantly, evidenceable. SecuriX is an Enterprise AI Gateway and Agent Access Security Broker: every prompt, response, and agent tool call routes through one control point. That position on the network is what turns Annex A from a set of intentions into a set of records.
| Annex A area | What the standard expects | Where SecuriX produces it |
|---|---|---|
| A.2 Policies related to AI | A documented, aligned, reviewed AI policy | OPA Rego policy engine with Git sync — policy is version-controlled, peer-reviewed, and executed on every request |
| A.3 Internal organization | Roles, responsibilities, concern reporting | SSO and SCIM identity mapping ties every action to a person and team; incidents route by webhook |
| A.4 Resources for AI systems | Documented data, tooling, and compute resources | Centralized model catalog and connected MCP tool inventory, scoped per team |
| A.5 Assessing impacts | Impact assessment process and records | Token and usage analytics by team, use case, and data class — the factual base an assessment needs |
| A.6 AI system life cycle | Responsible operation, monitoring, event logs | Immutable prompt and response audit log, policy decision logging, and real-time anomaly detection |
| A.7 Data for AI systems | Data management, quality, provenance, privacy | DLP engine classifying and redacting PII before egress, plus redaction of tool responses on the way back |
| A.8 Information for interested parties | Reporting, incident communication | SIEM streaming, log export, and CSV reporting for compliance and finance |
| A.9 Use of AI systems | Responsible use, intended use enforcement | Governed chat portal behind SSO, per-team model whitelisting, block/warn/approve workflows, and budget guardrails |
| A.10 Third-party relationships | Supplier management, allocated responsibility | Multi-provider routing with per-provider policy; agent credentials vaulted, scoped, and centrally revocable |
The honest summary: SecuriX will not write your Statement of Applicability. It will mean that when the auditor samples ninety days of AI activity, you have ninety days of AI activity.
Agents Raise the Bar Again
ISO 42001 was written with AI systems in mind, and agentic systems are AI systems that act. An agent holding delegated authority to read a mailbox, query a warehouse, and call an API is squarely inside A.6 (life cycle and operation), A.9 (intended use), and A.10 (third-party responsibility) — and it is far harder to evidence than a chatbot, because it takes actions no human reviewed.
Three questions an auditor will reasonably ask about any agent in production:
- Whose authority is it acting under? Agents need first-class non-human identities, not a shared service account and a long-lived key. We covered the progression in the AI IAM maturity model.
- What is it permitted to do, and who decided? Coarse OAuth scopes cannot express "read this mailbox, never send," which is why per-tool-call policy exists — see Rego policy on tool calls and why IAM alone is not enough.
- Can you prove what it did, and stop it? Every tool call logged with parameters and policy decision, and credentials revocable centrally when a project ends — the zombie agent problem is an audit finding waiting to happen.
If your AIMS scope includes agentic systems — and by next year it will — this is the layer that has to exist before the scope statement is credible.
A 90-Day Readiness Plan
Days 1–30 — Scope and see. Define the AIMS scope and name an accountable owner (clause 5 will require it anyway). Then get visibility: deploy the gateway, route AI traffic through it, and let a real inventory assemble itself. Do not write the policy yet. You do not know what you are governing.
Days 31–60 — Control and document. With two to four weeks of actual usage data, write the AI policy against reality and encode it as enforceable policy. Turn on DLP. Set model whitelists and team budgets. Draft the Statement of Applicability. Run impact assessments on your highest-exposure use cases — usually customer-facing, HR-adjacent, or anything touching regulated data. Build the supplier register from the providers you can now see.
Days 61–90 — Evidence and audit. Run the internal audit, hold the first management review, and log corrective actions. Stream logs to your SIEM so retention is defensible. Then engage a certification body for Stage 1.
A realistic caveat on timeline: Stage 2 tests operating effectiveness, so most organizations need three to six months of the system genuinely running before the certificate is achievable. Starting from an existing ISO 27001 programme compresses this considerably. Starting from nothing, plan for six to twelve months end to end — and note that the technical instrumentation is days of work, while the calendar goes to evidence accumulation and audit scheduling.
Common Mistakes
Writing the policy before you can see the usage. You end up governing an imagined organization. The first internal audit finds the gap, and you rewrite everything.
Confusing model assurance with organizational certification. An ISO 42001 certificate says your management system meets the standard within a defined scope. It does not say a model is safe, unbiased, or accurate. Do not let it be marketed internally as either.
Excluding controls in the SoA without justification. Exclusions are permitted; unjustified exclusions are a finding. "We do not develop AI systems" is a defensible reason to scope down parts of A.6. "We are only a user" is not a reason to scope out A.9.
Treating shadow AI as out of scope. The auditor's question is not "what is in your scope," it is "how do you know your scope is complete." If employees can reach public models through personal accounts, you cannot answer. Consolidating everything onto one governed surface is the answer — we wrote the playbook in Taming Shadow AI and Zombie Agents.
Buying a tool and calling it compliance — or writing sixty pages with no enforcement point. These look like opposite mistakes and fail identically: neither produces evidence that a control operated.
Frequently Asked Questions
What is ISO 42001 in simple terms? It is the international standard for managing AI responsibly. It defines how an organization sets AI policy, assigns accountability, assesses the impact of AI systems on people, controls the data those systems consume, and keeps records — and it can be independently certified by an accredited auditor.
Is ISO 42001 mandatory? No. It is a voluntary standard. In practice it is becoming contractually mandatory, because enterprise customers are asking for it in procurement. It is also not a legal substitute for regulatory compliance — it is the management system that makes regulatory compliance demonstrable.
How is it different from ISO 27001? ISO 27001 governs information security: protecting confidentiality, integrity, and availability. ISO 42001 governs AI systems and their effects, including impact on individuals and society, data provenance, responsible use, and life cycle management. They share a structure and integrate well, but 27001 certification does not cover 42001 requirements.
Do we need it if we only use third-party AI? Yes, the standard explicitly covers organizations that use AI systems. If anything, the user-side controls — A.9 on responsible use and A.10 on third-party relationships — are harder to evidence than the builder-side ones, because the systems are outside your infrastructure and the only place you can observe them is at the network boundary.
How long does ISO 42001 certification take? Typically six to twelve months from a standing start, or three to six months for organizations with a mature ISO 27001 programme to build on. The constraint is not documentation — it is accumulating enough operating evidence for the Stage 2 audit to sample.
Can a tool make us ISO 42001 certified? No, and be sceptical of anyone claiming otherwise. Certification assesses your management system. What tooling does is make operational controls enforceable and produce the records the audit consumes — which is the part that cannot be created retroactively.
Where does SecuriX fit in an ISO 42001 programme? As the enforcement and evidence layer. SecuriX sits between your employees, your agents, and every AI provider, executing policy on each request and recording the outcome. That covers the operational side of A.6, A.7, A.9, and A.10, and it supplies the usage data that impact assessments under A.5 depend on. The platform overview walks through the full control set.
The Bottom Line
ISO 42001 changes AI governance from a statement of principles into something an auditor can test. That is genuinely good news for CIOs and CISOs, because it replaces an unanswerable question — is our AI use responsible? — with a set of specific, evidenceable ones.
But every one of those questions eventually reduces to the same requirement: a record of what your organization actually did with AI. Policies are cheap and fast. Evidence has to be generated while the activity happens, at a point where every prompt, response, and agent action passes through.
Get that control point in place first. The certificate follows the system, and the system needs a place to stand.
Book a Demo
See how SecuriX enforces AI policy and produces audit-grade evidence across every prompt, model, and agent.
Continue reading: Cut Enterprise AI Costs in Half for how the same gateway pays for itself, Securing Agentic AI: Maturity Model for the identity progression behind agent governance, or the Enterprise platform overview for the full control set.
— The SecuriX Team
Community Forum
Questions, Feedback & Discussions
Join the conversation
Recent Discussions 0 Comments
No questions yet. Be the first!