ISO 42001 Clause 6.1: Actions to Address AI Risks and Opportunities

Most organizations treating ISO 42001 as a checkbox exercise get stuck in the same place: Clause 6.1. Not because the clause is unclear, but because it forces a question that generic compliance programs are designed to avoid — what does your AI actually risk doing?

Clause 6.1, "Actions to Address Risks and Opportunities," is the planning engine of the entire AI Management System. It takes everything your organization established in Clause 4 (context, stakeholders, AI system scope) and Clause 5 (leadership commitment and AI policy) and converts it into a structured, actionable understanding of where your AI systems could cause harm and where they could create genuine value. Done properly, it is the foundation every downstream clause depends on. Done poorly, it produces a risk register no auditor will trust and no practitioner will use.

This guide covers Clause 6.1 at the depth required to actually implement it — not just describe it. We'll work through each sub-clause, address the AI-specific risk categories the standard was built to catch, explain how opportunity identification works in practice, and connect the clause to the rest of the AIMS architecture.

---

Clause 6.1 in the ISO 42001 Architecture

Before diving into sub-clauses, understand where Clause 6.1 sits in the standard's logic. ISO 42001 follows the High Level Structure (HLS) used across all modern ISO management system standards, which means the clause numbering is not arbitrary — it reflects a deliberate sequence of requirements.

Clause	Title	Relationship to Clause 6.1
Clause 4	Context of the Organization	Provides inputs: external/internal issues, interested parties, AI system scope
Clause 5	Leadership	Provides inputs: AI policy, roles, top management commitment
Clause 6.1	Actions to Address Risks and Opportunities	Converts context into actionable risk and opportunity plans
Clause 6.2	AI Objectives	Sets measurable targets informed by 6.1 risk and opportunity findings
Clause 8	Operation	Implements the controls identified in the 6.1 risk treatment plan
Clause 9	Performance Evaluation	Monitors whether 6.1 risk treatments are working and risks are changing
Clause 10	Improvement	Addresses nonconformities and drives AIMS evolution based on 9's findings

The implication is direct: if Clause 6.1 is weak, every other clause in your AIMS is building on an unstable foundation. Auditors know this, which is why Clause 6.1 typically receives the most intensive scrutiny during a Stage 2 certification audit.

Practitioner Note: Clause 6.1 is not a one-time exercise. The standard requires the AI risk assessment to be conducted at planned intervals and when significant changes occur — including changes to AI systems, deployment contexts, or the regulatory environment. Build it as a living process, not a project deliverable.

---

Clause 6.1.1: General Requirements

The general sub-clause establishes the foundational obligation: your organization must determine the risks and opportunities that need to be addressed to ensure the AIMS can achieve its intended outcomes, prevent or reduce undesired effects, and enable continual improvement.

That sounds simple. In practice, it requires answering three questions that most organizations have not formally addressed in the context of AI:

What are the intended outcomes of our AIMS?

The AIMS outcomes are defined by your AI policy (Clause 5.2) and your organizational context (Clause 4.1). If your policy commits to responsible AI that is accurate, fair, and explainable — then Clause 6.1 must identify risks that threaten those properties and opportunities that enhance them. Vague policies produce vague risk assessments. A policy that says "we will use AI responsibly" gives an auditor nothing to measure and gives your team nothing to operationalize.

What issues and requirements from Clauses 4 and 5 carry AI risk implications?

