ISO 42001 AI risk assessment and treatment: what clauses 6.1.2 to 8.3 require

What ISO 42001 AI risk assessment and treatment requires and who pays for it

The organization owns its AI risk process. Clauses 6.1.2 and 8.2 require a documented AI risk assessment, clauses 6.1.3 and 8.3 require AI risk treatment, and the outcome of treatment must feed the statement of applicability, which lists the Annex A controls you need and justifies including or excluding each one. An implementation partner can design the method, draft the risk register and help run the workshops, but the decisions on risk criteria, risk owners and accepted residual risk must be made and signed off by your own people. Before any work starts, confirm who in your organization holds that accountability. ISO does not certify organizations. A certification body accredited for this purpose audits your system and issues the certificate, and accreditation of those 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 ask any prospective body whether it has applied them. The cost of the risk work depends mainly on how many AI systems fall in scope, how many use cases each one has, how mature your existing risk registers and data inventories are, and how much of the evidence already exists. Ask for a quote that separates the method design, the system-by-system assessments, the treatment plan, and the audit fee charged by the certification body, and state which items are one-time and which recur at each surveillance cycle.

The introduction to ISO/IEC 42001 gives three reasons AI needs specific management: automatic decision-making can be non-transparent and non-explainable, systems are built from data analysis and machine learning rather than hand-coded logic, and continuously learning systems change their behaviour during use. Each reason changes what a risk assessment must cover. A model that changes after deployment needs re-assessment triggers, not just a one-time review. A system whose logic is learned from data needs risk criteria tied to data quality and drift. A decision that cannot be fully explained needs treatment options such as human review or logging. Confirm with your risk owners which of your current AI systems fall into each of these categories, because the answer determines how much assessment effort each system needs.

How the AI risk assessment and treatment cycle runs from criteria to treatment plan

The sequence turns an agreed risk appetite into a documented set of AI risks, treatment decisions and Annex A controls that an auditor can trace from start to finish.

Set AI risk criteria and tolerance
Under clause 6.1.1, the organization sets the planning approach for AI risks and opportunities, and defines the criteria it will use to judge risk significance and the level of risk it will accept. Top management or the accountable AI governance owner agrees these criteria, ideally in the same scope that clause 4.3 defines for the AI management system. The output is a written risk criteria document covering likelihood, consequence, impact on individuals and society, and the tolerance thresholds that trigger treatment. Done means every person who scores risk can apply the same criteria and the document is approved and version-controlled.
Identify AI risk sources using Annex C
The team inventories each AI system in scope and lists the risks it could create or be exposed to. Annex C of ISO/IEC 42001 is informative, but it gives a structured list of potential AI-related organizational objectives and risk sources that helps prompt the discussion. Inputs usually include system descriptions, data sources, model behavior limits, third-party components and the intended use. The output is a risk register entry per system that names each risk source, the affected objective and the owner. Confirm that every system in the AI inventory has at least one entry or a documented reason why none applies.
Analyze AI risks against the criteria
The risk owner estimates the likelihood and consequence of each identified risk using the criteria from the first step, then records the inherent level before any controls are applied. Analysis covers the AI-specific causes that ISO/IEC 42001 highlights, including non-transparent automated decisions, behavior learned from data rather than human-coded logic, and systems that change during use. The output is a scored risk register with the scoring rationale recorded. A reviewer checks that scores follow the agreed criteria and that the rationale is written down, not just the number.
Evaluate risks against tolerance
Under clause 8.2, the organization runs the AI risk assessment on a planned basis and keeps the results. Each scored risk is compared with the tolerance thresholds. Risks above tolerance move to treatment, while risks within tolerance are accepted by a named owner and recorded as accepted. The output is a prioritized list of risks requiring treatment and a documented acceptance record for the rest. Auditors commonly ask for evidence that the assessment ran at the planned intervals and after significant changes, so keep dated results and the trigger that started each reassessment.
Select AI risk treatment options
For each risk above tolerance, the owner chooses a treatment: modify it with a control, avoid it by changing or stopping the use, share it through a contract or third-party arrangement, or accept it with approval. Under clause 6.1.3, the organization determines the controls needed to implement the chosen treatment. Where a control is needed, the team looks to the Annex A controls and the Annex B implementation guidance, and may add controls from other sources. The output is a risk treatment plan that links each risk to its selected option, its controls, its owner and the evidence that will show the control works.
Implement and verify treatment through clause 8.3
Under clause 8.3, the organization carries out the risk treatment plan and retains documented information of the results. Implementation is confirmed by the owner, and verification checks that each control operates as the plan intended. Where a treatment is still in progress, the register shows its status and the residual risk. The output is updated treatment records with completion evidence, residual risk ratings and any reassessment triggered by the treatment itself. Confirm that residual risks are re-scored against the same criteria before the risk is closed.
Record the statement of applicability
Clause 6.1.3 requires the organization to produce a statement of applicability that lists the necessary controls and justifies including or excluding each Annex A control. The team takes the controls selected in the treatment plan, maps them to the 38 Annex A controls in their nine objective areas, and records a reason for every inclusion and exclusion. The output is an approved statement of applicability that traces back to the risk register, so each control can be linked to the risk it treats. Before an audit, check that no selected control is missing from the statement and that every exclusion has a documented justification.

