ISO 42001 Statement of Applicability
The Statement of Applicability (SoA) is the record that links your AI risk treatment to the 38 Annex A controls of ISO/IEC 42001: which controls you apply, which you exclude and why, and how far each one is implemented. Below, what it records, how to justify exclusions and a template row for every control, described in our own words.
Where the SoA comes from
- Assess the risks of the AI systems in scope (clause 6.1.2).
- Choose a treatment for each risk and the controls that carry it out (clause 6.1.3).
- Compare those controls with Annex A so nothing needed is missed; add your own controls where Annex A has no match.
- Record the result for every Annex A control in the Statement of Applicability, and have the risk owners approve it with the risk treatment plan.
The Annex A controls guide explains each control, and the ISO 42001 checklist lists the SoA among the documents an auditor asks for.
What each row records
- The control: its Annex A reference and topic.
- Included or excluded: whether your risk treatment needs it for the AI systems in scope.
- Justification: why it is included (the risks it treats, a legal or customer requirement) or why it is excluded.
- Implementation status: in place, partly in place or planned, with a target date for anything not finished.
- Evidence: where an auditor can see the control working: a policy, a register, a log, a report.
Justifying an exclusion
An exclusion is credible when it follows from your scope and roles, not from effort. "We don't develop AI systems; we only use third-party AI services" is a reason to exclude development-stage controls; "not enough time" isn't. If you exclude a control, check that no risk in your risk register relies on it, and revisit the decision when your scope changes. The certification guide explains how the Stage 1 audit reviews these documents.
Common audit findings on the SoA
- Controls marked "included" with no evidence that they operate.
- Exclusions with no reason, or a reason that contradicts the scope statement.
- A SoA that doesn't match the risk treatment plan (a control the plan relies on is excluded, or the other way round).
- No version history or approval, so nobody can tell which decisions are current.
Template: every Annex A control
One row per control (38 rows under 9 objectives). Copy it into your own document, or let the gap assessment fill it from your answers.
| Control | Topic (our summary) | Included? | Justification | Typical evidence |
|---|---|---|---|---|
| A.2.2 | AI policy | Yes / No | AI policy document | |
| A.2.3 | Alignment with other policies | Yes / No | Policy cross-reference or mapping | |
| A.2.4 | Review of the AI policy | Yes / No | Policy review record | |
| A.3.2 | AI roles and responsibilities | Yes / No | Role descriptions; AI RACI | |
| A.3.3 | Reporting of concerns | Yes / No | Concern-reporting procedure; channel details | |
| A.4.2 | Resource documentation | Yes / No | AI system resource inventory | |
| A.4.3 | Data resources | Yes / No | Data inventory per AI system | |
| A.4.4 | Tooling resources | Yes / No | Tooling and model inventory | |
| A.4.5 | System and computing resources | Yes / No | Infrastructure inventory | |
| A.4.6 | Human resources | Yes / No | Staffing and skills plan | |
| A.5.2 | Impact assessment process | Yes / No | Impact assessment procedure | |
| A.5.3 | Documenting impact assessments | Yes / No | Stored impact assessment reports | |
| A.5.4 | Impact on individuals and groups | Yes / No | Individual and group impact analysis | |
| A.5.5 | Societal impacts | Yes / No | Societal impact analysis | |
| A.6.1.2 | Objectives for responsible development | Yes / No | Responsible AI development objectives | |
| A.6.1.3 | Responsible design and development processes | Yes / No | Development process with review gates | |
| A.6.2.2 | Requirements and specification | Yes / No | Requirements specifications | |
| A.6.2.3 | Design and development records | Yes / No | Design documents; decision records | |
| A.6.2.4 | Verification and validation | Yes / No | Test plans and results; acceptance criteria | |
| A.6.2.5 | Deployment | Yes / No | Deployment checklist; release approval | |
| A.6.2.6 | Operation and monitoring | Yes / No | Monitoring dashboards; operations runbook | |
| A.6.2.7 | Technical documentation | Yes / No | Technical documentation set | |
| A.6.2.8 | Event logs | Yes / No | Logging configuration; retention settings | |
| A.7.2 | Data for development and enhancement | Yes / No | Data management procedure | |
| A.7.3 | Acquisition of data | Yes / No | Data source register; licences or consents | |
| A.7.4 | Data quality | Yes / No | Data quality rules and check results | |
| A.7.5 | Data provenance | Yes / No | Lineage records | |
| A.7.6 | Data preparation | Yes / No | Data preparation procedures | |
| A.8.2 | Information for users | Yes / No | User documentation; AI notices | |
| A.8.3 | External reporting | Yes / No | External reporting channel | |
| A.8.4 | Communicating incidents | Yes / No | Incident communication plan | |
| A.8.5 | Information for interested parties | Yes / No | Register of reporting obligations | |
| A.9.2 | Processes for responsible use | Yes / No | Responsible use procedure | |
| A.9.3 | Objectives for responsible use | Yes / No | Responsible use objectives | |
| A.9.4 | Intended use and human oversight | Yes / No | Intended use statements; oversight records | |
| A.10.2 | Allocating responsibilities | Yes / No | Responsibility matrix in contracts | |
| A.10.3 | Suppliers | Yes / No | Supplier assessments; contract clauses | |
| A.10.4 | Customers | Yes / No | Customer requirements; terms of use |
Control references follow ISO/IEC 42001:2023; topics and evidence are our own descriptions. The standard itself is available from ISO (iso.org/standard/42001).
Questions
Is a Statement of Applicability required for ISO 42001?
Yes. Clause 6.1.3 (AI risk treatment) asks for one: a record of the controls your risk treatment needs, whether each Annex A control is included or excluded, and why. Certification auditors read it early, because it defines what they will test.
When can an Annex A control be excluded from the SoA?
When a control isn't needed to treat the AI risks of the systems in scope, for example the data-for-development controls when you only use AI services built by others. Every exclusion needs a written reason. The clause 4 to 10 requirements can't be excluded.
How often should the Statement of Applicability be updated?
Whenever your AI risk treatment changes: a new AI system in scope, a new supplier, a changed role, or a risk assessment that calls for a new control. Most organisations also review it before each internal audit and management review.
Is there a Statement of Applicability template for Excel?
Yes. The free gap assessment on this site builds a draft Statement of Applicability from your answers as an .xlsx file with live formulas, covering all 38 Annex A controls.
Sources
- ISO/IEC 42001:2023 (ISO): edition 1, published December 2023, 51 pages, ISO/IEC JTC 1/SC 42.
- Each source was opened and checked on 1 October 2026.