The ISO 42001 Statement of Applicability (SoA) is the documentation of all the controls your AI management system needs, with a justification for including or excluding each one, as defined in ISO/IEC 42001:2023, definition 3.26 (official preview). Published clause summaries describe clause 6.1.3 as requiring your AI risk treatment process to produce the SoA, containing the necessary controls and the justification for each inclusion and exclusion.
In practice the SoA is one table with a row per control. Each row says applied or excluded, why, which risks it answers, and where the evidence sits. It is the record a certification auditor opens first when testing Annex A. In the US, certification bodies that audit against ISO/IEC 42001 can be accredited under the ANAB ISO/IEC 42001 AIMS accreditation program, launched in January 2024.
What does ISO/IEC 42001 say a Statement of Applicability must contain?
ISO/IEC 42001 sets three rules for the SoA. The definition asks for all necessary controls plus a justification for each inclusion or exclusion. Its first note says you may not need every Annex A control and may add controls of your own. Its second note says every identified risk, and the controls that address it, must be reflected in the SoA.
Clause 6.1.3 produces the SoA as a step in risk treatment. You choose treatment options, determine the controls needed, compare them with the controls in Annex A to confirm nothing necessary is missing, and then record the result in the SoA and the risk treatment plan. Clause 8.3 then requires the plan to be implemented and checked in operation.
Two consequences follow. Annex A is normative (official preview table of contents), so every Annex A control gets a row, even one you exclude. And because the SoA comes out of risk treatment, it cannot be written before the risk assessment. Annex A groups its controls under control objectives, and Annex B (also normative) gives implementation guidance you can draw on when writing a justification. The order of the records is set out in the clause-by-clause ISO 42001 build. The full requirement text is in the ISO/IEC 42001:2023 standard on iso.org, which is a paid document.
How many controls go in an ISO 42001 SoA?
An ISO 42001 SoA lists every control in Annex A, plus any controls you add yourself. Published summaries commonly count 38 Annex A controls, while at least one SoA template ranking in US Google results in October 2026 counts 39. Build the rows from your licensed copy, not from a template.
An auditor checks that each Annex A control has a row and a decision, not that the total matches a number from a blog. The count, the nine objective areas and what each control asks for are covered in ISO 42001 Annex A controls grouped by theme.
Statement of Applicability columns, specified
An ISO 42001 SoA needs more columns than the definition implies, because each row must connect to risks and evidence. The specification below is AI Training Skool’s working layout.
| Column | What goes in it | Why the auditor cares |
| Control reference | Annex A number, or your own ID for added controls (for example ORG-01) | Shows every Annex A control has a row |
| Control title | The title from your licensed copy | Confirms you used the published control |
| Source | Annex A, organization-defined, or shared with another standard | Shows added controls are deliberate (definition 3.26, note 1) |
| Decision | Applied or excluded | The applicability decision itself |
| Justification | Why the control is needed, or why it is not, in one or two sentences | Required by definition 3.26 and clause 6.1.3 |
| Linked risks | Risk register IDs the control treats | Shows risks and controls are reflected (definition 3.26, note 2) |
| Linked impact assessments | Impact assessment record IDs, where the control addresses an impact | Shows clause 6.1.4 results reached treatment |
| Implementation status | Implemented, partly implemented, or planned with a date | Separates design from operation |
| Evidence location | Path or system where the proof sits | Lets the auditor sample without a hunt |
| Control owner | A named role | Shows accountability |
| Version, approver and date | Who approved this version and when | Shows control of documented information (7.5) |
Source: AI Training Skool SoA specification, October 2026, built on ISO/IEC 42001:2023 definition 3.26 and clause titles (official preview).
Real SoAs use the same core columns. Databricks’ public SoA for ISO/IEC 27001:2022 and related standards (version 8, updated 19 June 2024) has “Included”, “Implemented” and “Justification for inclusion or exclusion” columns for each standard it covers.
SoA justification patterns for inclusion and exclusion
A good SoA justification names the risk, system or obligation that makes the control necessary, or the fact that makes it unnecessary. A weak one restates the control or says “not applicable” with no reason.
| Decision | Weak justification | Good justification |
| Applied | “Required by ISO 42001.” | “Treats R-03 and R-07; AI policy needed to set approved tools and human review rules for all four in-scope systems.” |
| Applied | “Best practice.” | “Treats R-02; the fraud model is retrained quarterly and must pass verification before each release.” |
| Applied, organization-defined | “Extra control.” | “ORG-01 prompt filtering added for R-05, so prompt injection has a specific control the team can test each release.” |
| Excluded | “N/A.” | “No supplier provides AI systems, models or data within the AIMS scope; all four systems are built in-house on internal data (register reviewed 1 September 2026). Revisit if a supplier enters scope.” |
| Excluded | “Not relevant to our business.” | “The organization does not provide AI systems to customers; all systems are for internal use (scope statement v2). Revisit if any system is offered externally.” |
| Excluded | “Low risk.” | Avoid excluding on risk level alone. A low-scoring risk is a reason for a lighter control, not for no control, unless the risk is accepted under your criteria and the acceptance is recorded. |
Source: AI Training Skool examples, October 2026. Fictional systems and dates.
Three tests for any exclusion: it rests on a fact you can show (scope, register, contract), it names the condition that would reverse it, and no risk in the register points at the control. If a risk does point at it, the exclusion fails definition 3.26, note 2.
How each SoA row links to the risk register and evidence
Each SoA row sits in the middle of a chain: AI system register, impact assessment, risk register, SoA, risk treatment plan, evidence, internal audit. An auditor usually samples from both ends, starting with a risk and asking for its controls, or starting with a control and asking which risk it treats.
Make the chain visible with IDs, not prose. Every risk row in an ISO 42001 AI risk register lists SoA control references, and every applied SoA row lists risk IDs. Where a control addresses a harm to people, the row also cites the clause 6.1.4 record, written up from an AI system impact assessment question set. The evidence column then points to the proof: an approved policy, a test report, a contract clause, a training log.
A worked SoA extract from the AI Training Skool course
The SoA extract below starts from five representative rows of the SoA in our course, each with its decision and related clause. The justification and evidence columns are added here as an example for a fictional organization that builds all its AI systems in-house. Risk IDs are illustrative.
| Control | Decision | Related clause | Example justification | Example evidence |
| A.2.2 AI policy | Applied | 5.2 | Treats R-07 (unapproved tools); sets approved uses and review rules | AI policy v3, approved by the CEO; staff acknowledgement log |
| A.4.2 Resource documentation | Applied | 7.1 | Treats R-09 (models cannot be reproduced); records data, tooling and compute per system | Resource sheet for each register entry |
| A.5.2 AI system impact assessment process | Applied | 6.1 | All in-scope systems affect people; required to feed clause 6.1.4 results into risk | Impact assessment procedure; dated record per system |
| A.6.2.4 AI system verification and validation | Applied | 8.3 | Treats R-02 (drift); every release passes defined tests | Release test reports, signed by the model owner |
| A.10.3 Suppliers | Excluded | None (exclusion) | No supplier provides AI systems, models or data in scope (register reviewed 1 September 2026); revisit if one enters scope | Register extract; procurement confirmation |
Sources: decisions and related clauses from the AI Training Skool course. Control numbers and titles follow the matching Annex B guidance items (B.2.2, B.4.2, B.5.2, B.6.2.4, B.10.3) in the draft-era (FDIS) crosswalk contributed by Microsoft and listed on NIST’s AI Resource Center; the A numbers assume each control carries the same number as its guidance item, so confirm them in your licensed copy. Justification and evidence columns are fictional examples.
For the A.2.2 row, evidencing an AI policy for an ISO 42001 audit shows which records an auditor expects behind the policy.
The A.10.3 row shows the pattern for a defensible exclusion: a checkable fact, a date, and a reversal condition. If the organization later buys a vendor model, the exclusion flips to applied and the risk register gains a supplier risk.
Common nonconformities in an ISO 42001 SoA
The SoA findings below are typical in management system audits; they are patterns, not a list from the standard.
- An Annex A control is missing from the SoA altogether.
- Exclusions say “not applicable” with no reason.
- An excluded control is still referenced by a risk in the register.
- A control is marked implemented, but no evidence exists or the evidence predates the system.
- The SoA was written before the risk assessment and never updated.
- Organization-defined controls appear in practice but not in the SoA.
- The SoA has no version, approver or date, so it is not controlled documented information.
Each of these is a break in the chain from risk to control to evidence. When one is raised, the fix runs through corrective action: correct the row, find why the process let it through, and check the rest of the SoA for the same gap.
SoA template, PDF, example and the “2022” confusion
The column specification above is a working template: copy the headings into a spreadsheet and add one row per Annex A control from your licensed copy. The same layout sits well beside your risk register and impact assessment templates. The format is up to you. The SoA is documented information, which ISO/IEC 42001 says can be in any format and media (definition 3.10, official preview), so a PDF export of a controlled spreadsheet is fine.
Searches for an “ISO 42001 2022” SoA mix up two standards. ISO/IEC 42001 has one edition, published 18 December 2023. The 2022 date belongs to ISO/IEC 27001:2022, the information security standard published 25 October 2022, which has its own Annex A and its own SoA. If you hold both certifications, keep two SoAs or one table with a column for each standard; the controls differ. For a plain overview of the AI standard, including how it differs from ISO 27001, start with ISO 42001 at a glance.
Who approves the SoA and when to update it
Management approves the SoA together with the risk treatment plan, and the approval is dated and versioned. ISO/IEC 42001 asks for approval of the treatment plan and acceptance of residual risk in clause 6.1.3; name the approver in your procedure so nobody argues about it at audit.
Update the SoA when risk treatment changes. In practice, that means when a new AI system enters scope, a risk is added or rescored, a control is added or retired, an exclusion’s condition changes, or an audit finding is closed. Review it at least at each management review, even if nothing has changed, and record that the review happened.
Writing an SoA is a skill best learned on a realistic case. If you are comparing courses, a provider scorecard sets out what a full ISO 42001 Lead Implementer syllabus covers, including whether each course has you build practical artifacts such as an SoA. ISO/IEC 42001 Lead Implementer training with implementation templates and checklists works through an SoA alongside the AI register, impact assessment and risk register in its case study workbook.
Frequently Asked Questions
What is a Statement of Applicability in ISO 42001?
A Statement of Applicability is the ISO/IEC 42001:2023 record listing every control your AI management system needs, with a justification for including or excluding each one (definition 3.26). Clause 6.1.3 requires the AI risk treatment process to produce it. It covers every Annex A control plus any controls the organization adds.
Does an ISO 42001 SoA have to list every Annex A control?
Yes. Annex A of ISO/IEC 42001:2023 is normative, and clause 6.1.3 asks you to compare your controls with Annex A and justify inclusion or exclusion. So every Annex A control needs a row with a decision. Published summaries commonly count 38 Annex A controls, but build your list from your licensed copy of the standard.
Can you exclude Annex A controls in ISO 42001?
Yes, with a justification. Definition 3.26 of ISO/IEC 42001:2023 notes that organizations may not require all Annex A controls. A defensible exclusion rests on a checkable fact, such as no AI suppliers in scope, names the condition that would reverse it, and is not referenced by any risk in the risk register.
Is there an ISO 42001 statement of applicability template?
ISO/IEC 42001:2023 does not include an SoA template; it defines what the SoA must contain. A usable template has columns for control reference, title, decision, justification, linked risks, linked impact assessments, implementation status, evidence location, owner, and version with approver and date. Any format works, including a controlled spreadsheet exported to PDF.
Is the ISO 42001 SoA the same as the ISO 27001 SoA?
No. Both are Statements of Applicability, but they cover different Annex A control sets. ISO/IEC 27001:2022, published October 2022, covers information security controls; ISO/IEC 42001:2023, published December 2023, covers AI controls. Organizations certified to both keep two SoAs or one table with separate columns for each standard.
How often should the Statement of Applicability be updated?
Update the ISO 42001 Statement of Applicability whenever risk treatment changes: a new AI system in scope, a new or rescored risk, a control added or retired, or a changed exclusion condition. ISO/IEC 42001:2023 sets no fixed frequency, so many organizations also review it at each management review and record the result.