What makes AI risk assessment more or less expensive and longer

The effort behind ISO 42001 risk assessment and treatment scales with how much AI you run, how it behaves, and how much of it depends on outside parties. The cards below set out each driver and a control you can apply to keep the scope manageable.

Number of AI systems in scope

Every AI system inside the scope of clause 4.3 needs its own risk assessment under clause 8.2 and a treatment decision under clause 8.3. Start with a complete inventory of AI systems, including those bought as features in other software. Apply a tiered approach: give lower-impact use cases a lighter assessment template and reserve full analysis for systems that affect people's rights, safety or finances. Ask your team to confirm how many systems fall into each tier before estimating effort.

Continuously learning systems

Systems that change behaviour during use need risk assessments that are repeated, not filed once. The reasoning in ISO/IEC 42001's introduction about continuously learning systems is a reason to set re-assessment triggers, such as retraining, a change in input data or a drift alert. Each trigger adds recurring work. Define the triggers in the risk criteria so that the assessment cycle is predictable and auditable.

Third-party and externally hosted models

When a system uses a model or API you do not control, many risks sit outside your records. You still own the risk decision under clause 6.1.3, but you need supplier documentation, performance data and change notices to assess it. Ask suppliers early what documentation they provide and how they notify you of model changes. Where that information is thin, expect more time on treatment options such as restricting use or adding human review.

Business units and locations

Each business unit, country or legal entity that builds or uses AI can apply its own risk criteria, data rules and owners. Consolidating criteria into one organization-wide method reduces repeated workshops and conflicting risk ratings. Confirm which units use AI, who owns risk acceptance in each, and whether local regulation adds requirements. Scattered ownership usually adds more cost than the number of systems itself.

Maturity of existing risk registers

If your enterprise risk register already records likelihood, impact and treatment owners, you can extend it to AI risks and reuse its scoring scale. If the register is informal or spreadsheet-based, the first cycle will also define the method. Check whether AI risks can be tagged, linked to the AI system record and traced to the Annex A controls in the statement of applicability. Gaps in traceability are the most common reason risk work is repeated during an audit.

Third parties supplying data

Training, evaluation and operational data often come from data brokers, partners or customers. Each source affects data quality, provenance and bias risks that feed into the assessment. Map each data source to the systems it feeds, and record the contractual rights to use it. Where provenance cannot be shown, plan treatment such as exclusion, additional testing or documented acceptance by a named owner.

Who owns risk decisions, who prepares evidence and who audits it

The organization owns its AI risk process and every decision inside it. ISO/IEC 42001 requires the organization to define its AI risk assessment and treatment, so the people who set risk criteria, approve treatment choices and accept residual risk must be named inside the company. Management carries final accountability, and an auditor will look for evidence that a senior person with authority took those decisions.

Risk owners: Named individuals for each AI system or use case who accept the risks in their area and fund treatment.
AI governance lead: The person who maintains the risk method, runs the register and chases open treatments across teams.
Accountable executive: The senior manager who accepts residual risk on behalf of the company and records that acceptance in writing.
Technical contributors: Engineers and data owners who supply system facts, failure modes and monitoring data used in each assessment.
Decision records: Minutes or approvals showing who approved each risk criterion, treatment and acceptance, and when.

Confirm that every residual risk acceptance is signed by someone with authority over the affected AI system, and that the name and role appear in the register.

