# ISO 42001 Statement of Applicability Template

**Organisation:** [ORGANISATION NAME]
**Owner:** [NAME / ROLE]
**Date:** [DATE]
**Version:** 1.0

---

## Purpose

The Statement of Applicability (SoA) is one of the first documents an ISO/IEC 42001 certification auditor asks for. It lists every reference control in Annex A of the standard and records, for each one, whether the control applies to your organisation, why it applies (or why it does not), how far implementation has progressed, and where the evidence lives.

The SoA sits between two other documents in your AI Management System (AI MS):

- **The AI risk assessment** identifies what could go wrong with your AI systems. Every control you declare applicable should trace back to a risk, a legal or contractual requirement, or an organisational objective identified there.
- **The gap analysis** measures how mature your management system is against the requirements of Clauses 4 to 10. Aona's companion ISO 42001 Gap Analysis Template covers those clauses; this SoA covers the 38 Annex A controls. Together the two documents span the whole standard.

Annex A is a reference set, not a mandatory checklist. You select the controls that address your risks, justify every selection and every exclusion, and implement the applicable controls proportionately. The SoA is the record of those decisions, and it drives the certification audit plan: auditors sample applicable controls from your SoA and test the evidence behind them.

---

## How to Use

1. Complete or refresh your AI risk assessment and AI system impact assessments first. Control selection must trace back to identified risks, obligations, or objectives, so the SoA cannot be written in isolation.
2. Work through each Annex A control in the tables below with your AI governance team. Involve the people who run the controls, not just the people who document them.
3. Mark each control Applicable (Y) or Not Applicable (N). Excluding a control is legitimate, but only when the risk or activity it addresses genuinely does not exist in your organisation.
4. Write a justification for every control, applicable or not. Use the guidance and worked examples in the next section. This is the part auditors read most closely.
5. For each applicable control, record the implementation status (Not started / In progress / Implemented), a pointer to the evidence (policy reference, system name, log location, register entry), and a named owner.
6. Route the completed SoA through the approval block at the end, then keep it under version control. Re-issue it whenever the risk assessment changes, AI systems are added or retired, or an incident exposes a control gap.

**Status scale:** Not started · In progress · Implemented

---

## Scope and Inputs

Record what this SoA covers and which documents it draws on. Auditors use this block to confirm the SoA, the risk assessment, and the AI MS scope statement line up.

| Item | Reference | Version / date |
|------|-----------|----------------|
| AI Management System scope statement | [e.g. AIMS-SCOPE-01] | |
| AI risk assessment this SoA traces to | [e.g. RA-AI-2026] | |
| AI system impact assessments considered | [references] | |
| AI system inventory snapshot used | [e.g. INV-2026-Q2] | |
| Gap analysis (Clauses 4 to 10) companion document | [e.g. Aona ISO 42001 Gap Analysis] | |

### Coverage summary

Complete this after filling in the control tables. It gives management and auditors the headline picture in one glance.

| Area | Controls | Applicable | Excluded | Implemented | In progress | Not started |
|------|----------|------------|----------|-------------|-------------|-------------|
| A.2 Policies for AI | 3 | | | | | |
| A.3 Internal organisation | 2 | | | | | |
| A.4 Resources for AI systems | 5 | | | | | |
| A.5 Assessing impacts of AI systems | 4 | | | | | |
| A.6 AI system lifecycle | 9 | | | | | |
| A.7 Data for AI systems | 5 | | | | | |
| A.8 Information for interested parties | 4 | | | | | |
| A.9 Use of AI systems | 3 | | | | | |
| A.10 Third-party and customer relationships | 3 | | | | | |
| **Total** | **38** | | | | | |

---

## Writing Good Justifications

A justification explains the decision, not the control. Weak justifications are the most common SoA finding in certification audits, so apply these rules:

- **Trace to something specific.** Cite the risk register entry, legal obligation, contract clause, or business objective that makes the control necessary. "Addresses risk R-014: unmonitored model drift in the credit-scoring model" is auditable. "Industry best practice" is not.
- **Name the mechanism.** Say what actually implements the control: the policy, the process, the tool, the review. A justification that could be true of any organisation is a red flag.
- **Do not restate the control title.** "We have an AI policy because an AI policy is required" tells the auditor nothing about your reasoning.
- **Exclusions must show the risk is absent, not inconvenient.** "We do not train or fine-tune models, so no training-data pipeline exists" can support an exclusion. "We lack the resources this year" cannot: that is an applicable control that has not been implemented, and it belongs in your remediation plan, not in an exclusion.
- **Keep it short.** One to three sentences per control. Detail belongs in the evidence, not the SoA.

