ISO 42001 vs ISO 23894: which one an auditor tests and which one guides the work
When a customer questionnaire, contract or regulator asks for ISO/IEC 42001, the first thing to settle is that ISO/IEC 42001:2023 is the certifiable AI management system, with requirements in clauses 4 to 10. ISO/IEC 23894:2023 is AI risk management guidance, and ISO does not certify against it. Your team does not need 23894 certified to meet 42001, but it may be the method you use to meet 42001's risk clauses. The organization owns its risk decisions, including what risk it accepts and what it treats. An implementation partner can prepare the risk register, the assessment records and the treatment plans, but cannot make those decisions for you. Only an independent certification body issues a certificate, after its own audit.
ISO/IEC 42001 requires an AI risk assessment in clause 6.1.2 and AI risk treatment in clause 6.1.3, but it does not prescribe a method. It says organizations may combine generally accepted frameworks, other International Standards and their own experience. ISO/IEC 23894 is one accepted source of method, and it treats risk management as a separate activity from the AI system impact assessment covered by clause 6.1.4 and Annex A.5. Before you commit, confirm with the certification body which risk method it expects to see documented, and whether it accepts 23894 as the reference. Ask it to name the records it will sample, such as the risk criteria, the risk owner for each AI system and the justification for each treatment decision.
A practical check is to read your draft risk procedure against the clause wording and ask whether every requirement has a named owner, a defined method and a dated record. If the answer is yes, 23894 is a useful guide for building that procedure, not an extra certification target. If the answer is no, the gap is in your management system, and adding 23894 alone will not close it. Where your customers also use NIST frameworks, the NIST AI Resource Center publishes crosswalks that map ISO/IEC 23894 and ISO/IEC 42005 to the NIST AI RMF, which can help you show one set of risk records answers several questions.
Which standard covers what: a side-by-side comparison of ISO 42001 and ISO 23894
This table compares ISO/IEC 42001 and ISO/IEC 23894 on status, certification, structure, risk content, publication date and the evidence each one leaves behind. Read it as a split of responsibilities: 42001 defines what your AI management system must contain, while 23894 offers a method for working through AI risk inside that system.
| Dimension | ISO/IEC 42001:2023 | ISO/IEC 23894:2023 |
|---|---|---|
| Status | Requirements standard that specifies what an AI management system must establish, implement, maintain and improve | Guidance standard on AI risk management with recommendations, not certifiable requirements |
| Certification | Basis for a certification audit by an external certification body; ISO does not certify organizations | Not the basis of a certification audit; ISO does not certify against it, so organizations use it as a method reference |
| Structure | Harmonized clauses 4 to 10 plus Annex A controls (38 controls in nine objective areas) and Annex B implementation guidance | Risk process guidance covering context, assessment, treatment, monitoring and communication of AI risk |
| Risk and impact content | Clauses 6.1.2 (AI risk assessment), 6.1.3 (AI risk treatment) and 6.1.4 (AI system impact assessment) state what must happen | Explains how to perform the risk assessment and treatment activities that 42001 requires, and treats impact assessment separately |
| Publication date | 18 December 2023, edition 1 | 6 February 2023 |
| Evidence you must produce | Statement of applicability, AI risk assessment and treatment records, impact assessment records, objectives, competence records, internal audit and management review results | Documented risk method and results that you can point to as the basis for the 42001 risk records; the standard itself is not the evidence |
| NIST AI RMF crosswalk | GOVERN 1.3 and GOVERN 1.4 (risk processes and risk tolerance) map to 42001 clauses 6.1.1 to 6.1.3 and 8.3, not to Annex A controls | Crosswalk to the NIST AI RMF is published by the NIST AI Resource Center, so confirm the mapped subcategories in the crosswalk document before citing them |
How to run an AI risk assessment with ISO 23894 inside the ISO 42001 process
This sequence shows how an organization can use the risk management guidance in ISO/IEC 23894 inside its ISO/IEC 42001 AI management system, from setting risk criteria through to the treatment decisions and reviews that feed impact assessment.
Set risk criteria and tolerance from the AI policy
Leadership and the people who own the AI policy define how AI risks will be judged, including the likelihood and impact scales and the level of risk the organization will accept. The criteria should follow from the AI policy set under A.2 and the leadership commitments in clause 5, so that each later decision traces back to stated direction. The step is done when the criteria are written down, approved by the accountable owner and available to everyone who will score risks. The organization sets its own scales and tolerance, and it should confirm the wording with its auditor before it treats the criteria as settled.
Identify AI risk sources and objectives
The team lists the AI-related objectives the organization is pursuing and the sources that could block them, such as data quality problems, model behavior, third-party components, misuse and changes in the operating context. Annex C of ISO/IEC 42001 lists potential AI-related objectives and risk sources and is a useful starting checklist, though it is informative rather than a required list. The output is a register of risk sources linked to the objectives and AI systems they touch. Each entry names an owner for follow-up, which shows the register is maintained rather than produced once.
Analyze and evaluate each risk
For each identified risk, the team estimates its likelihood and consequences using the criteria from the first step, then compares the result with the tolerance the organization has set. ISO/IEC 23894 gives guidance on how to structure this analysis, and the organization can combine it with its own method and experience, as ISO/IEC 42001 allows for processes such as risk management. The output is a ranked risk list showing which risks are within tolerance and which need treatment. Analysts record their reasoning so that a reviewer can follow how each score was reached.
Select and record risk treatments
For risks above tolerance, the organization chooses how to treat them, for example by changing the system, adding controls, restricting use, adding monitoring or accepting the residual risk with a named approver. Clause 6.1.3 requires the organization to record its treatment decisions and to justify which Annex A controls it includes or excludes in the statement of applicability. The output is a risk treatment plan linked to specific controls and to the statement of applicability. The step is complete when every treatment has an owner, a status and a recorded justification.
Feed the results into impact assessment
Risk assessment and AI system impact assessment are separate activities in ISO/IEC 42001. Under clause 6.1.4 and the Annex A.5 controls, the organization assesses the effects of an AI system on individuals, groups and society, which can surface harms that a risk register would not capture. The risk results inform that assessment, and findings from the impact assessment can in turn add new risk sources. The output is a cross-reference between the risk register and the impact assessment record, so an assessor can trace a risk to the impact it relates to.
Monitor, review and update the risk record
Under clause 9, the organization monitors its risks and treatments and reviews them on a schedule it sets for itself, and again when an AI system, its data, its use or its operating context changes. Internal audit and management review examine whether the process is working. The output is dated review records showing decisions taken, risks closed or reopened and any changes to criteria. The organization should confirm with its certification body how it expects these review records to be presented, since no fixed review interval is prescribed here.
Where the NIST crosswalks map ISO 42001 and ISO 23894
ISO/IEC 42001 sets management system requirements, while ISO/IEC 23894 gives risk management guidance. The crosswalks below show how NIST AI RMF and related frameworks line up with both, so a team can see where a single risk activity satisfies several reference points. Use them to read across frameworks, not as proof of conformity.
Microsoft crosswalk to ISO/IEC 42001
The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft, maps GOVERN 1.3 and GOVERN 1.4, which cover risk management processes and risk tolerance, to ISO/IEC 42001 clauses 6.1.1 to 6.1.3 and 8.3. It does not map them to Annex A controls. For ISO 42001 work, this means risk tolerance and risk processes sit in the management system clauses, so the evidence is the documented risk process, its approvals and the operational records that show it runs. Check that the crosswalk references the FDIS text, since final published wording may differ.
INCITS/AI crosswalk for ISO/IEC 23894
The INCITS/AI crosswalk maps the revised ISO/IEC 23894 to the NIST AI RMF, dated 14 August 2025. ISO/IEC 23894 is the guidance a team can use to design AI risk assessment and treatment, and this crosswalk shows which NIST functions each of its risk activities supports. Use it to confirm that your risk register covers the same ground as both references. Because 23894 is guidance rather than a certifiable standard, the crosswalk helps you explain your risk method to an assessor.
INCITS/AI crosswalk for ISO/IEC 42005
A second INCITS/AI crosswalk, also dated 14 August 2025, maps ISO/IEC 42005 on AI system impact assessment to the NIST AI RMF. ISO 42001 treats impact assessment as its own activity under clause 6.1.4 and Annex A.5, separate from risk assessment. This crosswalk helps a team see where impact findings feed into the NIST Map and Measure work, so that impact assessments and risk assessments are not run as duplicate exercises. Confirm the file version before you cite it in an audit file.
HITRUST AI risk management assessment mapping
The HITRUST AI Risk Management Assessment uses 51 curated controls mapped to the NIST AI RMF and ISO/IEC 23894:2023, and it adds guidance from the OWASP Top 10 for LLMs. Teams in healthcare or other HITRUST-driven sectors can use it to see one control set that reflects both the NIST functions and the ISO 23894 risk guidance. It is a separate assessment, not an ISO 42001 certification, so it cannot stand in for the clause 9 audit evidence an ISO 42001 certification body reviews.
Crosswalks do not replace audit
A crosswalk is a reading aid that shows where two frameworks describe similar activities. It does not show that your system conforms to either one, and an accredited certification body still decides what counts as evidence for ISO/IEC 42001. Use crosswalks to plan documentation, explain your design to an auditor and spot gaps, then test your own records against the requirements. Ask any consultant to show their working on each mapping line they claim, not only the summary.
Check crosswalk versions before relying on them
Crosswalk files are published by NIST AI Resource Center contributors and are revised as the underlying standards change. Before you rely on a mapping, confirm the file name, date and the standard edition it cites, and compare it with the current ISO/IEC 42001 and ISO/IEC 23894 text you hold. A mapping built on an earlier draft may point to clause numbers or subcategories that no longer match. Record the version you used in your statement of applicability and your management review notes.
Why the auditor tests the management system and not the risk guidance
A certification audit tests conformity with the requirements of ISO/IEC 42001 and with the organization's statement of applicability, which clause 6.1.3 requires to list the necessary Annex A controls and justify including or excluding each one. The auditor does not grade the organization against ISO/IEC 23894. Instead, the auditor asks for documented risk criteria, risk assessment records, risk treatment decisions, AI system impact assessments and management review minutes that show the AI management system runs as a closed loop. Expect to show who approved the risk acceptance thresholds, which risks were assessed, which treatment was chosen for each, and how the outcome fed back into objectives. Start by checking that every risk treatment decision traces to a line in the statement of applicability.
ISO/IEC 23894:2023 is guidance on AI risk management, not a certification scheme, so no auditor certifies an organization against it. An organization that follows it should be able to show how its own risk method meets the requirements of clauses 6.1.1 to 6.1.4 and 8.3 of ISO/IEC 42001. A practical check is to take one risk through the full cycle, from identification to treatment to residual risk sign-off, and confirm that each step produces a record an auditor can sample. If the method is borrowed from 23894, the organization owns the decision to adopt it and must document that choice.
Certification sits outside ISO itself. ISO does not certify organizations, and accreditation of certification bodies is voluntary. ISO/IEC 42006:2025, published 7 July 2025, adds requirements on top of ISO/IEC 17021-1 for bodies certifying AI management systems, so the rules the auditor follows are more specific than a general management system audit. As of Global ACI-FMRA-001 version 3.3 (August 2026), ISO/IEC 42001 is not listed as an endorsed sub-scope of the Global ACI recognition arrangement. Ask each certification body in writing whether its accreditation covers ISO/IEC 42001 and which accreditation body issued it, before you commit to a scope.
What compliance, risk and engineering teams own when they use ISO 42001 and ISO 23894
The executive or AI governance owner holds final accountability for the AI management system. ISO/IEC 42001 expects top management to set the AI policy, define the AI objectives and review how the system performs, so this role decides how much AI risk the organization is willing to carry. The organization makes these decisions itself. An implementation partner can prepare the briefing papers and draft policy text, but the signed decisions must come from the organization.
- Risk appetite: Approve the criteria that separate acceptable AI risk from risk that needs treatment or escalation, drawing on the risk criteria approach described in ISO/IEC 23894.
- AI policy: Sign the AI policy and confirm it aligns with other organizational policies, such as information security.
- Objectives and resources: Set measurable AI objectives and fund the people and tools that the risk and engineering teams need.
- Management review records: Keep minutes showing that leadership reviewed AI risk results, incidents and internal audit findings.
Before the certification body's stage 1 review, confirm that every decision in this tab is dated, signed and traceable to a meeting or approval record.
The compliance lead owns the statement of applicability and the link between ISO/IEC 42001 requirements and the evidence that proves them. Clause 6.1.3 requires the organization to justify including or excluding each Annex A control, so this role decides which controls apply and records why. ISO/IEC 23894 does not replace that work. It informs the risk treatment logic that shapes those justifications.
- Statement of applicability: Maintain the list of Annex A controls, the inclusion or exclusion reason for each, and the owner of each control.
- Clause mapping: Track how risk assessment outputs under clauses 6.1.1 to 6.1.3 feed into controls and into the impact assessment under clause 6.1.4.
- Internal audit program: Schedule internal audits and record findings and corrective actions.
- Certification body readiness: Confirm which evidence the certification body will sample and that every item has an owner and a retention period.
The independent certification body, not the compliance lead or any consultant, decides whether the organization is certified.
The risk owner runs the AI risk assessment and treatment cycle. ISO/IEC 23894 gives guidance on this activity, and ISO/IEC 42001 treats AI risk assessment and treatment as required actions under clause 6.1. The risk owner selects the method, identifies risk sources, rates likelihood and consequence, and proposes treatments. Risk acceptance stays with the accountable manager named by the organization.
- Risk register: Record each AI risk with its source, affected stakeholders, rating, treatment option and residual risk.
- Risk treatment plan: Assign each treatment to an owner with a due date and a check on whether it worked.
- Risk acceptance records: Document who accepted each residual risk, on what basis, and when it must be reviewed.
- Monitoring triggers: Define the events, such as model drift or a serious incident, that force a risk reassessment.
An implementation partner can prepare the risk register template and the evidence trail. The organization must still populate and own the content.
The engineering and platform team turns risk decisions into controls that operate on real AI systems. This includes the data pipelines, model versions, deployment environments and logging configuration. ISO/IEC 42001 life cycle and data controls in Annex A depend on what engineers build and record, and ISO/IEC 23894 risk guidance becomes useful only when its treatments appear in configuration, tests and runbooks.
- Technical controls: Implement the safeguards chosen by the risk owner, such as access restrictions, input validation and human review gates.
- Verification evidence: Keep test results, validation reports and model cards tied to each release.
- Event logs: Configure and retain logs that let the team reconstruct AI system behavior after an incident.
- Change records: Link each model or data change to a risk reassessment when the change affects the risk register.
If self-hosted open-source tooling produces this evidence, confirm with the vendor and your own environment exactly which logs, versions and retention settings the tool supports before you claim them in the statement of applicability.
Where ISO 42001 risk work usually stalls, and how to avoid it
ISO/IEC 42001 requires an AI risk assessment and treatment, and ISO/IEC 23894 explains how to do that work well. Most stalls come from treating the guidance as a checklist, or from keeping risk records apart from the policy, the impact assessments and the systems they describe.
Treating 23894 as a scoring checklist
ISO/IEC 23894 is guidance, not a set of requirements that an auditor scores line by line. Teams that copy its headings into a spreadsheet often produce risk entries that nobody uses to make decisions. The auditor will look for evidence that your organization applied a sound process to its own AI systems, so check whether each risk record changed a design, a deployment or an owner's decision.
Risk assessment detached from policy
Clause 6.1.2 asks for an AI risk assessment, but the results should trace back to the AI policy and the AI objectives under clause 6.2. When the risk register is maintained by a separate team with its own criteria, the objectives and the risk picture drift apart. Confirm that each objective names the risks it addresses and that each high risk points to an objective or a control decision.
Risk and impact records merged
Clause 6.1.4 and Annex A.5 treat AI system impact assessment as its own activity, separate from risk assessment. Combined templates can hide impacts on individuals, groups and society behind generic likelihood scores. Keep distinct records for each, and cross-reference them so a reviewer can see which risks came from which impacts.
No documented risk tolerance
Without a stated risk tolerance, every risk treatment decision becomes a judgment call that depends on who is in the room. The fix is a short, approved statement of which risk levels are accepted, which need treatment and who may accept residual risk. Management review under clause 9.3 is the natural place to confirm that the tolerance still matches the organization's appetite.
Statement of applicability without reasons
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls and justifies including or excluding each one. Many drafts list the controls and mark them applicable or not, with no reasons. Write one or two sentences per control that tie the decision to a risk treatment outcome, so an exclusion can be defended against the risk register.
Risk register disconnected from inventory
A risk register that does not name the AI systems it covers cannot show that every system was assessed. Link each risk entry to an inventory record that lists the system's owner, purpose, data sources, third-party components and deployment status. When a system is added, changed or retired, the register should be updated in the same change.
Questions buyers ask about ISO 42001 and ISO 23894
Is ISO 23894 required to get ISO 42001 certified?
No. ISO/IEC 42001 does not name ISO/IEC 23894 as a requirement, so no standard obliges you to use it. What the certification body will check is that you have a documented AI risk process that meets the requirements of clauses 6.1.2 (AI risk assessment) and 6.1.3 (AI risk treatment) of ISO/IEC 42001. Many organizations use ISO/IEC 23894 as the guidance behind that process because it describes risk management activities in detail. You can meet clauses 6.1.2 and 6.1.3 with other frameworks or your own method, provided the method is documented, applied consistently and produces records an auditor can sample.
Can we use ISO 23894 alone without ISO 42001?
Yes, for guidance. ISO/IEC 23894:2023 gives AI risk management guidance that any organization can apply without adopting a management system. However, it is not a certifiable standard, so no certificate can be issued to ISO/IEC 23894. If a customer or contract asks for ISO 42001 certification, guidance alone will not meet that request. Using 23894 without 42001 suits teams that need a structured risk method for internal decisions, product reviews or supplier assessments.
Who issues the ISO 42001 certificate?
An independent certification body issues it, not ISO and not your consultant or implementation partner. ISO states that it does not certify organizations and that external certification bodies do, with accreditation of those bodies being voluntary. ISO/IEC 42006:2025 adds requirements for bodies certifying AI management systems on top of ISO/IEC 17021-1. Ask any certification body whether its accreditation covers ISO/IEC 42001 before you contract with it, because accreditation scope is confirmed per body and per accreditor.
How should we use the NIST crosswalks for ISO 42001 and ISO 23894?
Use the crosswalks as a mapping aid, not as proof of conformity. NIST's AI Resource Center publishes crosswalks that map ISO/IEC 23894 (revised) and ISO/IEC 42005 to the NIST AI RMF, both dated 14 August 2025, and a crosswalk contributed by Microsoft maps the NIST AI RMF to ISO/IEC FDIS 42001. Read the mapping rows for your use case and check each one against the clause text in your own copy of the standard. One example is the crosswalk's mapping of GOVERN 1.3 and GOVERN 1.4 on risk tolerance to ISO/IEC 42001 clauses 6.1.1 to 6.1.3 and 8.3 rather than to Annex A controls. Record which mapping you relied on and why, so an auditor can follow the reasoning.
Can our own team run the ISO 42001 risk work in-house?
Yes. Nothing in ISO/IEC 42001 requires an outside party to perform risk assessment or treatment, so an internal team can do it if it has the competence and time. The organization keeps ownership of the decisions: which risks are accepted, which treatments are chosen and who signs off residual risk. In-house teams usually need people who understand the AI systems in scope, someone who can run a consistent risk method, and a way to keep records current as systems change. Outside help is an option when that skill set or capacity is missing, but the decisions stay with your organization.
What does the risk work need from our team?
It needs three things: named owners, access to AI system records and protected review time. Each AI system in scope needs an accountable owner who can explain its purpose, data and users. Risk assessment and treatment depend on records such as model documentation, data sources, test results and incident history, so the team must be able to read them. Regular review sessions are also needed, both when a system changes and on a set schedule. Confirm with your certification body how often it expects these reviews to occur and what records it will sample, because those expectations shape the effort.
Will an implementation partner guarantee our ISO 42001 certificate?
No. An implementation partner can prepare systems, documentation and evidence for the assessment, but it does not decide the outcome. Only the independent certification body decides whether the management system conforms, and it will sample your records and interview your staff. Any partner that promises a certificate has blurred that line. When you compare partners, ask what they will deliver, who owns each control and record after handover, and how they keep the work separate from the certification body that will assess you.
How to choose a partner for ISO 42001 risk work and what to ask before signing
An implementation partner can help build the AI risk process that feeds ISO/IEC 42001 clauses 6.1.2 to 6.1.4, but the organization keeps ownership of its risk decisions and the certification body keeps the audit. The cards below set out what to check and confirm in writing before any work starts.
Experience with 42001 risk clauses
Ask for evidence that the partner has designed AI risk assessment, risk treatment and impact assessment processes that map to clauses 6.1.2, 6.1.3 and 6.1.4 of ISO/IEC 42001, not only generic risk registers borrowed from information security. Ask how they use ISO/IEC 23894 as method guidance while keeping the management system requirements as the audit baseline. Confirm in writing which named people did comparable work and how their experience is tested.
Written fixed scope and deliverables
Most engagements are fixed-scope, so the agreed scope, deliverables and timelines should be written down before work begins. Confirm which AI systems are in scope, which clauses and Annex A controls the work touches, and what counts as a finished deliverable. Ask what changes require a new written scope and how additional work is priced. A quote should follow directly from that written scope.
Split between partner and organization
Agree in writing who prepares each artifact and who owns each decision. The partner may draft the risk method, populate the register and prepare evidence, but risk acceptance, risk tolerance and the statement of applicability decisions under clause 6.1.3 stay with the organization's accountable owners. Ask for a responsibility matrix that names both parties for each risk activity, and confirm that no sign-off authority transfers to the partner.
Independence from the certification body
Ask the certification body which consultants it accepts without conflict of interest, and whether a consultant who designed the risk process can also be part of the audit team. ISO does not certify organizations, and accreditation of certification bodies is voluntary, so confirm the accreditation status of the body you plan to use. Get the partner's written confirmation that it will not issue or influence certification decisions.
Evidence handed over at closeout
Before signing, specify the artifacts you will own at the end: the AI risk register, the documented risk assessment and treatment method, the criteria used for risk acceptance, and inputs for the statement of applicability. Ask for the files in editable formats, the version history and the owner of each document. Confirm that your team can maintain the register after the partner leaves.
Support after the audit
Risk work is not finished at certification. Ask what the partner provides for internal audit support, management review inputs and periodic risk reassessment, and whether that is covered by a separate retainer. Confirm how changes to AI systems trigger risk reassessment and who is responsible for it. Ask for the terms in writing before the audit, so ongoing support is not assumed.
How DeployOpen prepares ISO 42001 risk evidence for an assessment
DeployOpen works on the evidence side of ISO 42001 vs ISO 23894: management system versus AI risk guidance. We prepare the systems, risk records and documentation that an independent certification body will review, while the organization keeps ownership of its AI risk decisions and controls.
How we scope
- Engagements are fixed-scope, with the systems, AI use cases and risk records covered agreed in writing before work starts.
- The written scope states which clause 6 risk assessment and treatment records, and which AI systems, are included in the work.
- The organization confirms which risk guidance it adopts, since ISO/IEC 23894 is guidance rather than a certifiable requirement.
How we build
- We configure self-hosted open-source tooling in the client's own infrastructure to hold risk registers, treatment decisions and their approvals.
- We set up logging and change records so risk assessments can be traced to the AI systems and data they describe.
- We help map the organization's existing risk method to the clause 6.1 structure so the same records serve the management system.
How we hand over
- Deliverables include documented risk assessment and treatment procedures, populated registers and a record of who approved each decision.
- We provide a cross-reference showing where each record answers a clause requirement, so the assessor can follow the evidence.
- Ownership of the risk register and its upkeep is transferred to named staff inside the organization.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
- Security testing of AI systems can be scheduled to produce evidence for risk treatment decisions, where the written scope includes it.
- Before choosing an auditor, confirm with the certification body which records it will sample and how it will test them.