Which risk method to adopt: a standalone register, an ISO/IEC 23894 method or a NIST AI RMF-aligned method

This table compares three ways to build AI risk assessment and treatment under clauses 6.1.2, 6.1.3, 8.2 and 8.3, showing when each fits and what it costs in effort. Read each row against your existing reporting obligations and the size of your AI portfolio, then use the final row to decide whether a crosswalk is worth maintaining.

Decision factor	Standalone register from clause 6.1.2	ISO/IEC 23894 method	NIST AI RMF-aligned method
Best fit	Few AI systems, one product line, no external risk reporting	Several AI systems with shared risk owners and a need for documented method	Organizations already reporting to NIST or using the AI RMF internally
What it covers	Risk criteria, risk identification, analysis and evaluation as clause 6.1.2 requires	Guidance on the full AI risk management process, which ISO/IEC 42001 treats separately from impact assessment	Govern, Map, Measure and Manage functions, with GOVERN 1.3 and 1.4 on risk processes and tolerance
Crosswalk to clauses	Maps directly to 6.1.2, 6.1.3, 8.2 and 8.3 without a second vocabulary	Requires mapping ISO/IEC 23894 terms back to the clauses in your own procedure	GOVERN 1.3 and 1.4 map to clauses 6.1.1 to 6.1.3 and 8.3, not to Annex A controls
Annex A controls	Controls chosen through the statement of applicability, not through the method	Controls chosen through the statement of applicability, not through the method	Crosswalk does not map to Annex A, so treatment links to controls must be documented separately
Upfront effort	Lowest, but criteria must be written from scratch and justified	Moderate, needs a documented procedure and training on the guidance	Moderate to high, needs vocabulary translation and a clear record of which NIST actions you adopt
Recurring effort	Register reviews at planned intervals and after changes	Reviews plus periodic calibration of risk criteria	Reviews plus keeping the crosswalk aligned with NIST updates
Auditor readability	Clear if criteria and records are complete	Clear when the procedure cites the standard and shows consistent use	Clear for NIST-literate reviewers, but the crosswalk must be shown to an ISO auditor
Confirm before adopting	Your certification body accepts your criteria and treatment records	Your procedure uses the guidance's terms consistently across all systems	Mappings against the NIST crosswalk document, since they are not Annex A equivalences

How the NIST AI RMF maps to ISO 42001 clauses 6.1 and 8.3

A NIST AI RMF crosswalk tells you where ISO/IEC 42001 and the NIST framework overlap, and the most useful entry for this topic is the pair of GOVERN 1.3 and GOVERN 1.4 subcategories. GOVERN 1.3 concerns processes for managing AI risk, and GOVERN 1.4 concerns risk tolerance. The crosswalk, contributed by Microsoft and hosted by the NIST AI Resource Center, maps both to ISO/IEC 42001 clauses 6.1.1 to 6.1.3 and 8.3 rather than to Annex A controls. For an assessor, that means the risk process and risk treatment decisions in your AI management system are where you should look for evidence of these two NIST expectations, not in an individual Annex A control.

Practically, a team preparing for certification should check that its documented AI risk assessment method under clause 6.1.2 defines how risks are identified, analyzed and evaluated, that its risk acceptance criteria under clause 6.1.2 reflect a stated risk tolerance, and that its AI risk treatment plan under clause 6.1.3 and the operational records under clause 8.3 show decisions that follow those criteria. Confirm with your certification body which records it expects to sample. The crosswalk does not tell you whether a given record is sufficient, so treat the mapping as a checklist of places to look, not as proof that a requirement is met.

A mapping is a starting point, not a substitute for audit evidence. Certification bodies test the requirements of ISO/IEC 42001 itself, and the NIST AI RMF is a voluntary framework with no certification, so a row in a crosswalk does not satisfy a clause on its own. Read the full table on the NIST AI Resource Center crosswalk page, confirm each linked row against the clause text in the standard, and then collect dated, approved records for each one. Ask your certification body early whether it accepts NIST-based wording as supporting evidence for a clause, and record its answer.

What must exist before the certification audit tests risk treatment

An auditor testing AI risk treatment works backward from a single AI system to its risk, its treatment and its justification. The cards below are the records that must already exist and connect to one another before that trace can succeed, so each one can be checked on its own and as part of the chain.

Documented AI risk method