### Worked example 1: control included and implemented

| Field | Entry |
|-------|-------|
| Control | A.6.2.6 Ongoing operation and monitoring of deployed AI systems |
| Applicable | Y |
| Justification | Addresses risks R-014 (model drift in the credit-scoring model) and R-021 (silent degradation of the support chatbot). Monitoring thresholds and escalation paths are defined in the Model Operations Procedure (POL-AI-07). |
| Status | Implemented |
| Evidence reference | POL-AI-07 v2.1; monthly model performance reports in the governance folder; alert configuration in the MLOps platform |
| Owner | Head of ML Engineering |

### Worked example 2: control excluded

| Field | Entry |
|-------|-------|
| Control | A.7.6 Preparation of data for AI development (cleaning, labelling, transformation) |
| Applicable | N |
| Justification | The organisation does not develop, train, or fine-tune AI models. All AI capability is procured as vendor-hosted services, so no training-data preparation pipeline exists. Vendor data-handling obligations are covered under A.10.3. Decision to be revisited if in-house model development begins (see change triggers in the version-control section). |
| Status | Not applicable |
| Evidence reference | AI system inventory INV-2026-Q2 showing no in-house model development |
| Owner | AI Governance Lead |

### Worked example 3: control applicable but partially implemented

| Field | Entry |
|-------|-------|
| Control | A.6.2.8 Retention of event logs for AI systems |
| Applicable | Y |
| Justification | Addresses risk R-009 (inability to reconstruct AI-assisted decisions during complaints or incidents) and supports evidence obligations under the incident-response procedure. |
| Status | In progress |
| Evidence reference | Prompt and response logging live for the customer chatbot (log store LS-04); logging for the two internal copilots scheduled for Q3 2026 (project AIMS-12) |
| Owner | Security Operations Manager |

An "In progress" entry is not a failure. Auditors expect a realistic SoA with a credible plan far more than a document claiming everything is finished.

---

## Statement of Applicability: Annex A Controls

Work through each control objective area in turn. The control descriptions below are paraphrased summaries; consult the ISO/IEC 42001:2023 standard for the authoritative control text.

### A.2 Policies for AI

Objective area: management sets and maintains a clear written direction for how the organisation develops and uses AI.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.2.2 | A documented policy governing the development and use of AI across the organisation | | | | | |
| A.2.3 | Keeping the AI policy consistent with other organisational policies (security, privacy, HR, procurement) | | | | | |
| A.2.4 | Reviewing the AI policy at planned intervals so it stays accurate and effective | | | | | |

### A.3 Internal organisation

Objective area: accountability for AI is clearly assigned and concerns can be raised safely.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.3.2 | Defining and allocating roles, responsibilities, and authorities for AI across the lifecycle | | | | | |
| A.3.3 | A defined channel for staff and others to report concerns about the organisation's AI systems | | | | | |

### A.4 Resources for AI systems

Objective area: the organisation knows and documents what each AI system depends on.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.4.2 | Identifying and documenting the resources each AI system requires | | | | | |
| A.4.3 | Documenting the data resources used to develop and operate AI systems | | | | | |
| A.4.4 | Documenting the tooling resources behind AI systems (frameworks, libraries, platforms) | | | | | |
| A.4.5 | Documenting the system and computing resources AI systems run on | | | | | |
| A.4.6 | Documenting the human resources and competencies AI systems depend on | | | | | |

### A.5 Assessing impacts of AI systems

Objective area: the consequences of AI systems for people and society are assessed and recorded.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.5.2 | A defined process for assessing the impacts of AI systems throughout their lifecycle | | | | | |
| A.5.3 | Documenting and retaining the results of AI system impact assessments | | | | | |
| A.5.4 | Assessing how AI systems affect individuals and groups of individuals | | | | | |
| A.5.5 | Assessing the broader societal effects of AI systems | | | | | |

### A.6 AI system lifecycle

Objective area: AI systems are designed, built, verified, deployed, and operated under defined, responsible processes.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.6.1.2 | Setting objectives that guide responsible AI development | | | | | |
| A.6.1.3 | Defined processes for responsible AI system design and development | | | | | |
| A.6.2.2 | Specifying and documenting the requirements each AI system must meet | | | | | |
| A.6.2.3 | Documenting design and development choices for each AI system | | | | | |
| A.6.2.4 | Verifying and validating AI systems against their requirements before release | | | | | |
| A.6.2.5 | Deploying AI systems in a planned, controlled way | | | | | |
| A.6.2.6 | Operating deployed AI systems under defined processes with ongoing monitoring | | | | | |
| A.6.2.7 | Maintaining technical documentation for each AI system | | | | | |
| A.6.2.8 | Recording and retaining event logs for AI systems | | | | | |

