ISO 42001 Requirements: A Practical Checklist

ISO 42001 is the first international standard built specifically for AI management systems. If your company builds, deploys, or resells AI-enabled products, and a customer, regulator, or procurement team has started asking how you govern that AI, this standard is the reference point they're increasingly working from. It's new, it's growing fast, and most organizations approaching it have no idea what "compliant" actually requires in practice.

This checklist breaks ISO 42001 down into the concrete requirements auditors and customers will actually ask about. It won't replace a full readiness assessment, but it will tell you where you stand and what to fix first.

What ISO 42001 Actually Covers

ISO 42001 sets requirements for an Artificial Intelligence Management System, or AIMS. Like ISO 27001 does for information security, it asks you to prove that AI risk is identified, governed, and continuously managed, not just documented once and forgotten. It sits alongside, and increasingly overlaps with, obligations under the EU AI Act and the NIST AI Risk Management Framework. None of those three requires the exact same paperwork, but organizations that get ISO 42001 right are usually most of the way toward satisfying the other two as well.

The Checklist

1. AI Policy Signed Off by Leadership

You need a documented AI policy that leadership has actually reviewed and approved, not a boilerplate statement pulled from a template. It should state your organization's stance on acceptable AI use, risk tolerance, and who owns AI-related decisions.

2. Defined Scope of the AI Management System

Which AI systems, teams, and processes fall inside your AIMS. Auditors will ask you to justify what's excluded as much as what's included, so vague scoping is one of the fastest ways to fail an audit.

3. Roles and Responsibilities Assigned

Someone needs to own AI governance day-to-day. This doesn't have to be a full-time hire, but it does have to be a named person or role with real authority to enforce the policy, not just report on it.

4. AI System Inventory

A living list of every AI system in scope: what it does, what data it touches, who built it (in-house or third-party), and what decisions or outputs it produces. Most companies underestimate this list badly the first time they build it, especially once embedded models and vendor tools get counted.

5. Risk Assessment Process

A repeatable method for identifying and scoring AI-specific risks, things like bias, model drift, data quality, misuse, and downstream harm to individuals. This has to be a process you run on a schedule, not a one-time exercise you point to during the audit.

6. Impact Assessments for High-Risk Systems

For AI systems that could meaningfully affect people (hiring decisions, credit decisions, health outcomes, and similar), you need a documented assessment of the potential impact before and during deployment. This is also where ISO 42001 overlaps heavily with EU AI Act high-risk system obligations.

7. Data Governance Controls

Where training and operational data comes from, how it's vetted for quality and bias, and how it's protected. If you're already SOC 2 or ISO 27001 certified, you have a head start here, but AI-specific data controls (like training data provenance) go beyond typical security controls.

8. Third-Party and Supply Chain Management

Most companies don't build their own foundation models, they license, fine-tune, or wrap someone else's. ISO 42001 requires you to assess and manage the AI-specific risk that comes with those vendors, not just their security posture.

9. Human Oversight Mechanisms

A documented way for humans to review, override, or stop an AI system's output or decision. Auditors want to see this is actually usable in practice, not a checkbox that exists on paper only.

10. Incident Response for AI-Specific Failures

Your existing security incident response plan probably doesn't cover a model producing biased outputs, hallucinating in a customer-facing context, or drifting out of spec. ISO 42001 expects a defined process for detecting, logging, and responding to these failure modes specifically.

11. Performance and Continuous Monitoring

Ongoing monitoring of how deployed AI systems actually perform against their intended purpose, including tracking model drift over time. This is a control you run continuously, not something you can produce as a snapshot document.

12. Internal Audit Program

Like other ISO management system standards, 42001 requires periodic internal audits of the AIMS itself, checking that the controls above are operating as designed, not just documented.

13. Management Review Cycle

Leadership needs to formally review the AIMS on a set cadence: what's working, what risks have changed, what needs investment. This is the governance loop that proves the system is alive, not a binder on a shelf.

14. Corrective Action Process

A documented way to track findings (from audits, incidents, or monitoring) through to resolution. Auditors will sample this trail, so gaps between "we found a problem" and "we fixed it" need to be traceable.

Where Most Companies Get Stuck

The controls that trip people up aren't the policy documents, those are straightforward to write. It's the operational pieces: building a complete AI system inventory, running risk assessments on a real cadence, and proving human oversight actually functions rather than exists in a slide deck. These require you to understand how AI is actually used across your organization, which is often murkier than leadership expects.

