ISO/IEC 42001 AI Risk Assessment Step-by-Step Guide

An ISO/IEC 42001 AI risk assessment is best treated as a repeatable management-system process

June 5, 2026
CyberZoni

A strong ISO/IEC 42001 AI risk assessment is a controlled management-system process that connects AI inventory, impact assessment, risk scoring, control selection, residual risk acceptance, monitoring, audit, and improvement.

What the AI risk assessment is supposed to achieve

An ISO/IEC 42001 AI risk assessment should answer five questions:

What AI systems are in scope?
Who or what could be harmed or adversely affected?
What can go wrong across the AI lifecycle?
How serious and likely are those risks?
What controls, owners, monitoring, and acceptance decisions are required?

The assessment should feed your AI management system: AI policy, risk treatment plan, control selection, supplier management, human oversight, monitoring, internal audit, and management review.

ISO/IEC 23894 is a useful companion because it provides guidance for organizations that develop, deploy, produce, or use AI systems to manage AI-related risk and integrate that risk management into AI activities. ISO/IEC 42005:2025 is also relevant because it provides guidance for AI system impact assessments focused on effects on individuals, groups, and society across the AI lifecycle.

Core deliverables

At the end of the assessment, you should have these records:

Deliverable	Purpose
AI inventory	List of AI systems, use cases, owners, users, suppliers, lifecycle status, and criticality.
AI system description	Business purpose, model type, data, interfaces, users, outputs, dependencies, and deployment context.
Stakeholder and impact assessment	Identification of affected individuals, groups, customers, employees, regulators, and society-level effects.
Risk criteria	Likelihood, impact, risk appetite, severity thresholds, and escalation rules.
Risk register	Risk scenarios, causes, impacts, inherent risk, controls, residual risk, owner, treatment plan, evidence.
Risk treatment plan	Control actions, responsible owners, deadlines, evidence, and validation method.
Statement of applicability or control applicability matrix	Which AI controls are applicable, not applicable, implemented, or planned.
Residual risk acceptance record	Formal approval by accountable management for remaining risk.
Monitoring plan	Metrics, alerts, review cadence, drift checks, incident triggers, and re-assessment triggers.

Step-by-step method

Step 1: Define the assessment scope

Do not assess “AI” in the abstract. Assess a specific system in a specific use context.

Start by deciding whether you are assessing:

a single AI system,
a portfolio of AI systems,
a business process using AI,
a third-party AI service,
a general-purpose AI or generative AI capability,
or the entire organization’s AIMS.

For each assessment, document:

Field	Example
Assessment name	Customer Support GenAI Assistant Risk Assessment
Business owner	VP Customer Operations
Technical owner	Head of AI Engineering
AI system owner	Product Manager, Support Automation
Assessment lead	AI Governance Manager
Lifecycle stage	Design, pilot, production, retirement
In-scope components	LLM API, retrieval system, prompt templates, user interface, support knowledge base
Out-of-scope components	Human-only escalation process, billing platform
Intended users	Support agents
Affected parties	Customers, support agents, company
Assessment date	2026-06-04
Review date	Quarterly or after material change

Step 2: Create or update the AI inventory

Before assessing risk, you need a complete inventory of AI systems. The inventory is the control point that prevents shadow AI from bypassing governance.

Minimum fields:

Field	Description
AI system ID	Unique identifier
Name	System name
Business process	Where it is used
Purpose	Intended use
AI type	ML model, rules plus ML, LLM, computer vision, recommender, classifier, agent
Build/buy status	Internal, vendor, open-source, embedded third party
Data used	Training, validation, production, personal, sensitive, confidential
Users	Employees, customers, public, automated system
Decision role	Advisory, assistive, semi-automated, fully automated
Impact level	Low, medium, high, critical
Owner	Accountable business owner
Status	Idea, development, pilot, production, retired
Last assessment	Date
Next review	Date

Step 3: Describe the AI system clearly

The risk team cannot assess what it cannot understand. Create a concise system description before scoring risks.

A. Business purpose

Explain what the system is supposed to do and why the organization uses it.

