AI risk assessment

ISO/IEC 42001 Clause 6.1.2 requires you to define and run an AI risk assessment process that covers the full AI system lifecycle, evaluates risk by likelihood and impact, and produces documented results. To operationalize it quickly, standardize scope and ownership, assess each AI use case consistently, record decisions, and tie findings to treatment actions and sign-offs. ¹

Key takeaways:

• You need a repeatable AI risk assessment process, not one-off reviews. ¹
• Your assessment must cover the AI lifecycle and evaluate likelihood and impact, with documented results. ¹
• Auditors will look for evidence that assessments drive decisions, controls, and ongoing monitoring, not just paperwork. ¹

“AI risk assessment requirement” usually fails in practice for one reason: teams treat it like a policy statement instead of an operating process that produces consistent, reviewable outputs. ISO/IEC 42001 Clause 6.1.2 is explicit about three operator outcomes: (1) identify risks associated with AI systems throughout their lifecycle, (2) analyze and evaluate those risks using likelihood and impact, and (3) produce documented information about the results. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to create a single intake-and-assess workflow that every AI system must pass through before deployment and on material change. That workflow should work for internally built models, configured commercial AI features, and AI supplied by third parties. The goal is not academic completeness; it is defensible consistency: defined criteria, repeatable scoring, decision records, and clear links to risk treatment actions and ownership. ¹

This page gives requirement-level guidance you can adopt immediately: who it applies to, what to do step-by-step, what evidence to retain, what auditors ask, and the implementation mistakes that trigger findings.

Regulatory text

Requirement (Clause 6.1.2): “The organization shall define and apply an AI risk assessment process that identifies risks associated with AI systems throughout their lifecycle, analyses and evaluates those risks considering likelihood and impact, and produces documented information about AI risk assessment results.” ¹

Operator interpretation of the text:

• “Define and apply a process” means you need a documented method (procedure/work instruction) and proof it is used for real AI systems, not a shelf document. ¹
• “Throughout their lifecycle” means you must assess risk beyond initial build or procurement. Cover design, development/configuration, testing, deployment, operation/monitoring, change management, and retirement. ¹
• “Considering likelihood and impact” means you need a consistent evaluation model (qualitative or quantitative) that incorporates both probability and severity, with defined scales. ¹
• “Produces documented information” means you must retain assessment outputs (records) that show inputs, scoring, rationale, decisions, and resulting actions. ¹

Plain-English requirement

You must run a repeatable AI risk assessment for each AI system, across its lifecycle, using a defined likelihood/impact approach, and keep records of the results and decisions. If you cannot show consistent assessments and evidence that findings drive controls and approvals, you will struggle to demonstrate conformity to Clause 6.1.2. ¹

Who it applies to (entity and operational context)

This requirement applies to any organization operating an AI management system under ISO/IEC 42001, including:

• AI providers building or significantly modifying AI systems.
• AI users deploying AI capabilities (including configurable commercial tools) in business processes.
• Organizations relying on third-party AI where risk is introduced through procurement, integration, or downstream use. ¹

Operationally, you should apply the process to:

• Externally facing AI (customer decisions, pricing, eligibility, claims, fraud, content moderation).
• Internally facing AI that affects employment, access, investigations, security operations, or regulated records.
• AI embedded in third-party products where you still own the business outcome (for example, agent-assist, automated summarization that enters official records, or decision support tools). ¹

What you actually need to do (step-by-step)

1) Define scope and inventory trigger

Create an AI system intake that answers, at minimum:

• What is the system, purpose, and decision/action it supports?
• Who owns it (business owner) and who operates it (technical owner)?
• Who is affected (customers, employees, applicants, counterparties)?
• Is it internally built, configured, or provided by a third party?
• Where does data come from, and where do outputs go (including downstream systems)? ¹

Practical control: require intake completion for new AI, material changes, and new uses of an existing model. ¹

2) Define your likelihood and impact methodology (and publish it)

Write a short, auditable method that includes:

• Likelihood scale definitions (what “unlikely/possible/likely” means for your org).
• Impact categories (at least: legal/compliance, customer harm, financial loss, operational disruption, security/privacy, reputational harm).
• Scoring rules (for example, a matrix) and what each risk tier requires (extra testing, approvals, monitoring, or restrictions). ¹

Keep the method stable. Change it only through governance, and retain version history so you can explain why older assessments used an older scale. ¹

3) Identify lifecycle risks using a structured checklist

Build a checklist that forces coverage across lifecycle stages:

• Design & data: training data suitability, labeling quality, sensitive attributes, data rights, privacy, representativeness, drift susceptibility.
• Model behavior: performance limits, robustness, failure modes, hallucinations (if applicable), explainability needs, bias/fairness concerns.
• Deployment: access controls, prompt/parameter governance, integration risks, human-in-the-loop design, user disclosures where required by policy.
• Operations: monitoring for drift, incident response, change control, logging, periodic reassessment triggers.
• Retirement: decommission plan, record retention, model artifact disposal, and rollback strategy. ¹

For third-party AI, extend the checklist to cover supplier assurances, configuration control, and contractual rights to receive relevant risk and change information. ¹

4) Analyze and evaluate risks (likelihood × impact) with rationale

For each identified risk:

• Assign likelihood and impact using your defined scales.
• Document the rationale in plain language (“why this likelihood; why this impact”).
• Capture inherent risk and residual risk (after planned controls), if your method supports it.
• Identify risk owners and treatment actions. ¹

A common audit gap is scoring without rationale. A second gap is listing mitigations without verifying they exist or are owned by someone who can deliver them. ¹

5) Produce documented results and route to decision

Your output should drive an explicit decision:

• Approved to proceed as designed.
• Approved with conditions (specific controls, testing, monitoring, or limits).
• Not approved (must redesign, replace, or remove the AI feature). ¹

Tie approval to a governance checkpoint. Even a lightweight sign-off (business owner + model/product owner + compliance/privacy/security as needed) is better than an informal “looks fine” in chat. ¹

6) Operationalize reassessment across the lifecycle

Define triggers such as:

• Material model change, retraining, or parameter updates.
• New data sources, new user group, or new decision context.
• Incident, near miss, customer complaint pattern, or monitoring alert.
• Third-party product version change or major feature release affecting AI behavior. ¹

If you need tooling to keep this repeatable, Daydream can help centralize AI system inventory, intake workflows, assessment records, and approval evidence so your process stays consistent across teams and third parties.

Required evidence and artifacts to retain

Auditors typically expect “documented information” that shows both the defined process and proof of execution:

• AI risk assessment procedure (version controlled). ¹
• AI system inventory with ownership, purpose, and lifecycle status. ¹
• Completed risk assessments per AI system (risks identified, likelihood, impact, rationale, results). ¹
• Risk treatment plan(s) linked to assessment findings (control selection, owners, due dates or milestones, acceptance decisions where applicable). ¹
• Approval records (sign-offs, meeting minutes, tickets, change approvals). ¹
• Monitoring and reassessment triggers and evidence (alerts, periodic reviews, incident records tied back to risk updates). ¹
• For third-party AI: due diligence records and change notifications that affect the assessed risk posture. ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me your AI risk assessment process and how you ensure it is applied to all AI systems.” ¹
• “How do you define likelihood and impact, and how do you prevent inconsistent scoring across teams?” ¹
• “Pick one AI system. Walk me from intake through risk identification, scoring, decisions, and monitoring.” ¹
• “How do you reassess risk after model changes or third-party updates?” ¹
• “Where is the documented output of the risk assessment, and who reviewed/approved it?” ¹

Hangups that cause findings:

• Inventory gaps (unknown AI systems or “shadow AI” in business units).
• Assessments that cover only development, not deployment/operations/retirement.
• Risks listed with no likelihood/impact evaluation.
• No documented results, or results not tied to treatment decisions. ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating “AI risk assessment” as a generic enterprise risk assessment.
   Fix: add AI-specific lifecycle prompts and require model/context details (data, outputs, human oversight, monitoring). ¹

2. No clear boundary for what counts as an AI system.
   Fix: define inclusion rules in your intake (e.g., ML models, generative AI features, configurable scoring engines marketed as AI, and third-party AI embedded in products you run). ¹

3. Scoring theater: numbers without definitions.
   Fix: publish likelihood and impact definitions and require short written rationales for each rating. ¹

4. One-and-done assessments.
   Fix: codify reassessment triggers and connect them to change management and incident management. ¹

5. Third-party blind spots.
   Fix: require procurement and vendor management to feed AI changes into your reassessment process; capture contractual rights to receive change information where feasible. ¹

Practical execution plan (30/60/90 days)

First 30 days (stand up the minimum viable process)

• Publish an AI system definition, intake form, and ownership model. ¹
• Create the likelihood/impact method and a basic risk matrix with decision thresholds. ¹
• Pilot the assessment on a small set of representative AI systems (internal, customer-facing, third-party). ¹

By 60 days (make it operational across teams)

• Build an AI inventory and reconcile it with procurement, IT, and engineering records. ¹
• Implement governance routing: who must review which risk tiers, and what approvals are required. ¹
• Connect reassessment triggers to change management and incident workflows. ¹

By 90 days (make it audit-ready and sustainable)

• Standardize evidence: templates, naming conventions, and a single repository for assessments and approvals. ¹
• Add operational monitoring expectations and require proof of monitoring for high-risk systems. ¹
• Run an internal audit-style review: pick samples, test traceability from intake to treatment to monitoring, and fix gaps. ¹

Frequently Asked Questions

Do we need an AI risk assessment for every use of ChatGPT or similar tools?

If the tool is used in a way that affects business decisions, regulated records, customers, or employees, treat that as an AI system use case and assess it. If use is purely ad hoc and prohibited from handling sensitive data by policy, document the boundary and enforce it. ¹

Can we use a qualitative risk matrix, or does ISO require quantitative modeling?

Clause 6.1.2 requires likelihood and impact analysis and evaluation, but it does not prescribe quantitative methods. A clear qualitative scale with defined criteria and documented rationale can meet the requirement if consistently applied. ¹

How do we handle third-party AI where we can’t see training data or model details?

Assess what you control (inputs, configuration, access, human oversight, downstream use) and what you can contract for (change notifications, assurances, support). Document assumptions and residual risk explicitly, and adjust your allowed use cases if risk remains high. ¹

What counts as “throughout the lifecycle” in practice?

You should cover pre-deployment (design/procurement and testing), deployment decisions, operational monitoring and change management, and retirement. The simplest proof is an assessment record plus defined reassessment triggers tied to your operational processes. ¹

How do we prove we “applied” the process, not just wrote it?

Keep completed assessments, approval artifacts, and treatment actions that trace back to identified risks. Auditors commonly ask for a walkthrough of one system from intake through monitoring evidence. ¹

We already have an enterprise risk management program. Can we map AI risk into that?

Yes, but you still need an AI-specific assessment process that reliably identifies lifecycle risks and documents results using likelihood and impact. Most organizations keep ERM as the reporting layer and run AI risk assessment as the operating workflow feeding it. ¹

Footnotes

1. ISO/IEC 42001:2023 Artificial intelligence — Management system