If you're evaluating whether your organization is ready for a formal ISO 42001 audit, a gap assessment against this checklist is the fastest way to find out where the real work is. Our ISO 42001 readiness assessment maps your current AI governance against the standard's requirements and gives you a prioritized list of what to fix before an auditor sees it. It also fits naturally alongside a broader compliance program if you're managing ISO 42001 next to SOC 2, ISO 27001, or other frameworks at the same time.

If you want to talk through where your AI governance stands today, get in touch and we'll walk you through what a readiness assessment would look like for your systems.

How the certification process actually runs

The checklist above tells you what to build. It does not tell you what the audit itself looks like, and that gap is where most first-timers lose three months. ISO 42001 follows the same certification mechanics as every other ISO management system standard. You engage an accredited certification body, they run a Stage 1 audit, then a Stage 2 audit, then you hold a certificate for a three-year cycle with surveillance audits in between.

Stage 1 is a documentation review. The auditor reads your AI policy, your scope statement, your risk assessment methodology, your AI system inventory, and your internal audit plan. They are checking whether the management system exists on paper and whether the scope you claim is coherent. Stage 1 findings are usually cheap to fix: a scope statement that does not name the legal entity, a risk methodology that scores likelihood without defining the scale, an inventory with no owner column. Expect Stage 1 to take one to two days for a company under 100 people, and expect a gap of four to eight weeks before Stage 2 so you can close what they raise.

Stage 2 is where they test whether the thing runs. The auditor samples. They will pick two or three AI systems off your inventory and follow them end to end: the impact assessment, the approval record, the monitoring output, the incident log, the human oversight step. If your inventory lists eleven systems and the auditor picks the two you built last quarter, the ones with no documented pre-deployment assessment, the finding is not "you are missing a document." The finding is that your process does not operate consistently, which is a major nonconformity and blocks the certificate until you clear it.

After certification, surveillance audits run annually and are narrower, usually one day, focused on management review minutes, corrective actions, internal audit results, and any change to the scope. Recertification at year three is a full Stage 2 again.

What auditors actually ask for, control by control

Auditors do not ask "do you have data governance." They ask for artefacts. Here is the shape of the questions we see against the harder controls.

On the AI system inventory: "Show me how a new AI system gets added to this list. Who triggers it? What stops an engineer from shipping a feature that calls a third-party model without the inventory being updated?" The honest answer for most companies is "nothing stops them," and the fix is a gate in an existing process rather than a new one. A required field in your change management ticket template, or a review step at design sign-off, is enough. What is not enough is a quarterly email asking teams to self-report.

On impact assessments: "Show me the assessment for this system, dated before the deployment date." That date comparison catches a lot of organizations. Assessments written retroactively in the two weeks before the audit are obvious, because the deployment ticket has a timestamp and the assessment does not match it. If you have already shipped systems without assessments, say so, log it as a corrective action with a remediation plan, and complete the backlog. Auditors respond far better to a disclosed and tracked gap than to a document that looks fabricated.

On human oversight: "Walk me through the last time a human overrode this system." If nobody has ever used the override, the auditor will ask how you know it works. A tested override with a logged result, even from a staging exercise, closes that question. A button in an admin panel that nobody has clicked since it was built does not.

On monitoring: "What is the threshold that triggers action, and what happened the last time it was crossed?" Monitoring dashboards that nobody watches are the single most common weak control in AI governance. The standard does not require sophisticated drift detection. It requires that you defined what "performing as intended" means, that you measure it, and that a defined person acts when the measure moves.

A worked example

Take a 60-person B2B SaaS company with three AI surfaces: a support copilot built on a commercial foundation model, a churn-prediction model trained in-house on customer usage data, and an embedded summarisation feature from a vendor that the product team turned on eighteen months ago and largely forgot about.

The copilot is the one everyone worries about, and it is the easiest to govern, because the vendor publishes model cards, the data flow is documented, and the output is advisory to a human agent. The churn model is riskier than it looks, because its output feeds account-manager decisions about which customers get renewal attention, which means a systematically biased model quietly degrades service for a subset of customers. The forgotten summarisation feature is the actual audit problem: no owner, no assessment, no monitoring, and no one who can say what data it sends where.

In an engagement like this the first month is inventory and ownership, not policy writing. The policy takes a week. Finding out that a fourth AI feature exists in a beta flag, and that the vendor contract behind it has no AI-specific terms, takes longer and matters more.