Example: The system assists customer support agents by drafting responses based on approved knowledge-base articles. Agents review and edit responses before sending them to customers.

B. Intended use and prohibited use

Document both.

Category	Example
Intended use	Draft support responses for low-risk product questions
Prohibited use	Making refund decisions, legal claims, medical advice, or account termination decisions

C. System architecture

Include the model, data, interfaces, human users, downstream systems, and vendors.

D. Decision role

Classify how much authority the AI has:

Role	Description	Risk implication
Informational	Provides information only	Usually lower risk
Assistive	Helps a human decide	Requires human oversight
Recommending	Ranks or recommends options	Risk of automation bias
Semi-automated	AI output normally followed unless overridden	Higher oversight burden
Fully automated	AI makes or executes decision	Highest governance burden

Step 4: Identify stakeholders and affected parties

AI risk is not only risk to the company. It includes risks to people, groups, customers, employees, business partners, and society.

Stakeholders may include:

Stakeholder	Possible concern
Customers	Incorrect decisions, unfair treatment, privacy invasion
Employees	Surveillance, deskilling, unfair performance evaluation
Vulnerable groups	Discrimination, exclusion, accessibility barriers
Regulators	Non-compliance, inadequate documentation
Business units	Operational failure, reputational damage
Security team	Prompt injection, data leakage, model abuse
Legal/privacy team	Personal data misuse, IP issues, automated decision concerns
Suppliers	Contractual, service, auditability, transparency issues

ISO/IEC 42005 is especially useful here because it focuses on identifying, evaluating, and documenting intended and unintended impacts of AI systems on individuals, groups, and society.

Ask:

Who receives the AI output?
Who is judged, ranked, predicted, profiled, or affected?
Who may be excluded by data, language, disability, geography, or digital access?
Who can challenge the output?
Who is accountable when the AI causes harm?

Step 5: Define risk criteria before scoring

Do not start by arguing whether a risk is high or medium. First define the scoring rules.

A simple ISO/IEC 42001-compatible method can use: Risk score = Likelihood x Impact.

Likelihood scale

Score	Level	Meaning
1	Rare	Highly unlikely; would require exceptional conditions
2	Unlikely	Could occur, but not expected
3	Possible	Could occur under normal conditions
4	Likely	Expected to occur periodically
5	Almost certain	Expected to occur often or continuously

Impact scale

Score impact across multiple dimensions, then use the highest relevant impact score.

Score	Level	Example impact
1	Negligible	Minor inconvenience, no material harm
2	Minor	Small customer issue, easily corrected
3	Moderate	Material service error, complaint, limited legal or privacy concern
4	Major	Serious harm, regulatory exposure, discrimination, major operational disruption
5	Severe	Physical harm, major rights impact, systemic discrimination, major legal exposure, severe reputational damage

Risk rating

Score	Rating	Action
1-4	Low	Manage through standard controls
5-9	Medium	Treatment plan required
10-16	High	Senior owner approval required
17-25	Critical	Do not deploy unless risk is reduced or formally accepted by executive governance

For AI systems, numeric scoring should be supported by evidence. A 3 x 4 = 12 score is not enough. Record why the likelihood and impact were chosen.

Step 6: Identify AI-specific risk scenarios

Use scenario-based risk identification. A useful format is:

Because [cause / threat / condition], the AI system may [risk event], which could cause [impact] to [stakeholder / asset / objective].

Example: Because the support assistant retrieves outdated knowledge-base content, it may generate inaccurate instructions, which could cause customers to take incorrect account actions and create customer harm, complaints, and remediation cost.

Assess risks across the full AI lifecycle.

AI risk categories to consider

Category	Example risks
Governance	No accountable owner, unclear approval authority, undocumented intended use
Legal and compliance	Privacy violation, unlawful automated decision-making, inadequate records
Data	Poor data quality, biased data, missing consent/provenance, sensitive data leakage
Model performance	Inaccuracy, hallucination, overfitting, brittleness, poor calibration
Fairness and non-discrimination	Disparate impact, proxy discrimination, unequal error rates
Transparency and explainability	Users cannot understand limitations or contest outcomes
Human oversight	Rubber-stamping, automation bias, unclear escalation
Security	Prompt injection, data poisoning, model extraction, adversarial examples
Safety	Physical or psychological harm, unsafe recommendations
Operational resilience	Downtime, vendor outage, uncontrolled model change
Third-party risk	Vendor opacity, inadequate audit rights, unclear data use
Misuse and abuse	Users apply system outside intended purpose
Environmental and societal	Resource use, labor displacement, manipulation, exclusion

