Annexes C and D, and building the Statement of Applicability
Lesson 4 of 4 in Annex A Controls and Annexes B, C, D: The Control Framework.
Two more annexes complete the standard, and both are informative — thinking tools, not requirements.
Annex C is the standard’s gift to anyone staring at a blank risk register. It offers two lists made to be crossed: potential AI-related organisational objectives — fairness, security, safety, privacy, robustness, transparency and explainability, accountability, availability, maintainability, availability and quality of training data, AI expertise — and AI-specific risk sources — complexity of the environment, lack of transparency and explainability, level of automation, machine-learning-specific sources (data quality, drift, adversarial inputs), system hardware issues, lifecycle issues, and technology readiness. Pick the objectives that matter to your context, ask which risk sources threaten each one, and your risk assessment has a defensible starting universe instead of a brainstorm.
Annex D answers ‘does this work in my industry?’ Yes, deliberately: the AIMS applies across domains and sectors — health, finance, transport, defence, employment — and Annex D discusses how it integrates with sector-specific standards (medical device quality, financial model-risk rules) and with other generic management systems (ISO 9001, ISO/IEC 27001, ISO/IEC 27701). The message: 42001 expects to be one system among several, sharing the Harmonized Structure skeleton, not a silo.
| Objective (Annex C) | Most direct risk sources | Example failure it predicts |
|---|---|---|
Fairness | ML-related sources (data quality); lack of transparency | Skewed training labels reproduce past discrimination — the Amazon recruiting pattern |
Transparency & explainability | Lack of transparency and explainability; complexity of the environment | Credit denials that no one can explain to the applicant — or to the regulator |
Safety | Level of automation; technology readiness; environment complexity | An automated system acting faster or more autonomously than its oversight can catch — Uber ATG’s 2018 Tempe crash |
Security | ML-related sources (adversarial inputs, poisoning); system hardware issues | Adversarial evasion of a content filter; poisoned training data in a scraped corpus |
Privacy | ML-related sources (data quality, memorisation); lifecycle issues | A model regurgitating personal data it memorised during training |
Robustness | ML-related sources (drift); environment complexity; technology readiness | The Epic sepsis model’s real-world performance collapsing far below its advertised accuracy |
Accountability | Level of automation; lifecycle issues | ‘The algorithm decided’ — diffused ownership discovered only after the incident |
Building the SoA, step by step. The Statement of Applicability is the single most-examined document in a 42001 audit, because it is where risk, controls, and justification meet. The build sequence: (1) finish risk assessment and risk treatment; (2) list every Annex A control plus any additional controls you designed; (3) for each, mark applicable or not applicable; (4) justify both answers — applicable controls point to the risks they treat, exclusions explain why the risk or activity does not exist for you; (5) state implementation status; (6) version it, own it, and re-issue it when the risk picture changes.
Which controls are plausibly excludable depends almost entirely on the role determination you made back in clause 4.1. That is the single strongest lever on your SoA:
Pure user
An organisation that only uses third-party AI (say, a law firm using a commercial drafting assistant) can often justify excluding the development-side controls: A.6.2.2–A.6.2.4 (requirements, design documentation, V&V) and much of A.7 if it never assembles training data.
What it can almost never exclude: A.9 (responsible use — this is its core exposure), A.2/A.3 (policy and roles), A.5 (impacts on its clients still occur), A.10.3 (its vendor is a supplier), and A.4 (it still needs to inventory what it uses).
Developer / producer
An organisation that builds AI systems carries the full lifecycle weight: all of A.6, all of A.7, plus A.8 duties toward the deployers of what it ships.
Plausible exclusions are narrow — perhaps parts of A.9 if it genuinely never operates its own systems internally (rare: nearly everyone uses some AI). Auditors are rightly suspicious of developers with thin A.6/A.7 applicability.
Provider platform
An organisation offering AI as a service to others adds the outward-facing groupings at full strength: A.8 (documentation, incident communication, external reporting channels for affected parties) and A.10.4 (customer expectations — what your customers need from you to meet their obligations).
If it builds on someone else’s foundation model, it is simultaneously a customer upstream (A.10.2/A.10.3) and a supplier downstream (A.10.4) — both directions must appear in the SoA reasoning.
Walk the SoA: is this control applicable — and will the justification survive audit?
Interactive decision tree — outcomes:
- Audit-proof inclusion
This is the pattern auditors want: the control is traced to named risks in a versioned assessment. The Stage 2 auditor will now ask to see V&V records — the justification sets up the evidence trail.
- Survives, but invites digging
‘Best practice’ is not wrong, but it severs the link between risk treatment and control selection that clause 6.1.3 requires. Expect the auditor to ask ‘which risks does this treat?’ — and to probe whether your risk assessment drives anything at all.
- Defensible exclusion
Clean: the justification states a fact about your role (no development), and shows the residual concern (does the vendor test?) is picked up by another applicable control. Exclusions that redirect to a compensating control are the strongest kind.
- Major-nonconformity material
Cost is never a valid basis for excluding a control from applicability. If the risk exists, the control is applicable — you may phase implementation, but the SoA must say so honestly. ‘Too expensive’ tells the auditor risks are being retained silently, without the acceptance record clause 6.1.3 demands.
- Half right, dangerously incomplete
Relying on vendor testing can be legitimate — but ‘their problem entirely’ is not how accountability works. You still need A.10.3 supplier processes to verify the vendor’s V&V meets your requirements, and your fine-tuning (if any) reopens the control. Rewrite to show what you verify and under which control.
Key terms: Statement of Applicability, risk source, Annex A control (ISO 42001), role determination, shadow AI
Tool: AIMS Builder & Audit — Build your own Statement of Applicability: answer scoping questions about a fictional organisation, then toggle applicability and draft justifications for all 38 controls.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.