Reusing your ISO 27001 work

If you already hold ISO 27001, a meaningful portion of ISO 42001 is already built. The clause structure is shared: context, leadership, planning, support, operation, performance evaluation, and improvement all follow the same Annex SL pattern, so your existing management review cadence, internal audit programme, corrective action register, and document control process extend to cover the AIMS rather than being rebuilt. ISO 27001 gives you 93 Annex A controls plus clauses 4 to 10, and the clause work is the part that transfers almost wholesale.

What does not transfer is the AI-specific risk content. Information security risk asks what happens if data is disclosed, altered, or unavailable. AI risk asks what happens if the system is accurate, available, confidential, and still produces an outcome that harms someone. Those are different questions and they need a different risk register, even if the scoring scale is shared. Companies that try to bolt AI risks onto their existing information security risk register end up with entries like "model produces incorrect output" scored against a confidentiality impact scale, which satisfies nobody.

One practical piece of ordering advice: if you are doing both, run ISO 27001 first or run them together with a single management system and two scopes. Running 42001 alone, without an existing management system underneath it, means you are building the whole Annex SL scaffolding for one standard, which is more work than most people budget. Our ISO 27001 implementation work is often the cheaper entry point for exactly this reason.

What this costs, and what drives it

Certification body fees are separate from readiness work, the same split that exists in SOC 2. The certification body charges audit days, and the number of days scales with headcount, number of sites, and the complexity of your AI estate. Readiness cost is driven by four things: how many AI systems you actually have once you count honestly, whether you already run a management system, whether your AI systems are third-party or built in-house, and whether any of them fall into a high-risk category that pulls in impact assessment work.

The cost driver people miss is engineering time. Logging model inputs and outputs for monitoring, building an override path that records who overrode what and why, and instrumenting a drift metric are engineering tickets, not consulting deliverables. Budget sprint capacity, not just a consulting fee. We publish fixed-scope readiness pricing on our pricing page so you can separate the advisory number from the internal number before you go to your board.

When you should not do ISO 42001

This is the section most vendors leave out. There are several situations where paying for ISO 42001 readiness is the wrong call right now.

Nobody has asked, and you have no EU exposure. If your AI feature is a nice-to-have, your buyers are North American mid-market, and no contract, questionnaire, or regulator has raised it, certification is a cost with no attached revenue. Write the AI policy, build the inventory, and stop there. Those two artefacts answer most of the AI questions currently appearing in vendor security questionnaires, and they cost you a couple of weeks rather than a programme.

You are a pure deployer of a single commercial model. If your entire AI surface is a chat feature calling a major provider's API, with no training on customer data and no automated decisions about people, a well-written AI usage policy plus your vendor's documentation plus a line in your trust centre will satisfy most buyers. Certifying a management system to govern one API call is disproportionate.

Your SOC 2 or ISO 27001 is not done. Buyers who ask about AI governance almost always ask about information security first. If you have neither, do the security framework first. An ISO 42001 certificate on top of no security attestation reads oddly to a procurement team and does not unblock the deals you are actually losing.

Your product is pre-revenue and the model changes weekly. A management system governs a stable process. If you are still deciding whether the feature ships, you will certify a process you abandon two quarters later and pay for surveillance audits against a scope that no longer describes the company.

The case for doing it now is narrower and clearer: you sell into EU customers or regulated buyers, your AI makes or materially influences decisions about individuals, a named deal is stalled on an AI governance question, or your own board or insurer has asked for evidence. If one of those is true, the programme pays for itself in deal velocity. If none of them is true, a gap assessment is worth doing and a full certification push probably is not.

What certification does not answer

A certificate proves you run a management system. It does not prove your model is accurate, fair, or safe, and sophisticated buyers know that. Expect follow-up questions that live outside the standard: whether customer data is used for training, whether prompts and outputs are retained by your model vendor and for how long, whether one tenant's data can appear in another tenant's output through a shared vector store or cache, and what your contractual position is if the model produces something defamatory or wrong in a regulated workflow.

Those are answerable, and the answers belong in your trust centre and your DPA rather than in your ISO scope statement. Preparing them alongside the certification work saves you the awkward gap where you hold a certificate and still cannot answer the first technical question a buyer asks. If you want help working out which of these applies to your product, talk to us before you commit to a certification body, because the scope you set at the start is expensive to change later.