Generative AI-specific risks

GenAI-specific risk	Example
Hallucination	Fabricated facts in customer, legal, medical, or financial context
Prompt injection	External text manipulates the model into ignoring instructions
Confidentiality leakage	Sensitive data appears in prompts or outputs
Toxic or unsafe content	Harmful, biased, or policy-violating output
IP/copyright risk	Generated or retrieved content creates IP exposure
Untraceable output	Organization cannot explain source or basis of answer

NIST’s AI RMF is a useful cross-check: its core functions are Govern, Map, Measure, and Manage, which align well with governance, context-setting, measurement, and risk treatment activities in an AI risk assessment.

Step 7: Analyze inherent risk

Inherent risk means the level of risk before new or enhanced controls.

For each risk scenario, score:

Field	Description
Risk ID	Unique number
Risk scenario	What could happen
Cause	Why it could happen
Impacted stakeholder	Customer, employee, public, business, regulator
Existing controls	Controls already in place
Likelihood	1-5
Impact	1-5
Inherent score	Likelihood x Impact
Inherent rating	Low, medium, high, critical
Evidence	Data, testing, incidents, expert review, vendor evidence

Step 8: Evaluate risk against appetite and acceptance criteria

Now decide whether the risk is acceptable, unacceptable, or acceptable only with additional controls.

Use three tests:

1. Threshold test

Does the score exceed your defined risk appetite?

Example: Critical risk cannot deploy. High risk requires a treatment plan and senior approval. Medium risk requires a treatment plan. Low risk can be monitored through standard controls.

2. Red-line test

Some risks should trigger escalation regardless of score, such as:

potential physical harm,
unlawful discrimination,
children or vulnerable-person impacts,
sensitive personal data misuse,
fully automated consequential decisions,
inability to provide meaningful human oversight,
inability to stop or roll back the system,
lack of supplier transparency for a high-impact use case.

3. Evidence test

Ask whether the score is defensible.

Bad evidence: The team believes the risk is low.

Better evidence: The validation set covers the intended user groups, measured error rates are within approved tolerance, human review is mandatory before customer communication, and monitoring alerts trigger if unsupported output exceeds 2%

Step 9: Select risk treatment options

For each unacceptable risk, select one or more treatment options.

Treatment option	Meaning	AI example
Avoid	Do not proceed with the risky use	Do not use AI for employee termination recommendations
Reduce	Add controls to lower likelihood or impact	Add human review, testing, retrieval grounding, access control
Transfer/share	Shift or share risk contractually or operationally	Vendor warranties, insurance, contractual audit rights
Accept	Formally accept residual risk	Executive approval with monitoring
Exploit opportunity	Use AI benefit under controlled conditions	Pilot in low-risk workflow before expansion

Control types

Use a layered control model.

Risk	Possible controls
Bias or disparate impact	Representative data review, fairness metrics, subgroup testing, independent review
Hallucination	Retrieval grounding, output constraints, confidence thresholds, human review
Prompt injection	Input filtering, tool-use restrictions, system prompt hardening, sandboxing, monitoring
Privacy leakage	Data minimization, redaction, access control, retention limits, privacy review
Model drift	Performance monitoring, drift detection, scheduled revalidation
Automation bias	User training, interface warnings, mandatory justification for decisions
Vendor opacity	Due diligence, contractual audit rights, model/data-use commitments
Misuse	Intended-use policy, access restrictions, user logging, prohibited-use monitoring

Step 10: Link risks to ISO/IEC 42001 controls and your control applicability matrix

For certification readiness, your risk assessment should drive control selection. In practice, create a control applicability matrix similar to a Statement of Applicability.