### A.7 Data for AI systems

Objective area: the data feeding AI systems is sourced, understood, and managed with discipline.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.7.2 | Managing the data used to develop and improve AI systems | | | | | |
| A.7.3 | Controls over how data for AI systems is acquired and selected | | | | | |
| A.7.4 | Ensuring the data used by AI systems meets defined quality requirements | | | | | |
| A.7.5 | Recording where AI data comes from and how it has changed (provenance) | | | | | |
| A.7.6 | Preparing data for AI development in a controlled way (cleaning, labelling, transformation) | | | | | |

### A.8 Information for interested parties

Objective area: the people affected by, using, or overseeing AI systems get the information they need.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.8.2 | Providing users with the documentation and information they need about the AI system | | | | | |
| A.8.3 | A route for external parties to report adverse impacts and for the organisation to respond | | | | | |
| A.8.4 | Communicating AI incidents to affected and interested parties | | | | | |
| A.8.5 | Providing interested parties with information about their obligations and the system's characteristics | | | | | |

### A.9 Use of AI systems

Objective area: the organisation uses AI systems responsibly and as intended.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.9.2 | Defined processes governing the responsible use of AI systems | | | | | |
| A.9.3 | Setting objectives that guide responsible AI use | | | | | |
| A.9.4 | Ensuring AI systems are used according to their intended purpose and documentation | | | | | |

### A.10 Third-party and customer relationships

Objective area: responsibilities are clear when AI capability is bought, supplied, or delivered to customers.

| Ref | Control (paraphrased) | Applicable (Y/N) | Justification | Status | Evidence reference | Owner |
|-----|----------------------|------------------|---------------|--------|--------------------|-------|
| A.10.2 | Allocating AI responsibilities clearly between the organisation, suppliers, partners, and customers | | | | | |
| A.10.3 | Managing the risks of suppliers that provide AI systems, components, or data | | | | | |
| A.10.4 | Ensuring customer needs and obligations are considered when providing AI systems or services | | | | | |

---

## Version Control and Approval

The SoA is a living certification document. Auditors check not only its content but whether it has been maintained and re-approved as the AI MS changed.

### Document history

| Version | Date | Author | Summary of changes | Approved by |
|---------|------|--------|--------------------|-------------|
| 0.1 | [DATE] | [NAME] | Initial draft for governance team review | |
| 1.0 | [DATE] | [NAME] | First approved issue | [NAME / ROLE] |
| | | | | |

### Approval

| Role | Name | Signature | Date |
|------|------|-----------|------|
| AI Management System owner | | | |
| Top management sponsor | | | |
| Risk owner (review) | | | |

### Change triggers

Re-review and re-issue the SoA when any of the following occurs, and at least annually:

- The AI risk assessment or an AI system impact assessment is updated with new or changed risks
- AI systems are added, materially changed, or decommissioned
- The scope of the AI MS changes (new business units, markets, or use cases)
- An incident, audit finding, or non-conformity exposes a control gap
- Regulatory or contractual obligations change
- Before every certification, surveillance, or recertification audit

---

## Common Audit Findings to Avoid

- **Weak or circular justifications.** Justifications that restate the control title, cite "best practice" without a traceable risk or requirement, or repeat identical wording across dozens of controls. Auditors read the justification column first; make each entry specific.
- **Orphaned controls.** Controls declared applicable with no owner, no evidence reference, or no implementation activity behind them; or the reverse, controls that are demonstrably operating but missing from the SoA. Both undermine confidence in the whole document.
- **Stale evidence.** Evidence references pointing to superseded policies, logs that stopped collecting months ago, or reports for AI systems that have since changed. Check every reference during each SoA review, not just the rows you edited.
- **Mismatch with the risk assessment.** Risks in the register with no corresponding applicable control, or applicable controls that trace to no risk, requirement, or objective. The two documents are audited side by side.
- **Unjustified or defensive exclusions.** Controls marked not applicable because implementation is hard, unfunded, or planned for later. If the underlying risk or activity exists, the control is applicable and its status is simply Not started or In progress.
- **No maintenance trail.** A single approved version from the certification push, untouched since, while systems, risks, and suppliers changed. Keep the document history table honest; it is evidence of Clause 10 improvement working.

---

*Provided free by [Aona AI](https://aona.ai). Aona discovers every AI tool in use across your organisation, monitors what data flows into them, and keeps your AI inventory audit-ready.*