AI Risk Assessment for ISO 42001:
Annex A Controls Deep Dive

AI risk assessment under ISO 42001 is the systematic process of identifying, analyzing, evaluating, and treating risks that are specific to artificial intelligence systems. Unlike traditional IT risk assessments that focus primarily on confidentiality, integrity, and availability, the ISO 42001 risk assessment framework extends into dimensions unique to AI: bias and fairness, transparency and explainability, societal impact, accountability, and the reliability of autonomous or semi-autonomous decision-making.

Clause 6.1 of ISO 42001 requires organizations to plan actions to address risks and opportunities related to their AI management system. But this is more than a compliance checkbox. The risk assessment is the analytical engine that drives every subsequent decision in your AIMS — which Annex A controls you select, which policies you write, which monitoring activities you perform, and how you allocate resources to AI governance. A weak risk assessment produces a weak management system. A rigorous one creates the foundation for genuine AI governance maturity.

How ISO 42001 Risk Assessment Differs from Traditional Risk Management

Organizations with existing ISO 27001 or ISO 9001 certifications will recognize the structural framework — risk identification, analysis, evaluation, and treatment. The Plan-Do-Check-Act cycle applies. The Annex SL risk clause structure is identical. However, the substance diverges significantly.

Traditional information security risk assessment asks: What could compromise the confidentiality, integrity, or availability of our information assets? AI risk assessment asks a fundamentally broader set of questions:

• Could this AI system produce discriminatory outcomes? The training data, model architecture, and deployment context all create potential vectors for bias that traditional security assessments never consider.
• Can affected individuals understand why this AI system made a particular decision? Explainability is not a security concern — it is an AI governance concern with legal, ethical, and operational dimensions.
• What happens when the AI system encounters inputs outside its training distribution? Model robustness and graceful degradation are AI-specific reliability concerns.
• Who is accountable when this AI system causes harm? AI creates accountability gaps that do not exist in traditional information processing systems.
• What are the broader societal consequences of deploying this system at scale? Environmental impact, labor displacement, and social equity effects fall within the ISO 42001 risk scope.

This expanded risk taxonomy is what makes ISO 42001 both more demanding and more valuable than applying a traditional risk framework to AI systems. You cannot achieve meaningful AI governance by treating AI risks as a subcategory of information security risks. They require their own assessment methodology, their own risk criteria, and their own treatment strategies.

The Risk Assessment as a Living Process

One of the most critical distinctions in ISO 42001 risk assessment is that AI risks are inherently dynamic. A machine learning model that was fair on its training data may develop bias over time as the underlying data distribution shifts. A generative AI system may produce harmful outputs in contexts that were not anticipated during development. An AI system that performs well in one regulatory jurisdiction may violate requirements in another.

ISO 42001 therefore requires that risk assessment be a continual process, not a point-in-time activity. Your risk assessment methodology must include triggers for reassessment: changes to AI systems, changes in the operating environment, new regulatory requirements, incidents or near-misses, and findings from ongoing monitoring. Auditors will look for evidence that your risk assessment evolves alongside your AI systems.

Conducting an AI risk assessment that satisfies ISO 42001 auditors requires a structured methodology with clear inputs, defined steps, and documented outputs. Below is the methodology we use across our ISO 42001 implementation engagements, refined over 200+ certification projects.

Step 1: AI System Inventory and Classification

Before you can assess risks, you need to know what you are assessing. Create a comprehensive inventory of all AI systems within your defined scope. For each system, document:

• System name, owner, and operational status (development, production, retired)
• AI technology type (machine learning, deep learning, NLP, computer vision, rule-based, generative AI)
• Purpose and use case (what decisions or outputs does it produce?)
• Data inputs (what data does it consume, and where does that data come from?)
• Affected stakeholders (who is impacted by the system's outputs or decisions?)
• Autonomy level (fully automated, human-in-the-loop, human-on-the-loop, decision support)
• Criticality classification (what happens if this system fails, produces incorrect outputs, or behaves unfairly?)

This inventory becomes the foundation for scoping. Many organizations discover AI systems they did not know existed during this exercise — embedded analytics, vendor-provided AI features, or departmental tools adopted without central IT oversight.

Step 2: Establish Risk Assessment Criteria

Define the criteria that will govern how risks are measured and evaluated. Your risk criteria must be documented, approved by management, and consistently applied. Key elements include:

• Likelihood scale — How probable is the risk event? Define 4 to 5 levels (e.g., rare, unlikely, possible, likely, almost certain) with clear descriptions and, ideally, quantitative thresholds.
• Impact scale — How severe would the consequences be? Define impact across multiple dimensions: operational (service disruption), financial (cost/revenue), reputational (brand damage), legal/regulatory (fines, sanctions), and human (harm to individuals or communities).
• Risk appetite statement — What level of risk is your organization willing to accept? This varies by AI system criticality, industry context, and regulatory environment. A healthcare AI system will have a much lower risk appetite than an internal content recommendation engine.
• Risk evaluation matrix — A matrix that combines likelihood and impact scores to produce an overall risk level (e.g., low, moderate, high, critical) and defines the treatment response required at each level.

Step 3: AI-Specific Risk Identification

This is the step where AI risk assessment diverges most dramatically from traditional risk management. Use structured workshops with cross-functional teams (AI engineers, data scientists, legal/compliance, business owners, and affected stakeholder representatives) to identify risks across the following AI-specific categories:

• Bias and fairness risks — Training data bias, proxy discrimination, feedback loop amplification, differential performance across demographic groups
• Transparency and explainability risks — Black-box decision-making, inability to provide explanations to affected individuals, lack of audit trail for AI decisions
• Security and robustness risks — Adversarial attacks, data poisoning, model extraction, input manipulation, model instability under distribution shift
• Privacy risks — Unauthorized personal data processing, re-identification from anonymized data, inference of sensitive attributes, excessive data retention
• Accountability risks — Unclear responsibility chains, inadequate human oversight, insufficient competence of personnel managing AI systems
• Reliability and safety risks — System failures, incorrect outputs, degraded performance over time, unsafe behavior in edge cases
• Societal and environmental risks — Labor displacement, environmental impact of compute, manipulation and misinformation, concentration of power

For each identified risk, document the risk source, the potential event, the potential consequences, and the existing controls (if any) that currently mitigate the risk.

Step 4: Risk Analysis and Evaluation

Apply your defined risk criteria to analyze and evaluate each identified risk. For each risk:

1. Assess the likelihood of occurrence, considering both inherent likelihood and the effectiveness of existing controls
2. Assess the potential impact across all relevant dimensions (operational, financial, reputational, legal, human)
3. Calculate the overall risk level using your risk evaluation matrix
4. Compare against your risk appetite to determine whether the risk requires treatment

Document the analysis in a risk register that provides traceability from risk identification through evaluation to treatment decisions. The risk register is one of the most heavily scrutinized documents during certification audits.

Step 5: Risk Treatment and Annex A Control Selection

For each risk that exceeds your risk appetite, select a treatment strategy:

• Mitigate — Implement controls to reduce likelihood or impact. This is the most common treatment for AI risks. Select appropriate Annex A controls and map them to each risk.
• Transfer — Transfer the risk to a third party through insurance, contractual arrangements, or outsourcing (with appropriate governance).
• Avoid — Eliminate the risk by discontinuing the AI activity or redesigning the system to remove the risk source entirely.
• Accept — Formally accept the residual risk when it falls within appetite after existing controls are considered. Acceptance must be documented and approved by management.

The output of this step is the Risk Treatment Plan — a document that links each unacceptable risk to specific treatment actions, assigned owners, target dates, and required resources. The Risk Treatment Plan and the Statement of Applicability (SoA) are companion documents: the SoA records which Annex A controls are selected and why, while the Risk Treatment Plan records the implementation roadmap.

Tools and Templates

Effective AI risk assessment does not require expensive software. Most organizations begin with structured templates and scale tooling as they mature:

• AI System Inventory Template — A structured spreadsheet or database for cataloging all AI systems in scope, their characteristics, and their criticality classification.
• AI Risk Register — A risk register template with AI-specific fields: risk category (bias, transparency, security, privacy, accountability, societal), AI system reference, lifecycle stage, and Annex A control mapping.
• Risk Evaluation Matrix — A customizable matrix with clearly defined likelihood and impact scales tailored to your organization's context.
• Statement of Applicability Template — A control-by-control document listing all 39 Annex A controls with applicability status, justification, and implementation evidence references.
• Risk Treatment Plan Template — An action-oriented document linking risks to treatment activities, owners, and timelines.

We provide all of these templates as part of our ISO 42001 implementation consulting engagements.

ISO 42001 is a documentation-intensive standard. Auditors will verify that your AIMS is not only implemented but also properly documented and maintained. The following documents form the core of your AI risk assessment documentation suite.

Mandatory Documented Information

• AI Policy — Your organization's top-level commitment to responsible AI governance. Must be endorsed by top management, communicated to relevant personnel, and available to interested parties as appropriate. The AI policy sets the tone for your entire AIMS.
• Risk Assessment Methodology — A documented procedure describing how AI risks are identified, analyzed, evaluated, and treated. Must include your risk criteria (likelihood and impact scales), risk appetite definition, and the process for updating the assessment. Auditors will verify that the methodology is consistently applied across all AI systems in scope.
• AI Risk Register — A comprehensive record of all identified AI risks with their likelihood, impact, current risk level, existing controls, and treatment decisions. The risk register must be maintained as a living document and reviewed at defined intervals.
• Risk Treatment Plan — For each risk requiring treatment, document the selected treatment strategy, specific actions, responsible owners, target completion dates, and required resources. The treatment plan drives implementation activities and is reviewed during management review meetings.
• Statement of Applicability (SoA) — A control-by-control document listing all 39 Annex A controls with their applicability status (applicable/not applicable), justification for inclusion or exclusion, and current implementation status. The SoA is one of the most critical audit documents — it demonstrates that control selection is risk-driven, not arbitrary.
• AI System Impact Assessment — Documentation of the impact assessment process and results for each AI system in scope. Must address potential impacts on individuals, groups, and society. Required by Clause 6.1.4.
• AI System Inventory — A maintained register of all AI systems within scope, their classification, lifecycle stage, and key characteristics.

Supporting Documentation

Beyond the mandatory documents, your AIMS will typically include:

• Internal Audit Reports — Documented results of internal audits verifying AIMS conformity and effectiveness (Clause 9.2)
• Management Review Minutes — Records of management review meetings where AIMS performance, risk assessment results, audit findings, and improvement opportunities are discussed (Clause 9.3)
• Competence Records — Evidence that personnel involved in AI activities have the necessary competence, including training records, qualifications, and experience documentation (Clause 7.2)
• Incident Reports — Records of AI system incidents, investigations, root cause analyses, and corrective actions
• Change Records — Documentation of changes to AI systems, including change requests, impact assessments, approval records, and post-implementation reviews
• Monitoring Reports — Periodic reports on AI system performance, drift detection results, fairness metrics, and operational health indicators

Documentation Best Practices

Based on our experience guiding organizations through certification audits, these practices separate successful documentation from documentation that triggers audit findings:

1. Write for the auditor, not for yourself. An auditor who has never seen your organization needs to understand how your AIMS works from the documentation alone. If it requires tribal knowledge to interpret, it will generate findings.
2. Maintain version control. Every document must have a version number, revision date, and approval authority. Use a document management system that tracks changes and prevents unauthorized modifications.
3. Show the connections. Your documentation should clearly trace the thread from risk identification through risk analysis to control selection to implementation evidence. Auditors follow this thread — gaps in traceability are the most common source of nonconformities.
4. Keep it current. The most common audit finding is documentation that does not reflect current practice. If you changed a process six months ago but did not update the procedure document, that is a nonconformity. Schedule regular documentation reviews.
5. Do not over-document. Write what is necessary for governance and audit purposes. Excessive documentation creates maintenance burden and increases the likelihood that documents become stale.