Control area	Applicable?	Why?	Implementation evidence	Risk IDs
AI policy and responsibilities	Yes	All AI systems require accountable ownership	AI policy, RACI, approval minutes	AI-R-001
Impact assessment	Yes	Customer-facing AI affects individuals	Impact assessment report	AI-R-003, AI-R-009
Data governance	Yes	System uses customer support records	Data lineage, quality checks, privacy review	AI-R-004
Human oversight	Yes	AI drafts customer communications	Agent review workflow, training	AI-R-014
Third-party management	Yes	LLM API supplied by vendor	Vendor due diligence, contract addendum	AI-R-021
Model monitoring	Yes	Output quality may drift	Monitoring dashboard, incident thresholds	AI-R-018

The key audit logic is: Risk identified -> Control selected -> Control implemented -> Evidence retained -> Residual risk evaluated -> Management accepts or rejects.

Step 11: Estimate residual risk

After defining controls, rescore the risk.

Field	Before controls	After controls
Likelihood	4	2
Impact	3	3
Score	12	6
Rating	High	Medium
Decision	Treat	Accept with monitoring

Document why the residual score changed. Do not lower the score just because a policy exists. Lower it only when the control is implemented, operating, and supported by evidence.

Good evidence includes:

validation results,
access-control screenshots,
monitoring dashboards,
test cases,
red-team results,
bias/fairness analysis,
human review logs,
supplier attestations,
training records,
incident response exercises,
approval minutes.

Step 12: Obtain formal risk acceptance

Residual risks must be accepted by the right level of authority.

Example authority model:

Residual rating	Acceptance authority
Low	System owner
Medium	Business owner
High	AI governance committee or executive risk owner
Critical	Executive committee; usually not deployable without further treatment

Acceptance record:

Field	Example
Risk ID	AI-R-014
Residual rating	Medium
Residual risk summary	Incorrect support response remains possible despite grounding and human review
Required monitoring	Unsupported output rate, complaint rate, override rate
Acceptance owner	VP Customer Operations
Acceptance date	2026-06-04
Expiry/review date	2026-09-04
Conditions	No expansion to refund decisions without reassessment

Step 13: Build the monitoring and reassessment plan

AI systems can drift, vendors can change models, data can shift, and users can misuse outputs.

Monitor:

Metric type	Examples
Model performance	Accuracy, precision/recall, hallucination rate, unsupported answer rate
Fairness	Error rates by protected or relevant groups, adverse impact indicators
Safety	Harmful output rate, severity of incidents
Security	Prompt injection attempts, unauthorized access, data exfiltration attempts
Human oversight	Override rate, review completion rate, escalation rate
Usage	Use volume, unusual use, prohibited-use attempts
Data	Drift, missing values, data quality failures
Vendor	Model version changes, service incidents, SLA failures
Complaints/incidents	Customer complaints, regulator inquiries, internal reports

Trigger reassessment when:

intended use changes,
user group changes,
data source changes,
model or vendor changes,
the system is integrated into a new business process,
performance drops below threshold,
incident or near miss occurs,
new legal/regulatory obligation applies,
monitoring shows drift or unexpected behavior,
the system moves from pilot to production.

Step 14: Keep documented information

For ISO-style management systems, documentation matters because it proves the process is repeatable and controlled.

Maintain:

Record	Owner
AI inventory	AI governance or risk team
Risk assessment procedure	AIMS owner
Risk criteria	Risk management function
Risk register	System owner plus risk lead
Impact assessment	Business owner plus AI governance
Technical validation evidence	AI engineering / data science
Privacy/security reviews	Privacy/security teams
Supplier due diligence	Procurement / vendor risk
Residual risk acceptance	Accountable business owner
Monitoring reports	System owner
Incident records	Operations / security / compliance
Internal audit results	Internal audit
Management review minutes	Executive sponsor / AIMS owner

Recommended Template Workflow

