According to the ISO Survey of Management System Standards 2024, overall ISO certification grew 20% year-on-year in 2024 and ISO/IEC 42001, published in December 2023, is one of the fastest-growing new standards in that cohort. Yet the document that sits at the centre of every ISO 42001 certification audit the Statement of Applicability (SoA) remains poorly understood by most compliance teams encountering it for the first time.
That gap matters. The SoA is the first document an auditor asks for during a Stage 1 review, and its quality frequently determines the tone of the entire audit. Get it right, and you demonstrate a mature, risk-driven AI Management System (AIMS). Get it wrong vague justifications, missing exclusion rationale, controls listed without implementation evidence and you face nonconformities before Stage 2 has even started.
This guide explains exactly what the ISO 42001 Statement of Applicability must contain, walks through how to complete it, and provides a structured template your team can put to use immediately.
What Is the ISO 42001 Statement of Applicability?
The Statement of Applicability is a mandatory document under Clause 6.1.3 of ISO/IEC 42001:2023. It lists every control in Annex A of the standard all 38 of them and records whether each control has been included in or excluded from the organisation’s AIMS, together with a documented justification for that decision.
The SoA is not a policy or a procedure. It is a declaration: a formal record of the control decisions your organisation has made, grounded in the results of your AI risk assessment and AI System Impact Assessment. Its purpose is to make the relationship between your risk profile and your control set explicit and auditable.
Key clause reference: ISO/IEC 42001:2023, Clause 6.1.3 AI risk treatment. The organisation shall produce a Statement of Applicability that contains the necessary controls and provides justification for inclusion and exclusion of controls.
Three things make the ISO 42001 SoA different from the SoA you may already know from ISO 27001:
- 38 AI-specific controls, not ISO 27001’s 93 information security controls. The domains cover AI policy, internal organisation, resources, AI system lifecycle management, data, system information, use of AI systems, and third-party relationships.
- A mandatory AI System Impact Assessment (Clause 6.1.4) feeds into control selection alongside the risk assessment. This is unique to ISO 42001.
- Controls are not automatically mandatory but every Annex A control must be addressed in the SoA, even those excluded. Silence is not a valid exclusion.
Why the SoA Is the Most Auditor-Scrutinised Document in Your AIMS
In ISO 42001 certification audits, the SoA functions as the auditor’s map. Stage 1 is essentially a documentation review the auditor reads the SoA, compares it against the scope statement and risk assessment, and decides whether the AIMS design is sound enough to proceed to Stage 2. A thin or generic SoA signals that the organisation has treated ISO 42001 as a paperwork exercise rather than a governance discipline.
What auditors look for specifically:
- Traceability: Can each control decision be traced back to a specific risk or impact assessment finding? Justifications that say ‘applicable to our business’ without referencing a risk will not hold up.
- Completeness: Every Annex A control must appear. Missing a domain entirely even if all controls in it are excluded is a gap.
- Specificity of exclusions: Excluded controls need real reasons. The standard permits exclusions where the risk does not apply or is mitigated by other means, but the burden of proof is on the organisation to explain why.
- Implementation evidence: Included controls must reference the document, procedure, or system where implementation can be verified. An SoA that lists controls as ‘applicable’ with no evidence pointer is a Stage 2 nonconformity waiting to happen.
The most common audit nonconformity related to the SoA is not missing controls it is missing justifications. Specifically: the Statement of Applicability requires justification for both inclusions AND exclusions, a distinction that catches many first-time implementers off guard.
The Eight Domains of ISO 42001 Annex A: What Your SoA Must Cover
Annex A of ISO/IEC 42001:2023 organises its 38 reference controls into eight domains. Understanding these domains before building the SoA helps teams assign ownership, group related controls, and avoid gaps in coverage.
| Domain | Controls | What the SoA Must Address |
|---|---|---|
| A.2 AI Policies | A.2.2 | Existence of a documented AI policy; scope and review cycle |
| A.3 Internal Organisation | A.3.1, A.3.2 | Role definitions, RACI assignments, oversight committee charter |
| A.4 Resources for AIMS | A.4.1, A.4.2 | Resourcing plan, AI system documentation / model records |
| A.5 AI System Lifecycle | A.5.1–A.5.7 | Lifecycle procedure covering dev, test, deploy, operate, retire |
| A.6 Data for AI Systems | A.6.1, A.6.2 | Data quality, provenance, labelling, anonymisation controls |
| A.7 System Information | A.7.1, A.7.2 | Transparency disclosures; model registry maintenance |
| A.8 Use of AI Systems | A.8.1 – A.8.4 | Acceptable use, human oversight requirements, safeguards, ethics |
| A.9 Third-Party Relationships | A.9.1, A.9.2 | Supplier due diligence, customer communication controls |
A Note on Custom Controls
ISO 42001 explicitly permits and in many cases expects custom controls that go beyond Annex A where the organisation’s AI risk profile demands it. A financial services firm deploying AI in credit decisioning may need controls around model explainability and adverse action documentation that Annex A does not prescribe in sufficient detail. A healthcare organisation using AI diagnostics may add controls tied directly to FDA or state-level AI medical device requirements.
Custom controls belong in the SoA alongside the Annex A controls. They are subject to the same justification and implementation evidence requirements and will be reviewed during Stage 2.
How to Build Your ISO 42001 Statement of Applicability: A Step-by-Step Process
The SoA is not the starting point it is the output of a structured process. Teams that try to fill in the SoA template before completing the upstream steps almost always produce a document that fails audit scrutiny. Here is the correct sequence.
Step 1: Define the AIMS Scope
Before any control can be assessed for applicability, Clause 4.3 requires the organisation to document the boundaries and applicability of the AIMS. The scope determines which AI systems, organisational units, and processes are subject to governance and therefore which controls are candidates for inclusion.
A scope that reads ‘all AI-related activities of XYZ Organisation’ sounds thorough but is functionally meaningless to an auditor. The scope must name or define with sufficient specificity to be auditable the AI systems it covers. Vague scopes generate vague SoAs.
Step 2: Conduct the AI Risk Assessment (Clause 6.1.2)
The AI risk assessment evaluates the likelihood and severity of risks that could prevent the organisation from achieving its AI governance objectives. Risks commonly assessed include algorithmic bias, data poisoning, model drift, lack of transparency in automated decisions, and inadequate human oversight for high-stakes outputs.
Risk assessment findings drive control selection. A high-severity bias risk, for example, naturally leads to the inclusion of controls in A.5 (lifecycle), A.6 (data), and A.8.4 (responsible use). Document the connection explicitly auditors will look for it.
Step 3: Conduct the AI System Impact Assessment (Clause 6.1.4)
This is the requirement that most distinguishes ISO 42001 from its ISO sibling standards. The AI System Impact Assessment (AISIA) evaluates the potential consequences of deploying a specific AI system on individuals, groups, and society including foreseeable misuse, unintended effects, and interactions with vulnerable populations.
The AISIA is not a risk register. It examines external impact rather than internal risk. Its findings should feed directly into the SoA: if a system’s impact assessment identifies a high probability of harm to individuals through automated decision-making, controls such as A.8.2 (human oversight) become substantially harder to exclude.
Step 4: Select Controls and Cross-Reference Annex A
Using both the risk assessment and impact assessment results, identify the controls needed to treat each risk and mitigate each identified impact. Then cross-reference your selected controls against the full Annex A list to confirm no necessary control has been overlooked.
This cross-reference step is a specific requirement of Clause 6.1.3. Its purpose is to ensure that the Annex A controls serve as a completeness check the organisation cannot simply choose controls in isolation from risk treatment without considering what the standard considers best practice for AI governance.
Step 5: Document the SoA
With control decisions made and justified, the SoA can now be compiled. Use a structured format a spreadsheet or compliance platform is typical that captures each of the following for every Annex A control:
- Control reference and name
- Applicable (Yes / No)
- Justification for inclusion or exclusion, referencing specific risk or impact assessment findings
- Implementation status (Implemented / In Progress / Planned)
- Owner and evidence reference (policy number, procedure title, system record)
The SoA then requires management sign-off. As a maintained document under Clause 7.5, it must have version control, a review date, and a clear owner. It is not a one-and-done deliverable it is a living document that must be updated whenever material changes occur to the AI systems in scope, the risk landscape, or applicable regulations.
ISO 42001 Statement of Applicability: Template
The table below provides a working SoA template pre-populated with all domains from Annex A. Adapt the justification and evidence columns to reflect your organisation’s specific context. Implementation status entries are illustrative; yours will vary based on AIMS maturity.
| Control Reference | Control Name | Applicable (Y/N) | Justification for Inclusion/Exclusion | Implementation Status | Owner / Evidence Reference |
|---|---|---|---|---|---|
| A.2.2 | AI policy | Y | Defines organisation-wide governance direction for all AI systems in scope. | Implemented | AI Policy v1.2 / AIMS-DOC-001 |
| A.3.1 | Roles and responsibilities | Y | Assigns accountability for AI risk ownership across development and deployment teams. | Implemented | RACI Matrix / AIMS-DOC-004 |
| A.4.1 | Resources for AI systems | Y | Ensures sufficient budget, tooling, and personnel are allocated to AIMS operations. | In Progress | Resource Plan Q2 |
| A.4.2 | AI system documentation | Y | Required to maintain auditable records of model architecture, training data, and intended use. | Implemented | Model Registry v2.0 |
| A.5.1 | AI system life cycle | Y | Governs development, testing, deployment, and retirement of all in-scope AI systems. | Implemented | Lifecycle Procedure AIMS-P-003 |
| A.5.2 | AI system requirements | Y | Captures functional and non-functional requirements including ethical constraints. | Implemented | Requirements Register |
| A.5.3 | AI system development | Y | Controls for responsible model design including bias mitigation at build stage. | In Progress | Dev Standards v0.8 |
| A.5.4 | AI system verification and validation | Y | Ensures models meet stated requirements prior to deployment. | Implemented | V&V Procedure AIMS-P-007 |
| A.5.5 | AI system deployment | Y | Controls for staged rollout, monitoring activation, and human oversight triggers. | In Progress | Deployment Runbook |
| A.5.6 | AI system operation | Y | Ongoing monitoring of live model performance, fairness indicators, and error rates. | Implemented | Ops Monitoring Dashboard |
| A.5.7 | AI system decommissioning | Y | Process for retiring models safely, including data retention and stakeholder notification. | Planned | Decommission SOP (Draft) |
| A.6.1 | Data for AI systems | Y | Controls for training data quality, provenance, and bias assessment. | Implemented | Data Governance Policy |
| A.6.2 | Data preparation for AI systems | Y | Pre-processing standards including anonymisation, labelling, and format controls. | In Progress | Data Prep Procedure |
| A.7.1 | Information for interested parties | Y | Transparency obligations to users, regulators, and affected individuals. | Implemented | Transparency Disclosures |
| A.7.2 | Record of AI systems | Y | Maintains the AI system inventory (model registry) required by Clause 4.3 scope. | Implemented | Model Registry v2.0 |
| A.8.1 | Use of AI systems – organisational controls | Y | Governs acceptable use policies, user training, and escalation paths. | Implemented | Acceptable Use Policy |
| A.8.2 | Use of AI systems – human oversight | Y | Defines human-in-the-loop requirements for high-risk AI decisions. | Implemented | Human Oversight SOP |
| A.8.3 | Use of AI systems – safeguards | Y | Technical and procedural safeguards to prevent misuse or harmful outputs. | In Progress | Safeguards Register |
| A.8.4 | Responsible use of AI | Y | Ethical use framework covering fairness, accountability, and non-discrimination. | Implemented | Ethics Policy AIMS-DOC-012 |
| A.9.1 | Suppliers and third parties | Y | Due diligence and contract requirements for external AI providers and integrations. | In Progress | Vendor Assessment Template |
| A.9.2 | Customers and users | Y | Controls for communicating AI limitations, consent collection, and dispute resolution. | Planned | Customer Comms Framework |
Editorial note: The template above covers the core Annex A controls by domain. Your organisation’s SoA should list each of the 38 individual controls as separate rows. Controls in domains A.3, A.4, A.5, A.6, A.7, A.8, and A.9 contain multiple individual controls per domain that each require their own justification row.
ISO 42001 SoA vs ISO 27001 SoA: Key Differences
Organisations certified to ISO 27001 arrive at ISO 42001 implementation with a genuine head start. The document discipline transfers. The management sign-off process transfers. The cross-referencing methodology transfers. The AI-specific content does not.
| Dimension | ISO 42001 SoA | ISO 27001 SoA |
|---|---|---|
| Control Count | 38 AI-specific controls across 9 domains (Annex A) | 93 information security controls across 4 themes (Annex A) |
| Primary Focus | AI ethics, fairness, transparency, human oversight, lifecycle | Data confidentiality, integrity, availability, cybersecurity |
| Unique Requirement | AI System Impact Assessment feeds control selection (Clause 6.1.4) | No impact assessment requirement; risk assessment alone drives SoA |
| Custom Controls | Permitted and encouraged for AI-specific risks | Permitted but less common in practice |
| Living Document Cadence | High velocity: AI systems evolve rapidly; quarterly review recommended | Annual review standard; change-driven updates |
| Auditor Priority | SoA quality is the first indicator of AIMS maturity | SoA cross-referenced against risk register; both reviewed together |
The practical implication for ISO 27001-certified organisations: do not assume your existing SoA process maps cleanly onto ISO 42001. The upstream inputs AI risk assessment and AI System Impact Assessment are substantively different from an information security risk assessment. They require domain knowledge of AI systems, model behaviour, and AI-specific harm categories that your information security team may not possess without support from AI practitioners or a specialist governance platform.
Writing Exclusion Justifications That Will Survive Audit
Exclusion justifications are where most SoA drafts fall apart. The standard is clear: excluding a control without documented rationale is itself a nonconformity. Here is the difference between justifications that satisfy auditors and those that do not.
Weak exclusion justifications (avoid these)
- “Not applicable to our industry” no risk-based reasoning
- “We do not develop AI systems” true for some organisations, but this may exclude entire domain A.5 without accounting for the development activities of third-party AI providers in scope under A.9
- “Low risk” a conclusion, not a justification. Where does this assessment come from?
- “Covered by ISO 27001” ISO 42001 controls address AI-specific risks that ISO 27001 does not cover. Cross-certification does not substitute for AI governance controls
Strong exclusion justifications (use these patterns)
- Risk-based: “Control A.5.3 (AI system development) is excluded. The organisation does not develop or train AI models internally. All AI systems in scope are procured as licensed third-party products. Development-phase risks are addressed through supplier due diligence controls under A.9.1. This assessment is supported by [Risk Assessment finding R-14].”
- Scope-based: “Control A.6.2 (data preparation) is excluded for the customer segmentation model (System ID: AI-007) in scope. Training data for this system is provided by a third-party data vendor under a certified data governance programme. Data preparation controls are contractually required of the vendor and verified through annual supplier audit.”
- Regulatory exception: “Control A.8.4 provisions relating to fairness disclosures to end-users are applied at a reduced scope for the internal-only HR scheduling tool (System ID: AI-012). The tool does not produce decisions affecting employment status or compensation; its outputs are advisory to line managers who retain final decision authority.”
Maintaining the SoA as a Living Document
The ISO 42001 SoA is not completed once and filed. Clause 7.5 requires maintained documents to be kept current, and the standard’s continuous improvement expectations under Clause 10 mean the SoA must evolve with the organisation’s AI systems and risk profile.
Triggers for SoA review:
- A new AI system enters scope or an existing system changes materially in function, training data, or deployment context
- The AI risk assessment or AI System Impact Assessment is updated any change in risk ratings may shift control applicability
- Regulatory developments: a new U.S. state AI law, updated NIST AI RMF guidance, or EU AI Act enforcement actions affecting equivalent controls
- Audit findings: a Stage 2 nonconformity or surveillance audit observation related to a control in the SoA
- Organisational change: acquisition, outsourcing of AI functions, or change in AI governance ownership
Managing SoA updates manually across spreadsheets, email chains, and version-controlled documents works at small scale. At enterprise scale, with multiple AI systems in scope across business units and jurisdictions, the version control and audit trail requirements become significant. Platforms purpose-built for ISO 42001 implementation, such as Govern365.ai, maintain the SoA as a live record within the broader AIMS automatically linking control status to the AI model registry, risk assessment results, and audit evidence, so changes to one feed updates to the other without manual reconciliation.
Five Mistakes That Turn a Valid SoA Into an Audit Nonconformity
These are the patterns that appear most consistently across ISO 42001 Stage 1 reviews. Avoiding them before the auditor arrives is significantly less expensive than correcting them under time pressure.
- Leaving controls blank. A control row with no entry no yes/no, no justification is not an exclusion. It is a gap. Auditors treat unexplained silence as evidence that the control was not considered.
- Copying justifications across controls. Generic text pasted across multiple control rows (e.g., ‘standard best practice’) signals that the SoA was not built from a genuine risk assessment. Each control needs a justification tied to the specific risk or impact finding it addresses.
- Marking controls ‘implemented’ with no evidence reference. ‘Implemented’ is a claim, not a fact. Without a pointer to the procedure, record, or system where implementation can be verified, the claim cannot be tested at Stage 2.
- Excluding A.5 domain controls without supplier controls. Organisations that do not develop AI internally sometimes exclude all of Annex A.5 (AI System Lifecycle). This is only valid if A.9 (third-party controls) adequately addresses the lifecycle governance obligations for procured systems. The SoA must make this compensating relationship explicit.
- Treating the SoA as a one-time document. An SoA with a review date 18 months in the past, unsigned by current management, and reflecting AI systems that have since been retired or replaced will not survive surveillance audit. Version history, review dates, and management signatures are not formalities they are evidence of an active, maintained AIMS.
Frequently Asked Questions
Is the Statement of Applicability mandatory for ISO 42001 certification?
Yes. Clause 6.1.3 of ISO/IEC 42001:2023 explicitly requires a Statement of Applicability as a documented output of the AI risk treatment process. Without it, an organisation cannot proceed to Stage 2 certification audit. Auditors treat the SoA as the primary document for assessing whether Annex A controls have been considered, selected, and justified.
How many controls does the ISO 42001 SoA need to address?
The SoA must address all 38 controls in Annex A, even those deemed not applicable. For excluded controls, the organisation must provide a written justification explaining either that the risk is not present in their context or that it is mitigated by other means. Leaving a control blank with no explanation is itself a nonconformity.
Can we exclude controls from our ISO 42001 SoA?
Yes, but with a documented justification for each exclusion. Valid grounds include absence of the associated risk (for example, a pure AI-user organisation excluding development-phase controls), regulatory exceptions, or alternative compensating controls that address the same risk objective. Generic exclusions such as ‘not relevant to our business’ without risk-based reasoning will not satisfy auditors.
How does the AI System Impact Assessment affect the SoA?
The AI System Impact Assessment (Clause 6.1.4) is a distinctive ISO 42001 requirement with no direct equivalent in ISO 27001. Its findings feed directly into control selection: if the impact assessment identifies high-risk societal consequences for a deployed AI system, controls such as A.8.2 (human oversight) and A.8.3 (safeguards) become harder to exclude with justification. Impact assessment results should be referenced explicitly in the SoA.
What is the difference between an AI risk assessment and an AI system impact assessment under ISO 42001?
The risk assessment (Clause 6.1.2) evaluates internal risks the likelihood and severity of the organisation failing to achieve its AI governance objectives. The impact assessment (Clause 6.1.4) evaluates external consequences how a deployed AI system could affect individuals, groups, or society. Both outputs inform control selection in the SoA, but from different angles: risk drives what could go wrong internally; impact drives what harm could occur externally.
How often should the ISO 42001 Statement of Applicability be reviewed?
ISO 42001 requires the SoA to remain current. In practice, this means reviewing it whenever a new AI system enters scope, an existing system changes materially, the risk assessment is updated, or a regulatory change affects applicable controls. A minimum annual review cycle is standard, but organisations with rapidly evolving AI portfolios often conduct quarterly reviews to stay ahead of audit findings.
Can we reuse our ISO 27001 SoA for ISO 42001?
No. While both standards use the SoA format, ISO 42001’s Annex A contains 38 AI-specific controls that have no equivalent in ISO 27001’s information security control set. However, ISO 27001 experience does transfer: the document discipline, management sign-off process, and cross-referencing methodology are identical. Organisations certified to ISO 27001 can reach ISO 42001 SoA readiness significantly faster than those starting from scratch.
What happens if we add custom controls not in Annex A?
ISO 42001 explicitly permits custom controls. If a risk identified in your assessment is not addressed by any Annex A control, you are expected to define and document your own control, include it in the SoA, and justify its design. Custom controls are recorded alongside Annex A controls and are subject to the same audit scrutiny. They often arise in regulated sectors healthcare AI, financial services AI where sector-specific obligations exceed the Annex A baseline.
What To Do With This Template
The Statement of Applicability is, at its core, a decision record a document that shows auditors, regulators, and stakeholders that your organisation has thought carefully about every Annex A control, assessed it against your specific AI systems and risk profile, and made a documented, accountable decision about whether and how to implement it.
The template in this guide gives your team the structural starting point. The harder work is upstream: a rigorous AI risk assessment, a genuine AI System Impact Assessment, and control justifications written by people who understand both the standard’s requirements and your organisation’s actual AI systems.If your team is building the AIMS from scratch or approaching your first ISO 42001 audit, start your 14-day free trial of Govern365.ai, by the Global AI Certification Council a platform built by the people who wrote the certification standard, with the AI model registry, risk assessment tooling, and audit evidence management to take your SoA from template to audit-ready.
