3.7 AI Risk Treatment Planning, Control Selection & Risk Acceptance
Key Takeaways
- Clause 6.1.3 mandates that organizations formulate an AI Risk Treatment Plan (RTP) to address unacceptable risks identified under Clauses 6.1.2 and 6.1.4.
- Risk treatment options include risk avoidance, risk reduction (mitigation), risk sharing (transfer), and formal risk acceptance (retention).
- Controls are selected from ISO/IEC 42001 Annex A domains (A.2 through A.10), matching specific AI threat vectors to technical and organizational controls.
- Formal risk acceptance requires explicit management sign-off based on documented risk criteria, designated approval authorities, and ongoing residual risk tracking.
3.7 AI Risk Treatment Planning, Control Selection & Risk Acceptance
Once AI risks and societal impacts have been identified and evaluated under Clauses 6.1.2 and 6.1.4, the organization must establish a formal AI Risk Treatment Process under ISO/IEC 42001 Clause 6.1.3. Risk treatment is the process of selecting and implementing measures to modify risk levels so that residual risk falls within acceptable organizational thresholds. The primary operational output of this process is the Risk Treatment Plan (RTP), a core deliverable evaluated during certification audits.
The Four AI Risk Treatment Strategies
Under Clause 6.1.3, top management and risk owners must select one or more treatment strategies for every identified risk:
- Risk Avoidance: Deciding not to start or continue with an activity that gives rise to an unacceptable risk. Example: Discontinuing the development of an emotion-recognition AI model due to unacceptable legal, regulatory, and ethical risks.
- Risk Mitigation (Reduction): Taking explicit action to reduce the likelihood or consequence of a risk using technical or organizational controls. Example: Implementing automated bias-detection filters and synthetic data augmentation under Annex A.6.
- Risk Sharing (Transfer): Shifting a portion of the risk burden to third parties through contractual indemnities, insurance policies, or vendor SLAs. Example: Executing vendor agreements that hold third-party API providers accountable for training data copyright infringement.
- Risk Acceptance (Retention): Formally accepting the residual risk without further treatment when it meets organizational risk appetite criteria and receives executive approval.
Selecting Controls from ISO/IEC 42001 Annex A
ISO/IEC 42001 contains 38 control objectives and controls structured across ten Annex A domains. Implementers map identified risks directly to appropriate controls:
| Annex A Domain | Domain Focus | Representative Technical & Organizational Controls |
|---|---|---|
| Annex A.2 | Internal Organization | Roles and responsibilities allocation, separation of duties in ML pipelines. |
| Annex A.3 | Resources for AI Systems | Hardware/GPU provisioning, human competence, and data storage resources. |
| Annex A.4 | Assessing Impacts | Standardized impact assessment SOPs and stakeholder review workflows. |
| Annex A.5 | AI System Lifecycle | Verification, validation, testing, and continuous drift monitoring controls. |
| Annex A.6 | Data for AI Systems | Data provenance, quality checks, sanitization, bias auditing, and consent tracking. |
| Annex A.7 | Information for Interested Parties | Transparency disclosures, user notices, and algorithmic explainability tools. |
| Annex A.8 | Use of AI Systems | Operational guidelines, human-in-the-loop oversight, and output validation. |
| Annex A.9 | Third-Party Relationships | Vendor risk assessments, API SLA monitoring, and data privacy contracts. |
| Annex A.10 | Operational Controls | Logging, auditability, incident response, and continuous monitoring. |
Comprehensive Risk-to-Control Treatment Matrix
The following matrix illustrates how specific AI risk scenarios are treated using Annex A controls:
| Risk Scenario | Selected Strategy | Annex A Domain | Implemented Technical/Organizational Controls | Target Residual Risk |
|---|---|---|---|---|
| Demographic Bias in Credit Scoring | Risk Mitigation | Annex A.6 & A.8 | Re-balance training dataset; implement demographically blind features; deploy human oversight review for all credit rejections. | Low (Acceptable) |
| Model Drift Causing Accuracy Drop | Risk Mitigation | Annex A.5 & A.10 | Deploy continuous automated monitoring of performance metrics; establish automated retraining triggers upon accuracy drop. | Medium (Tolerable) |
| Prompt Injection Attacks on Chatbot | Risk Mitigation | Annex A.8 & A.10 | Implement input sanitization firewalls; restrict system prompt permissions; log all anomalous user inputs. | Low (Acceptable) |
| IP Infringement via Third-Party LLM | Risk Sharing & Mitigation | Annex A.9 | Execute vendor contractual indemnities; restrict API inputs to non-proprietary data; conduct quarterly vendor audits. | Medium (Tolerable) |
| Emotion Recognition Compliance Risk | Risk Avoidance | Annex A.4 & A.5 | Decommission model development completely; purge training data; update AI system inventory. | Zero (Eliminated) |
Formulating the Risk Treatment Plan (RTP)
The Risk Treatment Plan (RTP) is a documented operational artifact detailing how selected controls will be executed. An effective RTP must explicitly specify:
- Risk Identifier & Description: Cross-referenced directly to the master AI Risk Register.
- Selected Annex A Controls: Specific control IDs (e.g., A.6.2, A.8.3).
- Control Owners: Designated individuals accountable for implementation.
- Target Implementation Deadlines: Milestone dates for control deployment.
- Resource Allocation: Financial budget, software tools, and engineering hours required.
- Key Risk Indicators (KRIs): Quantitative metrics to verify control effectiveness post-deployment.
Governance of Formal Risk Acceptance
Under Clause 6.1.3, residual risks that remain after treatment must be formally accepted by designated management authorities. Risk acceptance governance requires:
- Threshold-Based Sign-Off Levels: Low residual risk can be accepted by the AI System Owner; Medium residual risk requires CAIO approval; High residual risk requires C-Suite / Board sign-off.
- Documented Acceptance Rationale: Explaining why further risk reduction is technically unfeasible or cost-prohibitive while remaining within risk appetite.
- Continuous Residual Risk Tracking: Re-evaluating accepted risks during annual Management Reviews under Clause 9.3.
Worked Implementation Scenario: Autonomous Fraud Detection Risk Treatment Plan
Context: A digital bank deploys a real-time AI model for fraud detection that exhibits a 3% false-positive rate, freezing legitimate customer credit cards.
Risk Treatment Execution:
- Strategy: The bank selects Risk Mitigation.
- Control Selection: The team selects Annex A.8.2 (Human Oversight) and Annex A.10.2 (Operational Logging).
- RTP Formulation: The RTP specifies that all transactions flagged as high-value fraud must be routed to human fraud analysts within 60 seconds (Control Owner: Fraud Operations Manager; Budget: $75,000; Deadline: 30 days).
- Acceptance: The residual false-positive rate of 0.5% is formally accepted by the Chief Risk Officer.
Lead Implementer Exam Tips
- Four Treatment Options: Know all four options cold: Avoidance, Mitigation/Reduction, Sharing/Transfer, Acceptance/Retention.
- Mandatory RTP Elements: Memorize the required elements of an RTP: Risk ID, Annex A controls, Control Owner, Resource Allocation, Implementation Deadline, and KRIs.
- Sign-Off Authority: Remember that residual risk acceptance must be formally documented and signed off by management authorities designated according to risk severity thresholds.
An organization discovers that an automated resume-screening tool exhibits statistically significant demographic bias. The firm decides to suspend automated filtering and require HR recruiters to manually review all applications while the model is re-trained. Which risk treatment strategy does this represent?
To address risks associated with training data contamination, unrepresentative sampling, and lack of data consent, which Annex A control domain should the implementer primarily select controls from?
Under ISO/IEC 42001 Clause 6.1.3, what is required before residual AI risks can be formally accepted by the organization?
Which artifact serves as the primary operational deliverable detailing control owners, implementation deadlines, and resource allocations for treated AI risks?