Clause 4.1 requires identification of external and internal issues relevant to the AIMS. For AI systems, external issues commonly include evolving regulatory requirements (EU AI Act, sector-specific AI regulations, GDPR's automated decision-making provisions), competitive dynamics, and societal expectations around AI transparency. Internal issues include data governance maturity, model development capabilities, organizational AI literacy, and the degree to which AI is embedded in critical decision-making processes.

Clause 4.2 requires identification of interested parties and their requirements. For AI, this includes customers who rely on AI outputs, employees whose work is affected by AI, regulators with oversight authority, and affected communities — particularly where AI systems make or influence consequential decisions about people.

These inputs are not just context — they are direct sources of risk. An interested party whose requirement is "AI recommendations must be explainable" creates an explainability risk that must appear in your Clause 6.1.2 risk assessment. The connection must be explicit and traceable.

What must be planned?

Clause 6.1.1 requires that your organization plan actions to address the identified risks and opportunities, integrate those actions into the AIMS processes, and evaluate the effectiveness of those actions. This is the PDCA cycle applied to AI risk — it does not end when the risk register is written.

---

Clause 6.1.2: AI Risk Assessment

This is the operational core of Clause 6.1. The standard requires that your organization define and apply an AI risk assessment process — and that process must be repeatable, comparable, and capable of producing valid results.

Establishing AI Risk Criteria

Before assessing risks, you must define what "risk" means for your AIMS. This requires establishing two categories of criteria:

Risk acceptance criteria: What level of risk will the organization tolerate without additional controls? This must be defined before assessment begins — setting it after you see the results is a common failure pattern that auditors recognize immediately.

Risk assessment criteria: How will you evaluate identified risks? Typically this involves likelihood (how probable is the risk materializing?) and consequence (what is the severity and scope of impact?). For AI systems, consequence analysis must explicitly consider impact on affected individuals — particularly where AI influences decisions in high-stakes domains like hiring, credit, healthcare, or criminal justice.

Identifying AI-Specific Risks

The ISO 42001 risk taxonomy is notably broader than traditional IT risk frameworks. The following are the risk categories that must be addressed for any substantive AI risk assessment. Each is distinct, each requires its own identification approach, and each has specific control implications:

Algorithmic Bias and Fairness

Algorithmic bias occurs when an AI system produces systematically skewed outputs that disadvantage or harm particular groups. The risk has two primary sources: biased training data (the model learns discriminatory patterns from historical data) and biased model architecture or objective functions (the model is optimized in ways that encode unfair trade-offs).

Identification requires examining the demographic composition of training datasets, the outcome distributions across protected characteristics, and the decision criteria the model uses. A lending AI trained predominantly on historical approval data from a market that discriminated against certain borrowers will perpetuate and potentially amplify that discrimination unless specifically corrected.

The risk extends beyond legal liability. An organization certified under ISO 42001 that fails to identify and address bias risks is directly contradicting its AI policy commitments — which makes it a dual audit finding under both Clause 6.1.2 and Clause 5.2.

Model Drift and Degradation

AI models are trained on data from a particular time period. As the world changes — consumer behavior shifts, supply chains reconfigure, fraud patterns evolve, language usage changes — the statistical relationships the model learned become less reliable. This is model drift, and it is one of the most consequential risks in production AI systems because it is invisible until its effects become significant.

A fraud detection model trained before a major shift in payment methods will start producing more false negatives. A demand forecasting model trained pre-pandemic will produce unreliable outputs in conditions it has never seen. Both represent risks to business outcomes and, in regulated contexts, risks to compliance.

Risk identification for model drift requires documenting the training data vintage, the expected stability horizon of the underlying relationships, and the monitoring approach that will detect performance degradation before it reaches material impact.

Data Quality and Data Governance Risks

AI systems are only as reliable as the data that trains them and the data they process at inference time. Data quality risks include incomplete data (which can create systematic blind spots), mislabeled training data (which teaches the model the wrong patterns), data with embedded privacy violations (which create legal exposure), and data that is not representative of the deployment population (which undermines generalizability).

ISO 42001 Annex A provides specific controls for AI data governance — but those controls only apply correctly if the data quality risks are properly identified in Clause 6.1.2 first. Organizations that skip the data quality risk identification step often discover during audits that their Annex A controls are inconsistent with their actual data landscape.

Explainability and Transparency Risks

Many high-performing AI models — particularly deep neural networks and ensemble methods — operate in ways that are not easily interpretable by humans. This creates risk in contexts where stakeholders have a right to understand or challenge AI-influenced decisions: credit decisions under GDPR's Article 22, hiring decisions under employment law, clinical recommendations under patient rights frameworks, and benefit eligibility determinations under administrative law.

The risk is not merely reputational. Where legal requirements mandate explainability, deploying an unexplainable model without appropriate mitigations is a direct compliance exposure. Risk identification must map explainability requirements to each AI system in scope and evaluate the gap between current explainability capability and the applicable requirements.

Adversarial Attacks and Model Manipulation

Adversarial attacks are inputs deliberately crafted to fool an AI system — causing it to misclassify images, bypass fraud detection, or generate harmful outputs. Model poisoning involves corrupting the training pipeline itself, injecting malicious patterns that cause the model to behave in attacker-controlled ways once deployed.

These risks are particularly acute for AI systems operating in adversarial environments: fraud detection, content moderation, cybersecurity tooling, and any AI system where a motivated actor benefits from subverting the system's correct behavior. Risk assessment must consider the threat actor landscape — who has motive to attack the system and what capabilities they likely have — not just the technical vulnerability profile.

Privacy and Data Protection Risks

AI systems create privacy risks that traditional IT risk frameworks are not designed to catch. Machine learning models can inadvertently memorize and reproduce training data, enabling membership inference attacks that reveal whether a specific individual was in the training set. Model inversion attacks can reconstruct approximate training data from model outputs. Differential privacy analysis can sometimes re-identify individuals from supposedly anonymized datasets.

Beyond technical attacks, AI systems often process personal data at scale in ways that create disproportionate surveillance or profiling risks. GDPR's data minimization requirements, purpose limitation principles, and automated decision-making restrictions all create specific privacy risk scenarios that must be identified and addressed in the AI context.

Security and Supply Chain Risks

AI systems rarely stand alone. They depend on third-party model providers, cloud infrastructure, data annotation services, open-source libraries, and API integrations. Each dependency is a potential risk vector: a compromised open-source library in the model training pipeline, a third-party model provider that changes its safety guidelines, or a cloud infrastructure provider that experiences an outage during a critical inference window.

The AI supply chain risk is distinct from traditional software supply chain risk because it includes the data supply chain — the provenance and integrity of training data — alongside the code supply chain. ISO 42001 Annex A, Section A.6.2 (third-party and supply chain considerations) provides controls, but these controls must be grounded in the supply chain risks identified in Clause 6.1.2.

Third-Party AI Dependencies

Organizations increasingly deploy AI systems built on foundation models — large pre-trained models licensed from providers like OpenAI, Google, Anthropic, or Mistral. This creates a specific risk category: your AI system's behavior is partially governed by your provider's training choices, safety tuning, and update schedule, all of which you may have limited visibility into and no control over.

When a foundation model provider updates their model, your application's behavior may change — for better or worse. When a provider changes their acceptable use policies, your compliance posture may be affected. When a provider discontinues a model, your system faces an operational cliff. These dependencies must be explicitly documented and assessed in the AI risk register.

Risk Analysis and Evaluation

Once risks are identified, the assessment process requires analysis (understanding the nature and level of each risk, considering its likelihood and consequence) and evaluation (comparing the analyzed risk against your acceptance criteria to determine which risks require treatment).

A practical approach uses a risk matrix with defined severity levels. For AI, severity must account for:

• The scale of the AI system's deployment (how many people are affected?)
• The reversibility of harm (can incorrect AI outputs be corrected before causing lasting damage?)
• The vulnerability of affected populations (does the system disproportionately affect protected classes or vulnerable individuals?)
• The degree of human oversight in the decision loop (is the AI making autonomous decisions or supporting human judgment?)

The standard requires that the results of the AI risk assessment be retained as documented information. This is not negotiable — auditors will ask to see it.

---

Clause 6.1.3: AI Risk Treatment

Identifying risks is only valuable if it drives action. Clause 6.1.3 requires the organization to select appropriate risk treatment options for each evaluated risk and implement controls sufficient to address it.

Risk Treatment Options

ISO 42001 aligns with standard risk management treatment options:

Risk avoidance: Eliminating the risk by not proceeding with the AI system or removing the feature that creates the risk. This is appropriate when the risk cannot be adequately controlled and the potential harm outweighs the benefit. Organizations sometimes discover in Clause 6.1.2 that a planned AI use case is simply not viable from a risk perspective — Clause 6.1.3 is where that conclusion becomes a documented decision.

Risk modification (mitigation): Implementing controls that reduce the likelihood or consequence of the risk. This is the most common treatment option. For AI, it includes technical controls (bias testing, explainability layers, anomaly detection, access controls), organizational controls (human review requirements, escalation procedures, use case restrictions), and contractual controls (supplier obligations, liability provisions).

Risk sharing: Transferring or distributing risk to a third party — typically through insurance, contractual indemnification, or liability sharing with AI providers. This does not eliminate the risk; it changes who bears the financial consequence if the risk materializes.

Risk acceptance: Accepting the risk without additional controls when the risk falls within acceptance criteria. This must be an explicit, documented decision by an authorized decision-maker — not simply a failure to address the risk.

The Statement of Applicability

One of the most important outputs of Clause 6.1.3 is the Statement of Applicability (SoA). The SoA documents which controls from ISO 42001 Annex A apply to your AIMS, which are excluded and why, and how the selected controls address the risks identified in Clause 6.1.2.

The SoA is not a formality. It is the document that demonstrates to auditors — and to your own team — that your control selection was deliberate and risk-driven rather than arbitrary. Every control included in the SoA should trace back to at least one identified risk. Every excluded control should have a documented justification.

Common Annex A control categories include:

• A.4: AI System Impact Assessment — formal process for evaluating potential harms before deployment
• A.5: AI System Lifecycle — controls across development, testing, deployment, monitoring, and decommissioning
• A.6: Data for AI — data quality, data provenance, training/validation/test set management
• A.7: AI System Stakeholders — communication, transparency, and affected party engagement
• A.8: AI System Technical Controls — accuracy, robustness, security, privacy-preserving techniques
• A.9: Human Oversight — mechanisms for human review, override, and accountability
• A.10: Responsible and Sustainable AI — resource usage, environmental impact, societal effects

Implementing the Risk Treatment Plan

The risk treatment plan must be more than a list of intended controls. It must assign owners, define implementation timelines, specify how the effectiveness of each control will be measured, and identify the residual risk after controls are implemented. Residual risk must be evaluated against your acceptance criteria — if the residual risk still exceeds acceptance, additional treatment is required.

This is where many organizations stall. The gap analysis reveals significant risks, the treatment plan identifies controls, but the controls never get fully implemented because ownership is unclear, resources were not allocated, or the AIMS exists in a silo disconnected from the teams actually building and deploying AI systems. If Clause 6.1.3 is not integrated into your AI development and deployment processes — not just your compliance processes — it will not work.

---

Opportunity Identification: The Underrated Half of Clause 6.1

Most discussions of Clause 6.1 focus on risk. The standard is equally explicit about opportunities — and practitioners who ignore this half are leaving value on the table, both for their organizations and for their certification narrative.

Opportunities in the ISO 42001 context are conditions that could produce positive outcomes if properly pursued. For an AI Management System, they include:

Accuracy and quality improvements: AI systems that demonstrably outperform manual processes in accuracy, consistency, or throughput create real organizational value. The opportunity is to deploy these systems responsibly in ways that capture the performance benefit without introducing uncontrolled risk.

Accessibility and inclusion: AI can make services accessible to populations that were previously excluded — through language translation, visual assistance, real-time transcription, or personalized communication. Organizations that identify and pursue these opportunities can demonstrate concrete social value from their AI investments.

Compliance efficiency: AI systems that automate routine compliance monitoring, document review, or regulatory reporting reduce burden and improve coverage. The opportunity is to deploy these tools in ways that enhance — rather than compromise — the reliability of compliance outcomes.

Competitive differentiation through certified responsible AI: ISO 42001 certification is itself an opportunity. Customers, regulators, and procurement officers increasingly distinguish between organizations with demonstrated AI governance maturity and those without it. Early movers in certification gain a trust advantage that is difficult for competitors to replicate quickly.

Innovation within governance boundaries: A well-implemented Clause 6.1 process actually enables faster AI deployment by establishing clear criteria for what constitutes acceptable risk. Teams know what they need to demonstrate before deploying — which is faster than ad hoc reviews or post-incident remediation.

Opportunities must be documented in the same structured way as risks: identified, assessed for feasibility and value, and connected to planned actions that integrate into AIMS processes. Clause 6.2 (AI Objectives) is the primary mechanism for converting identified opportunities into measurable targets.

---

Connecting Clause 6.1 to Adjacent Clauses

Clause 6.1 does not function in isolation. Its inputs and outputs create binding connections across the entire AIMS that auditors trace during certification assessments.

Clause 4 Feeds Clause 6.1

Your external issue analysis from Clause 4.1 must be traceable to specific risks in Clause 6.1.2. If you identified EU AI Act compliance as an external issue, where does the risk of non-compliance appear in your risk register? If you identified a major competitor gaining AI governance certification as a market threat, where does the opportunity to differentiate through your own certification appear in your opportunity log?

Auditors examine these connections. A Clause 4 analysis that lists twenty external issues and a Clause 6.1 risk register that does not reference them is a finding.

Clause 5 Feeds Clause 6.1

Your AI policy from Clause 5.2 establishes commitments. Those commitments create specific risk scenarios if violated. A policy commitment to human oversight of high-stakes decisions creates an obligation — and a risk if that oversight is absent or inadequate. A policy commitment to transparency creates a risk if deployed AI systems cannot explain their outputs to affected parties.

The Clause 6.1 risk assessment must include scenarios where the organization fails to fulfill its own AI policy commitments. This is not just an internal compliance matter — it is what auditors look for to verify that the AI policy is substantive rather than aspirational.

Clause 6.1 Drives Clause 8

Every operational control in Clause 8 — from AI system design requirements to human oversight mechanisms to incident response procedures — should trace back to a risk identified in Clause 6.1.2 or a treatment selected in Clause 6.1.3. If a Clause 8 control cannot be linked to a Clause 6.1 finding, either the control is unnecessary or the risk was missed. Neither is a comfortable position in an audit.

Clause 9 Monitors Clause 6.1 Effectiveness

The performance evaluation requirements in Clause 9 — including monitoring, measurement, analysis, and internal audit — are the mechanisms that determine whether the treatments selected in Clause 6.1.3 are actually working. This creates a feedback loop: if monitoring reveals that a model is drifting beyond its risk tolerance threshold, that finding must flow back into the Clause 6.1 risk assessment as an updated risk evaluation. Clause 6.1 must be a living process, not a static document.

---

Practical Implementation Steps

Here is how to execute Clause 6.1 as a working process rather than a documentation exercise:

Step 1: Build Your AI System Inventory

Before assessing risks, you need to know what you are assessing. Conduct a structured discovery to identify every AI system in scope — including internal development tools, third-party AI features embedded in commercial software, and AI capabilities enabled through APIs. Many organizations are surprised to find AI systems in HR screening tools, customer service platforms, and financial reporting software that were not on anyone's radar as "AI."

For each system, document: the purpose and use case, the affected populations, the training data sources, the deployment environment, the degree of automation (human-in-the-loop vs. fully automated decisions), and the applicable regulatory requirements.

Step 2: Define Risk Criteria Before Assessing

Set your likelihood scale, consequence scale, risk matrix, and acceptance thresholds before you begin the assessment. This prevents results-oriented risk evaluation — where the criteria are implicitly adjusted to produce a desired outcome. Criteria must be documented and reviewed by leadership before assessment begins.

Step 3: Conduct Structured Risk Identification Workshops

Risk identification for AI systems requires multi-disciplinary input: data scientists who understand model behavior, legal and privacy teams who understand regulatory requirements, operations teams who understand deployment contexts, and business leaders who understand stakeholder expectations. No single function has the complete picture.

Use the risk categories from Clause 6.1.2 — bias, drift, data quality, explainability, adversarial attacks, privacy, security, supply chain — as structured prompts for each AI system. This prevents the workshop from devolving into a generic IT risk brainstorm that misses AI-specific concerns.

Step 4: Build the AI Risk Register

For each identified risk, document: the risk description, the affected AI system(s), the likelihood rating with rationale, the consequence rating with rationale, the inherent risk level, the treatment option selected, the controls implemented or planned, the residual risk level, the risk owner, and the next review date.

The risk register is living documentation. It should be updated when new AI systems are deployed, when existing systems change substantially, when monitoring reveals new risk patterns, and at a minimum on the cadence defined in your AIMS planning.

Step 5: Develop the Risk Treatment Plan and SoA

Map each risk requiring treatment to one or more Annex A controls. Document why each control was selected, who owns implementation, what the implementation timeline is, and how effectiveness will be measured. Excluded Annex A controls must be justified — typically because the corresponding risk category does not apply to your AI systems or because an equivalent control is addressed through an alternative mechanism.

Step 6: Document Opportunities with the Same Rigor as Risks

Create an opportunity log parallel to your risk register. For each identified opportunity, document: the opportunity description, the AI system(s) involved, the expected value (quantitative or qualitative), the conditions required to realize it, the planned action to pursue it, and the connection to Clause 6.2 AI objectives. Auditors expect to see evidence that the organization takes the opportunity side of Clause 6.1 seriously — not just a one-line acknowledgment that opportunities were considered.

Step 7: Integrate with AI Development and Deployment Processes

Risk treatment controls only work if they are embedded in the processes where AI systems are actually built and deployed. This means your model development lifecycle must include mandatory risk assessment checkpoints, your deployment approval process must reference the risk register, and your monitoring program must be configured to detect the specific risk patterns identified in Clause 6.1.2. The AIMS cannot be a parallel compliance process running alongside the real work — it must be integrated into the real work.

---

Common Clause 6.1 Failures in Certification Audits

Based on what we see in certification preparation engagements, these are the patterns most likely to produce major nonconformances in Clause 6.1:

Risk criteria set after the assessment: Organizations complete a risk assessment and then define risk acceptance criteria to match the results. Auditors identify this through date inconsistencies in documentation and will escalate it as a process integrity finding.

Generic risk categories without AI-specific content: A risk register that lists "data breach" and "system failure" without addressing algorithmic bias, model drift, or adversarial attacks is applying an IT risk framework to an AI management system requirement. It will not satisfy a competent auditor.

Risk register not connected to interested party requirements: If your Clause 4.2 analysis identified customers who require explainable AI outputs, the explainability risk must appear in your risk register. Disconnected documentation signals a compliance-theater approach rather than genuine risk management.

Statement of Applicability with no exclusion justifications: An SoA that simply lists "not applicable" for Annex A controls without explaining why is insufficient. Every exclusion requires a documented rationale traceable to the risk assessment findings.

Treatment plan with no owners or timelines: A list of intended controls with no accountability structure is not a treatment plan — it is a wishlist. Clause 6.1.3 requires implemented actions, which means someone is responsible and there is a deadline.

Static risk register never updated: If your risk register has a single modification date from your initial AIMS implementation and has never been updated since, auditors will correctly conclude that it is not functioning as a living process. Every surveillance audit cycle should show evidence of risk register updates.

---

Frequently Asked Questions: ISO 42001 Clause 6.1

---

Conclusion

Clause 6.1 is not where you document that you thought about AI risk. It is where you prove that you understand it — specifically, systematically, and in a form your organization can act on. The organizations that pass certification audits are not the ones with the most sophisticated risk matrices; they are the ones where the risk assessment is genuinely integrated into how AI systems are built, deployed, and monitored.

The AI-specific risk categories in Clause 6.1.2 — bias, drift, data quality, explainability, adversarial attacks, privacy, security, and supply chain dependencies — are not theoretical abstractions. They are the patterns that produce real harm in production AI systems. Identifying them before deployment is always less expensive than addressing them after an incident.

And the opportunity side of Clause 6.1 matters too. The most effective AI Management Systems are not compliance exercises that constrain AI deployment — they are governance frameworks that enable faster, more confident AI deployment because the organization knows what it is managing and why.

If you are building or maturing an ISO 42001 AIMS and want an expert assessment of your Clause 6.1 process — including your risk register structure, SoA defensibility, and readiness for a certification audit — we offer focused gap assessments designed to identify exactly where your documentation and processes need to be strengthened before an external auditor does it for you.

---

Last updated: April 8, 2026