Getting ready for ISO 42001

What ISO 42001 is, and why it exists

ISO/IEC 42001:2023 is the first international standard for an Artificial Intelligence Management System, or AIMS. It exists because AI created governance questions that no existing standard answered cleanly: how do you demonstrate that AI is developed and used responsibly, that its risks are identified and treated, and that its impact on individuals and groups is assessed rather than assumed? ISO 27001 protects the confidentiality, integrity, and availability of information. It was never designed to speak to bias, transparency, human oversight, or the societal impact of an automated decision.

Like ISO 27001 and ISO 9001, ISO 42001 is a certifiable management system standard. That word matters. You are not certifying a product or a model. You are certifying that your organization has a repeatable, auditable system for governing AI across its lifecycle: policies, roles, risk processes, controls, monitoring, and continual improvement. An auditor examines the system and the evidence it produces, not the source code of any given model.

For a scale-up pursuing certification, the appeal is the same as ISO 27001: it is a recognized, third-party-verifiable signal that turns "trust us, we are responsible with AI" into "here is our audited program." Increasingly, enterprise buyers and regulated customers are starting to ask for it the way they already ask for SOC 2.

How the AIMS clauses fit together

ISO 42001 is built on the Harmonized Structure, also called Annex SL, that every modern ISO management system standard shares. If you have been through an ISO 27001 project, the shape is immediately familiar. The management system requirements sit in clauses 4 through 10:

• Clause 4, Context of the organization: define what your organization does with AI, who your interested parties are, and the scope of the AIMS.
• Clause 5, Leadership: secure top-management commitment, set an AI policy, and assign roles and responsibilities.
• Clause 6, Planning: run the AI risk assessment and risk treatment, and address the AI system impact assessment.
• Clause 7, Support: resources, competence, awareness, communication, and documented information.
• Clause 8, Operation: operational planning and control, executing the risk treatment and impact assessment in practice.
• Clause 9, Performance evaluation: monitoring, measurement, internal audit, and management review.
• Clause 10, Improvement: nonconformity, corrective action, and continual improvement.

Alongside the clauses, Annex A provides a reference set of AI controls, organized into control objectives that cover topics such as AI policy, internal organization, resources for AI systems, impact assessment, the AI system lifecycle, data for AI, information provided to interested parties, use of AI systems, and third-party relationships. As with ISO 27001, you are not required to implement every control. You produce a Statement of Applicability that justifies which controls apply and which do not. Annex B offers implementation guidance for those controls, and the standard references ISO/IEC 23894 for AI risk management technique.

Governing the AI you build vs. the AI your staff use

Most ISO 42001 readiness material assumes you are an AI developer: you train or fine-tune models, ship them in a product, and need to govern that lifecycle. That is a real and important scope. But for a large share of tech scale-ups, the more urgent and faster-moving exposure is the other side of the coin: the AI your own staff and engineers use every day. Browser LLMs, desktop AI apps, coding agents and CLIs, and MCP servers, most of it adopted without a review.

ISO 42001 covers both. Its scope explicitly includes organizations that use AI systems, not only those that build them. Annex A control themes around the use of AI systems, third-party relationships, and data for AI all point at this. The trouble is that this side is hard to evidence. You can document a model you trained. It is much harder to prove to an auditor that you know which AI tools are in use, what data flows to them, and that unapproved use is actually being prevented rather than merely prohibited on paper.

This is the gap Cerbera is built to help close, honestly, as one input among several. A policy that says "do not paste customer data into unapproved AI" is a clause 5 artifact. Continuous, inline evidence that the policy is enforced, that secrets and PII are redacted before they leave, that unapproved models are blocked, and that MCP servers are risk-scored and gated, is the operational proof clauses 8 and 9 ask you to produce. The policy is the claim. The proxy logs are the evidence.

A readiness roadmap you can actually run

Certification is the end of a path, not the start. Here is a sequence that maps onto the clauses without turning your team into full-time auditors.

1. Scope the AIMS

Decide what the management system covers. For most scale-ups this includes both the AI you may embed in your product and the AI your workforce uses. Define interested parties, boundaries, and exclusions. This is clause 4 work, and getting the scope honest here saves pain at audit.

2. Inventory the AI in use

You cannot govern what you cannot see. Build a real inventory of AI systems, tools, and third-party services in play. This is where continuous discovery earns its place: a point-in-time survey is stale within weeks, and shadow AI adoption does not wait for your audit cycle.

3. Run the risk assessment and the impact assessment

These are two distinct exercises, and conflating them is a common mistake. The AI risk assessment (clause 6, informed by ISO/IEC 23894) evaluates risks to the AIMS and your objectives. The AI system impact assessment evaluates what specific AI use could do to individuals, groups, and society, covering fairness, transparency, privacy, and safety. Document both.

4. Select and deploy controls

Map your treatments to Annex A control themes and record decisions in the Statement of Applicability. Technical controls like model allow-listing, DLP and redaction, and MCP risk gating sit here, alongside organizational controls like your AI policy and acceptable-use rules.

5. Monitor, then internally audit

Clause 9 requires you to monitor the system and run internal audits and management reviews before a certification body ever arrives. Continuous logs of AI use and policy enforcement make internal audit tractable rather than a scramble for screenshots.

6. Certification and improvement

A certification body runs a stage 1 (documentation) and stage 2 (evidence) audit, then surveillance audits keep the certificate alive. Clause 10 is not a finish line: nonconformities and improvements feed back into the loop.

How ISO 42001 relates to ISO 27001, the EU AI Act, and SOC 2

The most efficient way to approach ISO 42001 is the same "build once, map many" discipline that works for SOC 2 and ISO 27001 together. Because ISO 42001 shares the Harmonized Structure with ISO 27001, an existing ISMS gives you most of the management system scaffolding: leadership, documented information, internal audit, and management review carry over. ISO 42001 then adds the AI-specific layer that ISO 27001 never covered, including the AI impact assessment, bias and transparency considerations, and human oversight.

The EU AI Act requires providers of high-risk AI systems to operate a quality management system. An ISO 42001-conformant AIMS is, in effect, a quality management system for AI, so a well-run AIMS is a strong foundation for AI Act readiness even though it does not, on its own, make you compliant with the Act. Treat 42001 as the operating model and the Act as one set of obligations you map into it.

SOC 2, by contrast, is an attestation against the Trust Services Criteria rather than a certifiable management system. The overlap is in evidence: access controls, change management, monitoring, and logging that support a SOC 2 report often double as evidence for an AIMS. The same Cerbera logs that show AI use is controlled can serve more than one report at once.