Who this is for: Organizations implementing or certified to ISO 42001 (AI Management System). Risk managers extending ISO 31000 to AI-specific risks. Internal auditors preparing for ISO 42001 Stage 1/2 assessments. GRC architects building a unified ISO 42001 + ISO 23894 risk management framework. EU AI Act high-risk system providers using ISO 42001 as a path to presumption of conformity.
Companion standard, not certifiable. ISO/IEC 23894:2023 provides guidance on AI-specific risk management processes. It extends ISO 31000 (risk management) with AI-specific considerations and serves as the technical companion to ISO 42001 (certifiable AIMS). While ISO 23894 itself is not certifiable, implementing its guidance strengthens ISO 42001 certification readiness and demonstrates risk management maturity to auditors.
Contents
1. Overview 2. Relationship to ISO 42001 and ISO 31000 3. AI Risk Management Process 4. Process-to-Procedure Mapping 5. Detailed Procedure Cards 6. Quick Reference 7. Quick Start 8. References1. Overview
ISO/IEC 23894:2023, Information technology -- Artificial intelligence -- Guidance on risk management, provides detailed guidance on managing risks specific to AI systems throughout their lifecycle. It extends the general risk management process defined in ISO 31000 with AI-specific considerations across four stages: risk identification, risk analysis, risk evaluation, and risk treatment.
The standard addresses risks that are unique to AI or substantially different from traditional ICT risks:
- Data quality and representativeness risks that can lead to biased, unreliable, or unsafe AI outputs
- Model behavior risks including opacity, drift, brittleness, and unintended emergent capabilities
- Autonomy and human oversight risks where AI systems operate with insufficient human control
- Transparency and explainability risks that undermine trust and accountability
- Societal and environmental risks including systemic effects, sustainability impacts, and effects on vulnerable populations
2. Relationship to ISO 42001 and ISO 31000
| Standard | Role | Certifiable? | Relationship |
|---|---|---|---|
| ISO 31000 | General risk management framework | No (guidance) | Provides the base risk management process that ISO 23894 extends |
| ISO/IEC 23894 | AI-specific risk management guidance | No (guidance) | Extends ISO 31000 with AI-specific risk identification, analysis, evaluation, and treatment |
| ISO/IEC 42001 | AI Management System (AIMS) | Yes | Requires risk management (Clause 6.1); ISO 23894 provides the detailed how-to |
ISO 42001 tells you what to do (establish risk management within your AIMS). ISO 23894 tells you how to do it for AI-specific risks. Using both together creates the strongest evidence base for ISO 42001 certification and for demonstrating AI risk management maturity to regulators.
3. AI Risk Management Process
| Stage | ISO 23894 Clause | AI-Specific Focus |
|---|---|---|
| Context Establishment | Cl. 5 | Define AI risk governance structure, scope, criteria, and organizational context. Identify stakeholders affected by AI systems. |
| Risk Identification | Cl. 6.1 | Identify AI-specific risk sources: data quality (6.1.2), bias (6.1.3), transparency (6.1.4), autonomy (6.1.5), security (6.1.6), societal impact (6.1.7). Map risks across the AI lifecycle. |
| Risk Analysis | Cl. 6.2 | Analyze likelihood and impact of identified AI risks. Consider cascading effects, systemic risks, and risks that emerge only at scale or in deployment. |
| Risk Evaluation | Cl. 6.3 | Compare analyzed risks against acceptance criteria. Prioritize risks for treatment. Account for AI-specific factors: model uncertainty, data distribution shift, adversarial robustness. |
| Risk Treatment | Cl. 6.4 | Select and implement risk treatment options: avoidance, reduction, transfer, acceptance. AI-specific treatments include guardrails, human oversight, model constraints, monitoring, and safe fallback states. |
| Monitoring and Review | Cl. 7 | Continuously monitor AI risks. Detect model drift, data distribution changes, and emerging risks. Update risk assessments as AI systems evolve. |
4. Process-to-Procedure Mapping
| ISO 23894 Process Area | SWT3 Procedure | What It Witnesses | Clause |
|---|---|---|---|
| AI Risk Governance | AI-GOV.1 | AI risk governance structure and policy established | Cl. 5 |
| Risk Management Scope | AI-GOV.6 | AI risk management scope, boundaries, and criteria defined | Cl. 5.1 |
| Risk Identification | AI-RISK.1 | AI-specific risks identified and categorized | Cl. 6.1 |
| Data Quality Risk | AI-DATA.1 | Training data quality, representativeness, and provenance assessed | Cl. 6.1.2 |
| Bias Risk | AI-FAIR.1 | Bias disparity measured across protected attributes | Cl. 6.1.3 |
| Transparency Risk | AI-TRANS.1 | Transparency disclosure obligations met | Cl. 6.1.4 |
| Autonomy Risk | AI-HITL.1 | Human oversight maintained in autonomous operations | Cl. 6.1.5 |
| Risk Analysis | AI-IMPACT.1 | Societal impact of AI system analyzed | Cl. 6.2 |
| Data Protection Analysis | AI-DPIA.1 | Data protection impact assessed for AI processing | Cl. 6.2 |
| Risk Evaluation | AI-DRIFT.1 | Model drift detected, risk re-evaluated against criteria | Cl. 6.3 |
| Risk Treatment | AI-PMM.1 | Post-market monitoring active for ongoing risk treatment | Cl. 6.4 |
| Risk Mitigation | AI-SAFE.1 | Safe state transition capability verified | Cl. 6.4.2 |
5. Detailed Procedure Cards
AI Risk Identification (Cl. 6.1)
ISO 23894 guidance: Organizations should identify AI-specific risk sources across the entire AI lifecycle: design, development, deployment, operation, and decommissioning. Risk sources include data quality and representativeness (6.1.2), algorithmic bias (6.1.3), lack of transparency (6.1.4), insufficient human oversight (6.1.5), security vulnerabilities (6.1.6), and societal impacts (6.1.7). Each risk source should be documented with its potential consequences and the conditions under which it may materialize.
How SWT3 addresses it: The witnessRisk() call records each identified risk with its source category, potential consequence, lifecycle stage, and current status. Factor A identifies the risk category (data, bias, transparency, autonomy, security, societal). Factor B records the severity assessment. Factor C records the lifecycle stage and mitigation status.
For ISO 42001 Stage 2 audits, AI-RISK.1 anchors demonstrate that Clause 6.1 (actions to address risks and opportunities) is implemented with AI-specific depth. The auditor will check coverage across all six risk source categories from ISO 23894 Cl. 6.1.2-6.1.7. Gaps in coverage (e.g., no bias risk identification) indicate incomplete risk identification. Cross-reference with AI-GOV.6 to show the risk management scope was defined before identification began.
Data Quality Risk Assessment (Cl. 6.1.2)
ISO 23894 guidance: Data quality risks are among the most significant AI-specific risks. Organizations should assess training data for completeness, accuracy, representativeness, currency, and relevance. Data provenance should be documented, including sources, collection methods, preprocessing steps, and any known limitations. Insufficient data quality can lead to biased outputs, unreliable predictions, and safety failures.
How SWT3 addresses it: The witnessDataProvenance() call records the dataset identifier, provenance chain, quality metrics, and any known limitations. This creates a verifiable record that data quality was assessed and documented before the data was used for training or fine-tuning.
AI-DATA.1 anchors should predate model training events (AI-MDL.1). Factor A identifies the dataset. Factor B records quality metrics. The auditor will look for completeness: every dataset used in training should have a corresponding AI-DATA.1 anchor. Cross-reference with AI-FAIR.1 to show that data quality assessment informed bias testing.
Risk Re-evaluation Through Drift Detection (Cl. 6.3)
ISO 23894 guidance: Risk evaluation is not a one-time activity. AI systems change over time as data distributions shift, user behavior evolves, and the operational environment changes. Organizations should implement continuous monitoring to detect when previously evaluated risks have changed in likelihood or impact, triggering risk re-evaluation.
How SWT3 addresses it: The witnessDrift() call detects model drift by comparing current behavior against the baseline established during risk evaluation. When drift exceeds configured thresholds, the anchor signals that risks should be re-evaluated. This closes the loop between initial risk evaluation (Cl. 6.3) and ongoing monitoring (Cl. 7).
AI-DRIFT.1 anchors at regular intervals demonstrate continuous risk monitoring (Cl. 7). A drift detection that exceeds threshold should trigger a new AI-RISK.1 assessment, showing the risk re-evaluation cycle is functioning. Factor A records the drift metric. Factor B records the threshold. Factor C records the baseline comparison period.
Risk Mitigation: Safe State Transition (Cl. 6.4.2)
ISO 23894 guidance: When risk treatment involves reducing risk through controls, organizations should implement safe fallback states that AI systems can transition to when risks materialize. This includes graceful degradation, human handoff, and shutdown procedures that maintain safety even when AI components fail or behave unexpectedly.
How SWT3 addresses it: The witnessSafeState() call records the transition to a safe state, including the trigger condition, the fallback mode activated, and the duration of the safe state. This proves that risk mitigation controls are not just documented but actually function when needed.
AI-SAFE.1 anchors demonstrate that Cl. 6.4.2 risk mitigation is implemented operationally, not just as a policy. Factor A identifies the trigger (drift, error rate, adversarial detection). Factor B records the fallback mode. Cross-reference with AI-INCIDENT.1 to show that safety transitions are logged as part of the incident response chain.
6. Quick Reference
| Auditor Question | Where to Look |
|---|---|
| Is the AI risk management scope defined? | AI-GOV.6 anchor. Factor A = scope definition. Factor C = criteria and boundaries. |
| Are AI-specific risks identified across all six categories? | AI-RISK.1 anchors. Check coverage: data (6.1.2), bias (6.1.3), transparency (6.1.4), autonomy (6.1.5), security (6.1.6), societal (6.1.7). |
| Has data quality risk been assessed? | AI-DATA.1 anchors for each dataset. Factor B = quality metrics. Must predate AI-MDL.1 training anchors. |
| Is bias risk being monitored? | AI-FAIR.1 at regular intervals. Factor A = protected attribute. Factor B = metric value. |
| Is human oversight maintained? | AI-HITL.1 anchors. Ratio of reviewed to total decisions shows oversight coverage for Cl. 6.1.5. |
| Are risks re-evaluated when conditions change? | AI-DRIFT.1 detects change. New AI-RISK.1 after drift = re-evaluation cycle functioning. |
| Do risk mitigation controls function operationally? | AI-SAFE.1 anchors prove safe state transitions occur. AI-PMM.1 proves ongoing monitoring. |
| How does this map to ISO 42001 Clause 6.1? | All ISO 23894 procedures directly support ISO 42001 Cl. 6.1. See ISO 42001 crosswalk. |
7. Quick Start
pip install swt3-ai
# Initialize with the ISO AI governance profile
swt3 init --profile iso-ai-governance --tenant YOUR_TENANT
# Run the demo to see witness anchors generated
python -m swt3_ai.demo
# Or use TypeScript
npm install @tenova/swt3-ai
npx swt3-init --profile iso-ai-governance
Full SDK documentation: sovereign.tenova.io/docs
Create a free account: sovereign.tenova.io/signup
8. References
- ISO/IEC 23894:2023 -- Information technology -- Artificial intelligence -- Guidance on risk management
- ISO/IEC 42001:2023 -- AI management systems
- ISO 31000 -- Risk management
- GAICC: AI Risk Management under ISO/IEC 23894
- Related: ISO 42001 Crosswalk
- Related: ISO 42001 Assessor Workpaper
- Related: TUV Rheinland ISO 42001 Evidence Guide
- SWT3 UCT Registry, 280 procedures across 9 namespaces
- SDK Documentation, Python, TypeScript, and 5 additional language SDKs