ISO/IEC 42001
ISO/IEC 42001 is the management-system standard for artificial intelligence. It specifies requirements for establishing and running an AI Management System (AIMS) — the organizational machinery of policy, roles, risk assessment, controls, records, audit, and improvement that surrounds your AI work. If you have seen ISO/IEC 27001, the shape is immediately familiar: it uses the same harmonized management-system structure and the same Plan-Do-Check-Act rhythm, and it is certifiable by an accredited body.
That certifiability is the whole difference from the NIST AI RMF. The NIST framework is voluntary guidance you adapt freely; nobody audits you against it and there is no certificate. ISO/IEC 42001 is a specification with auditable requirements, where “we do that informally” is a nonconformity. Both can be right for the same organization — the framework to structure thinking, the standard to prove discipline.
What a management system actually is
A management system is not a document. It is a closed loop that an outsider can inspect: you decide what you are trying to achieve, you assign someone to achieve it, you do the work in a defined way, you keep records that the work happened, you check whether it worked, and you change something when it did not. Every requirement below is a piece of that loop.
| Element | The requirement in plain terms | What an engineer sees day to day |
|---|---|---|
| Context and scope | Define what the AIMS covers and the internal/external issues and interested parties | A scope statement naming which systems, teams, and sites are in scope |
| Leadership | Top management demonstrably owns the system, not just endorses it | A named executive owner; agenda time; budget attached to AI risk work |
| AI policy | A published policy setting direction and commitments | A short document you are expected to be able to point to and follow |
| Roles and responsibilities | Assigned, communicated, documented accountability | RACI; a named owner per agent, model, and control |
| Risk assessment and treatment | A defined, repeatable method for identifying and treating AI risks | A risk register with a documented methodology, not ad hoc judgement |
| AI impact assessment | Assessing consequences for individuals, groups, and society | A separate assessment artifact per system, distinct from the risk register |
| Objectives and planning | Measurable AI objectives and plans to reach them | Targets like “100% of production agents emit approval records” |
| Competence and awareness | People doing the work are demonstrably capable | Training records, onboarding checklists, evidence of skills |
| Documented information | Controlled documents and retained records | Versioned docs, defined retention, controlled access |
| Operational controls | The actual technical and process controls, selected and justified | Tool permission gates, eval pipelines, logging, human-approval flows |
| Third-party and supplier management | Control over externally supplied models, data, and services | Vendor assessments, contract clauses, model provenance records |
| Monitoring and measurement | Evidence that controls are working, not just present | Dashboards, control metrics, periodic effectiveness reviews |
| Internal audit | Independent internal checking on a planned schedule | Someone not on your team asks you for evidence and files findings |
| Management review | Leadership reviews performance and decides changes | A recurring meeting with inputs, minutes, and decisions |
| Nonconformity and improvement | Findings get root-caused, corrected, and tracked closed | A corrective-action tracker that is actually closed out |
The standard also includes normative and informative annexes covering a set of AI-specific controls and implementation guidance, plus material on organizational objectives and risk sources. Treat those annexes as the checklist you justify your control selection against — including justified exclusions.
Relationship to ISO/IEC 27001 and to impact assessment
Two relationships matter in practice.
With 27001. 42001 is designed to sit alongside an information-security management system, sharing the same high-level structure so that context, leadership, competence, documented information, internal audit, and management review can be operated once and scoped to cover both. If you already hold 27001, a large share of the AIMS machinery exists — you are extending scope and adding AI-specific risk criteria and controls, not building from zero. If you do not, expect the management-system overhead itself to dominate the effort, and expect that overhead to be the real cost of certification.
With impact assessment. 42001 treats AI impact assessment as distinct from risk assessment, and the distinction is worth internalizing. Risk assessment asks what could go wrong for the organization. Impact assessment asks what the system does to people and society — individuals subject to its decisions, groups who may be differentially affected, and broader effects. They use different lenses and often surface different findings. Related ISO/IEC documents provide guidance on AI risk management and on impact assessment methodology; check the current numbering and status against the primary source rather than memorizing it.
What “auditable” means for an engineer
Auditors do not evaluate whether your architecture is good. They evaluate whether you did what you said you would do and can prove it. That reduces to three habits.
1. Documented procedures. For anything the standard expects you to control, there is a written description of how it is done, and reality matches it. The common failure is a procedure written for the audit that describes a process nobody follows — auditors find this quickly by asking a practitioner instead of a manager.
2. Records. A record is dated, attributable, and retained. “We review model changes” is a claim; a change record with a reviewer, a date, and the eval results attached is a record. Most of the engineering work in becoming auditable is making systems emit records as a side effect of normal operation, which is exactly what Evidence Automation is about.
3. Traceable decisions. For a given production decision, you can walk backwards: which model version, which prompt template, which policy bundle, which tool call, which human approval, which risk assessment authorized this capability in the first place. Agents make this harder and more important at the same time.
| Auditor question | Weak answer | Evidence-backed answer |
|---|---|---|
| How do you control which tools an agent can call? | “Engineers review PRs” | Versioned tool registry + policy bundle + approval record per grant |
| How do you know the model still performs adequately? | “We monitor quality” | Scheduled eval runs with stored reports and a defined threshold |
| Who approved this refund the agent issued? | “It is in the logs somewhere” | Signed approval record linked to the trace ID, queryable by date |
| How do you handle an AI incident? | “We would escalate” | Runbook, tested game-day record, closed corrective actions |
| Are your people competent to do this? | “The team is experienced” | Role competence matrix with completed training records |
Where the effort actually goes for an agent deployment
Rough distribution of effort for an organization deploying agents and pursuing certification for the first time:
| Area | Share of effort | Why |
|---|---|---|
| Management-system scaffolding | High if no 27001; low if you have it | Policy, scope, audit programme, management review, document control |
| Inventory and scope definition | Moderate, and underestimated | Nobody knows how many agents, tools, and MCP servers exist |
| Risk and impact assessment methodology | Moderate | Needs a repeatable method, not per-project improvisation |
| Operational controls for agents | Moderate to high | Identity per agent, permission gates, approvals, logging, evals |
| Evidence generation and retention | High initially, then near zero | The automation investment that pays back every cycle |
| Supplier and model provenance | Moderate | Model, dataset, and MCP-server supply chain documentation |
| Internal audit and corrective action | Recurring | Ongoing cost regardless of tooling |
Two agent-specific gaps show up in almost every first assessment. The first is non-human identity ownership: agents authenticate to systems, but access reviews cover employees only, so nobody owns the agent’s credentials or reviews its scopes. The second is scope drift: the AIMS scope was written around three known systems, and by audit time there are eleven agents because a team wired an assistant into a workflow. Automated inventory discovery fixes both, which is why it is the first section of Evidence Automation.
A first-year timeline, roughly
Certification is not a project you finish in a sprint. A realistic shape for an organization starting from an existing 27001 programme:
| Phase | Duration | Main activity | Engineering involvement |
|---|---|---|---|
| Scoping and gap analysis | 4–8 weeks | Define AIMS scope, inventory systems, map to requirements | High — you produce the inventory |
| Build and remediate | 3–6 months | Write procedures, implement controls, start generating records | High — controls and evidence pipelines |
| Evidence accumulation | 3+ months | Let the system run so records exist to sample | Low — mostly keeping jobs green |
| Internal audit and review | 4–6 weeks | Independent check, corrective actions, management review | Medium — you answer the questions |
| Certification audit | 2 stages | Documentation review, then implementation audit | Medium — interviews and evidence pulls |
| Surveillance | Ongoing | Periodic audits and continual improvement | Low if automated, high if manual |
The evidence-accumulation phase is the one that cannot be compressed with money or effort. Records must exist over a period, which is the practical argument for instrumenting agents on day one rather than when the audit is scheduled.
NIST AI RMF vs ISO/IEC 42001 vs EU AI Act
| Dimension | NIST AI RMF | ISO/IEC 42001 | EU AI Act |
|---|---|---|---|
| Nature | Voluntary framework and guidance | International management-system standard | Binding regulation |
| Binding? | No | No, unless contractually required | Yes, in scope |
| Structure | Four functions: Govern, Map, Measure, Manage | Plan-Do-Check-Act management system with annexed controls | Risk tiers plus a separate GPAI model regime |
| Output | A structured risk process and shared vocabulary | A certificate from an accredited body, plus the running system | Legal compliance; conformity assessment for high-risk |
| Scope of concern | Trustworthiness characteristics of AI systems | How the organization manages AI | What the system is used for and its effect on people |
| Who cares | Engineering, security, and risk teams; US federal-adjacent buyers | Enterprise procurement, auditors, boards | Regulators, legal, anyone selling into or affecting the EU |
| Cost profile | Low; internal effort only | Ongoing: surveillance audits, document control, internal audit | Depends entirely on tier; high-risk is substantial |
| Best used for | Structuring the actual risk work | Proving organizational discipline repeatably | Determining what you are legally required to do |
They compose cleanly: the Act sets the requirement, 42001 gives the operating system, the AI RMF gives the risk method, and your telemetry gives the evidence.
When certification is worth it, and when it is theater
Honest version.
Worth pursuing when:
- Enterprise or public-sector customers ask for it in security questionnaires and it is blocking deals. This is the most common real reason and it is a perfectly good one.
- You already run 27001, so marginal cost is modest and the two systems share machinery.
- You are heading into EU AI Act high-risk territory and need a quality-management system anyway.
- Your AI work is spread across many teams and you genuinely need a forcing function to impose consistent practice.
Theater when:
- The scope is drawn so narrowly that it excludes the systems that actually carry risk. A certificate covering one pilot service while eight production agents sit outside scope is a marketing asset, not a control.
- The procedures are written for the auditor and diverge from how the team works. This is worse than no certification, because it institutionalizes a fiction and consumes the budget that could have bought real controls.
- Nobody can name a customer or regulator who asked, and it is being pursued as a signal.
- The organization treats the certificate as the goal and lets controls decay between surveillance audits.
What to build next
If you want to be useful on a 42001 programme without becoming a compliance specialist, build these three things for a system you own: an automated inventory of agents, tools, and models; a trace and approval record store that answers “who authorized this action” in one query; and a control-to-check mapping where each control has an automated test and a dashboard tile. That is exactly the scope of Evidence Automation and of Lab 4.
Two habits that make you the person the programme actually relies on:
- Make records a byproduct. Any control whose evidence requires a human to remember to do something will fail at audit. Push it into CI, into the deployment pipeline, or into the runtime — then the evidence exists whether or not anyone was paying attention.
- Write the justification, not just the decision. When you exclude a control, cap a scope, or accept a residual risk, the auditable artifact is the reasoning, dated and attributed. Engineers habitually record the outcome and drop the reasoning, and it is the reasoning that gets asked for.
Get those two right and the rest of an AIMS is paperwork that someone else can maintain.