A written method sets how AI risks are identified, the criteria used to rate likelihood and consequence, the risk acceptance thresholds and who may accept residual risk. Clause 6.1.2 and clause 8.2 require the assessment to be repeatable and to produce consistent results. Check that the criteria are dated, approved by management, and applied the same way to every AI system in scope. ISO/IEC 23894 gives guidance you can use to shape the method.

AI risk register with named owners

The risk register lists each identified AI risk with its source, the AI system it affects, its rating before and after treatment, and a named owner accountable for the decision. Owners must be people with authority over the system, not only the team that built it. Sample one high-rated entry and confirm that the owner, rating and dates are present and that the owner recorded the decision.

Treatment plans tied to the statement of applicability

Each treatment option, whether it reduces, avoids, transfers or accepts the risk, must point to the Annex A controls or other measures that implement it. Clause 6.1.3 requires the statement of applicability to justify including or excluding each Annex A control, so every control cited in a treatment plan must appear there with a matching justification. Trace one treatment to its control and confirm the two records agree.

Records of risk review after changes

Risk assessments must be reviewed when an AI system changes in purpose, data, model version, deployment context or user population. Keep dated review records that state what changed, which risks were reexamined and what was decided. Clause 6.3 on planning of changes supports this trail. Ask for the review record created after the most recent model update and check that its date follows the change.

Evidence that treatment was applied

A treatment plan only counts once the control is operating. Keep implementation evidence such as configuration exports, test results, approval tickets, monitoring outputs or training records that show each treatment in place. Auditors often ask for this evidence after a risk is closed, so confirm that the evidence is dated within the audit period. A written plan with no operating evidence is a gap, not a treatment.

Questions buyers ask about AI risk assessment under ISO 42001

Can we run AI risk assessment in-house under ISO 42001?

Yes. ISO/IEC 42001 does not require an outside firm to perform clause 6.1.2 or clause 8.2 risk assessments, and the organization owns its risk criteria, risk owners and treatment decisions. Teams that already run an information security or enterprise risk process usually extend it to AI rather than build a new one. The questions to answer honestly are whether someone inside has the time, authority and technical knowledge to judge model behaviour, and whether the assessment will be repeated after changes. An implementation partner can help set up the method and records, but the risk decisions and their evidence must remain with the organization, and only an independent certification body can issue a certificate.

What skills and staff time does AI risk assessment need?

The work needs people who understand the AI system, the business process it supports and the risk owner who accepts residual risk. In practice that usually means a product or system owner who can describe intended use and data sources, an engineer who can explain model limits and failure modes, a security or privacy lead who can judge misuse and data exposure, and a risk or compliance lead who keeps the criteria consistent. Staff time recurs because the assessment must be revisited when the model, data, use case or supplier changes. Ask any consultant to show how they will transfer the method to your team and which tasks they will leave with you.

How does AI risk assessment differ from AI system impact assessment?

AI risk assessment asks what could stop the organization from meeting its AI objectives, such as loss of data confidentiality, model drift, unsafe outputs or non-compliance, and how likely and severe each risk is. AI system impact assessment under clauses 6.1.4 and 8.4 asks what effect the system may have on individuals, groups and society, including fairness and rights. The two use different questions and often different stakeholders, so they should not be merged into one spreadsheet. Risk treatment under clauses 6.1.3 and 8.3 then selects controls, which feed the statement of applicability. Impact findings can raise or change risks, so the two processes must reference each other in your records.

Is ISO/IEC 23894 required to meet ISO 42001 risk clauses?

No. ISO/IEC 42001 sets the requirements, and ISO/IEC 23894:2023 provides guidance on AI risk management that you can use to design your method. Certification auditors test whether your process meets the clause requirements and produces consistent records, not whether you followed a particular guidance document word for word. Using ISO/IEC 23894 is still a practical choice because it gives a shared vocabulary and worked approach that auditors recognize. Confirm with your certification body which guidance they expect you to reference, and check the current edition with ISO before you write the procedure.

How should we use the NIST AI RMF crosswalk for ISO 42001 risk work?