Start with scope and governance. Use the AIMS scope, AI policy, roles and responsibilities, and legal register templates to define boundaries, responsibilities, obligations, and approval authority.
Build the risk register. Use the ISO 42001 Risk Assessment Template to capture AI risks and opportunities, score likelihood and impact, define inherent risk, record existing controls, and decide whether risk treatment is required.
Assess human and societal impacts. Use the AI System Impact Assessment Template to document affected parties, intended use, foreseeable misuse, potential harms, safeguards, oversight, and residual impact concerns.
Select controls and document applicability. Use the Statement of Applicability Template to justify which ISO 42001 Annex A controls apply, assign owners, link controls to risks, and record implementation evidence.
Operationalize treatment actions. Use the risk treatment plan, controls tracker, and lifecycle process template to convert assessment findings into accountable actions, deadlines, evidence, and lifecycle stage gates.
Prepare for review and audit. Use the internal audit checklist and management review records to test whether the AIMS is implemented, maintained, effective, and continually improved.

Recommended Templates

ISO 42001 Risk Assessment Template – Main working template for AI risk scoring, treatment actions, residual risk, owners, and control traceability.
ISO 42001 Toolkit Bundle – Complete AIMS documentation set for policy, scope, responsibilities, risk, impact, control applicability, lifecycle governance, and audit readiness.
AI System Impact Assessment Template – Template for documenting impacts on individuals, groups, users, customers, employees, society, and the environment.
ISO 42001 Statement of Applicability Template – Control applicability and justification template for linking selected controls to risk treatment and evidence.
AI System Life Cycle Process Template – Lifecycle procedure template for embedding risk controls into initiation, design, development, validation, deployment, monitoring, change, and retirement.

ISO/IEC 42001 AI risk assessment checklist

This checklist provides a practical summary of the key activities involved in conducting an ISO/IEC 42001 AI risk assessment.

The checklist can be used during AI system intake, pre-deployment review, supplier assessment, internal audit preparation, or periodic reassessment. It covers essential areas such as governance, intended use, stakeholder impact, data and model risks, human oversight, third-party dependencies, risk treatment, residual risk acceptance, and ongoing monitoring.

For a free downloadable version of the checklist, use the link below:

Download the ISO/IEC 42001 AI Risk Assessment Checklist

Common mistakes to avoid

Treating the risk assessment as a compliance form

A risk register with generic entries like bias risk or privacy risk is weak. Use concrete scenarios tied to a real system, real data, real users, and real decisions.

Ignoring intended use

The same model can be low risk in one context and high risk in another. A chatbot that summarizes public help articles is different from a chatbot that gives medical, legal, financial, or employment advice.

Scoring risk without evidence

Risk scores should be supported by validation results, incident data, user testing, vendor evidence, security testing, or expert review.

Confusing human oversight with human accountability

A human in the loop is not enough. The human must have enough time, information, authority, competence, and interface support to challenge or override the AI.

Forgetting third-party AI dependencies

Vendor AI systems still need assessment. Outsourcing the model does not outsource accountability.

Failing to reassess after change

AI risk changes when prompts, models, data, thresholds, integrations, vendors, users, or business purposes change.

A simple operating rhythm

Cadence	Activity
Monthly	Review AI inventory changes and new use cases.
Quarterly	Review high and medium AI risks, monitoring metrics, incidents, and overdue treatments.
Before deployment	Complete risk assessment, impact assessment, validation, control mapping, and residual risk acceptance.
After material change	Reassess affected risks and obtain new approval.
Annually	Review risk methodology, appetite, control effectiveness, internal audit findings, and management review outputs.

Final recommended procedure

For each AI system, follow this repeatable procedure:

Register the AI system in the AI inventory.
Assign accountable owners for business, technical, risk, and operational responsibilities.
Document intended and prohibited use.
Map the system architecture, data flows, users, suppliers, and outputs.
Identify affected stakeholders and complete an impact assessment.
Define likelihood, impact, risk appetite, and escalation criteria.
Identify risk scenarios across the AI lifecycle.
Score inherent risk using documented evidence.
Evaluate risks against appetite and red-line criteria.
Select treatment options and AI controls.
Implement and test controls.
Score residual risk.
Obtain formal risk acceptance.
Monitor performance, fairness, security, usage, drift, incidents, and supplier changes.
Reassess after material change or at a defined review interval.
Feed results into AIMS performance evaluation, internal audit, management review, and continual improvement.