Use the NIST crosswalk as a cross-reference to show where your existing NIST AI RMF activities satisfy ISO/IEC 42001 clauses, not as a replacement for the standard. The published crosswalk maps GOVERN 1.3 and GOVERN 1.4, which cover risk management processes and risk tolerance, to clauses 6.1.1 to 6.1.3 and 8.3 rather than to Annex A controls. Check each mapping against your own evidence, because a crosswalk shows correspondence, not conformity. If your organization already uses the NIST AI RMF, the crosswalk can reduce duplicated documentation. You can find the source document through the NIST AI Resource Center crosswalks.

What drives the effort of ISO 42001 AI risk assessment?

Effort rises with the number of AI systems in scope, how much each one changes, how many data sources and third-party models it uses, and how high-stakes its decisions are. A single internal assistant with no personal data is a much smaller exercise than a credit or hiring model that affects people. Other drivers include how mature your existing risk register is, whether suppliers provide usable model documentation, and how many risk owners must agree. The first assessment is the most expensive because criteria and records are created. Ongoing effort is driven by change frequency and the quality of your monitoring. When requesting a quote, ask for the number of systems, assessment cycles per year, and the records the partner will deliver.

Can an implementation partner issue our ISO 42001 certificate?

No. An implementation partner can design the risk method, prepare systems, produce records and help you test the process before audit. Only an accredited or otherwise recognized certification body issues ISO 42001 certificates after an independent audit, and ISO itself does not certify organizations. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Keep the partner and the certification body independent so that the auditor can test your process without conflict. Before signing, ask the certification body whether it will accept the work product, and confirm accreditation status through your national accreditation body.

Where AI risk treatment projects usually stall

The most common stall is that risk criteria are written after the risk register is already full. Teams list AI risks as they come up, score them with whatever scale the security or data science lead prefers, and only then try to define what counts as acceptable. The result is a register that cannot be defended: the criteria look fitted to the risks rather than the other way round, and the risk owners cannot say which scores trigger treatment. Before any AI system is scored, confirm who approves the criteria, which likelihood and impact scales apply, and what the organization's risk acceptance thresholds are. Clause 6.1.2 expects the assessment to produce consistent and comparable results, which is hard to show when the scale changes midway through the exercise.

The second stall appears when treatment plans do not match the statement of applicability. Treatment decisions under clause 6.1.3 select controls, and the statement of applicability must then show which Annex A controls are included, why, and which are excluded with justification. In practice, the register lists treatments that reference controls the statement never mentions, or the statement excludes controls that a treatment plan quietly depends on. Ask for a cross-check before sign-off: every selected treatment should trace to a control in the statement, and every control marked as implemented should trace back to a risk. Mismatches like these are among the first things an auditor reading the records will notice.

The third stall is impact assessment merged into the risk register. ISO/IEC 42001 treats AI system impact assessment as a separate activity under clauses 6.1.4 and 8.4, and ISO/IEC 42005 covers impacts on individuals, groups and society, which a risk register built around organizational harm does not capture well. When both are combined, impacts on people tend to be scored as one more risk to the business, and the assessment loses its own documented process and records. Keep the two as separate records that cross-reference each other, and confirm with your certification body how it expects each to be evidenced before the project is scoped.

How DeployOpen prepares AI risk evidence for your certification audit

DeployOpen prepares the systems, risk records and evidence that support ISO 42001 AI risk assessment and treatment in your own infrastructure. Your organization owns its risk decisions and controls, and only an independent certification body can issue a certificate.

How we scope

We agree the AI systems, roles and environments in scope for risk assessment and treatment in a written scope before work starts.
We confirm which risk sources and objectives from Annex C your organization will consider, and record how they were selected.
Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support is available as a retainer.

How we build

We set up a repeatable AI risk assessment method with defined criteria, owners and review points inside your existing infrastructure.
We configure logging and tooling so risk register entries link to the systems, data and controls they affect.
We document risk treatment options and their link to your statement of applicability, so decisions can be traced during an audit.

How we hand over

We deliver the risk methodology, risk register, treatment plan and records of risk owner acceptance as documented information.
We walk your team through how each record is produced, updated and retained, so your staff can run the process after handover.
We document the evidence trail for clauses 6.1.2, 6.1.3, 8.2 and 8.3 so your auditor can sample it independently.

How we support

We can support internal audit and management review of the risk process, as agreed in the written scope.
Retainers cover updates to the risk register when AI systems change, new risks emerge or treatment plans need revision.
Your organization and its chosen certification body decide readiness and certification; we prepare the evidence but do not issue reports or certificates.