ISO 42001 Statement of Applicability: How to Justify Every Control

The ISO/IEC 42001 Statement of Applicability (SoA) is the record, required by clause 6.1.3, of every control an AI management system needs and why each is included or excluded. Clause 6.1.3 covers AI risk treatment. The SoA lists the Annex A controls plus any controls you add. It gives a reason for every decision and ties each reason to a record, such as the risk assessment or an external requirement. Certification auditors review it at Stage 1 and test it at Stage 2.

The term also appears in ISO/IEC 27001. The 42001 version works against a different control set and allows exclusions for specific AI systems. Its required contents also leave out implementation status, which the 27001 version asks for.

Where clause 6.1.3 puts the SoA

Clause 6.1.3 of ISO/IEC 42001:2023 makes the SoA one output of AI risk treatment, produced only after the treatment decisions exist. The organization first chooses how to treat each assessed AI risk, and then works out which controls those treatment choices need. Next it compares that list with Annex A, so nothing necessary is missed. Only then does it produce the SoA and the AI risk treatment plan. Designated management approves the plan and accepts the residual AI risks.

The order above comes from two independent secondary copies of the clause text, so check item letters and wording against your licensed copy before quoting them. The wider process, from risk criteria to treatment, sits in the guide to risk treatment under clause 6.

What the definition adds

ISO/IEC 42001 term 3.26 defines the SoA as “documentation of all necessary controls” with a “justification for inclusion or exclusion of controls.” Two notes follow the definition. The first allows that some Annex A controls will not be needed, and that an organization can add its own. The second says every identified risk, and the controls set up to address it, must be reflected in the SoA.

That second note is easy to miss. It turns the SoA from a control list into a map back to the risk register. An SoA that cannot be traced to risk IDs therefore fails the definition itself, before good practice even comes into it.

One editorial slip sits in the published definition. It is minor. Its cross-reference for “controls” points to term 3.23, which defines information security. Read “controls” in the ordinary management system sense.

Annex A and Annex B are both normative

Annex A of ISO/IEC 42001 holds the reference control objectives and controls, and ISO’s published contents page labels it normative. So is Annex B, the implementation guidance for those controls. Annexes C and D are labelled informative. Some ranking explainers say otherwise. Two call Annex B informative, and a documentation site that Google’s AI Overview cites for this topic calls Annex A informative. Treat Annex B as guidance an auditor can expect you to know.

Per Annex A of ISO/IEC 42001:2023, there are 38 controls across nine areas (A.2 to A.10) and ten control objectives, since A.6 carries two. Verify control wording against your licensed copy. A separate guide covers each Annex A control and its evidence. That leaves the question of what each SoA row must hold.

What the SoA must contain

The ISO/IEC 42001 SoA must contain the necessary controls and a justification for including or excluding each one. Everything else in a typical SoA spreadsheet is good practice that auditors expect but the clause does not list. Keep the two apart. A template that presents status as a requirement teaches teams to run the SoA as a project tracker.

The field specification below is GAICC editorial analysis of the clause 6.1.3 wording.

Fields the standard names

Two fields come straight from clause 6.1.3: the necessary controls and the justification for each inclusion and exclusion. The necessary controls are the ones found through risk treatment, the Annex A comparison and any additions. The same clause asks that necessary controls be aligned with the AI objectives, kept as documented information, communicated internally and made available to interested parties as appropriate. One approved SoA, issued with the treatment plan, meets most of that in a single artifact.

Fields that make the SoA auditable

Status, owner and evidence pointer are absent from the 42001 wording, yet each one makes the SoA easier to audit. Without an evidence pointer, the auditor must request every record by hand. Without an owner, nobody answers for the control at interview. Both gaps slow the audit down. Status does a different job. It shows which included controls are still open actions in the treatment plan and which already operate.

How much detail an inclusion needs

An inclusion justification needs enough detail for an outsider to trace the control to its cause. Practitioners on ISO 27001 forums ask the same question, and the answer carries across. Name one of four sources and cite the record:

• Risk treatment, citing the AI risk IDs the control treats from the risk register.
• A legal or regulatory duty, citing the statute or regulation as logged in your register of external requirements.
• A contract, citing the customer or supplier clause that commits you to the control.
• A policy decision, citing the AI policy clause or management decision that adopted it.

One sentence and one reference usually suffice. Long essays slow the audit and bury the trace.

Grounds for excluding a control

ISO/IEC 42001 names two grounds for excluding a control in the SoA. The first is the risk assessment: it found the control unnecessary for the AI risks in scope. The second is external requirements: applicable law or other external requirements do not require the control, or grant an exception to it. The clause says a justification can include these grounds, so the list is not closed. Company size, cost or the effort of producing evidence are still weak grounds on their own, because none of them says anything about risk.

The risk ground has a twist under 42001. The clause 6.1.2 risk assessment already weighs consequences to the organization, to individuals and to societies. Results of the separate clause 6.1.4 impact assessment feed into that risk assessment, so an exclusion that ignores them will not hold. The guide to the clause 6.1.4 impact assessment shows how the two connect.

Why “not applicable” fails

“Not applicable” on its own fails because it states a verdict without the record that produced it. An auditor cannot tell whether the team assessed the risk or skipped the row. The definition note also requires every identified risk to appear in the SoA. An exclusion that contradicts an open risk register entry is therefore a direct inconsistency between two controlled records.

The illustrative rows below show the difference in practice.

Excluding a control is not accepting a risk

Excluding a control and accepting a risk are different decisions with different approvers. An exclusion says the control is not needed. Risk acceptance says a needed control leaves some risk behind. Clause 6.1.3 asks designated management to approve the treatment plan and accept residual AI risks. Record each decision in its own place, and link them by risk ID.

Controls you add beyond Annex A

A note to clause 6.1.3 says the Annex A controls are not exhaustive. The same clause asks whether controls beyond Annex A are necessary, and those additions belong in the SoA with the same fields. Limits on what an AI agent may do through connected tools are one example, since no Annex A short title names them. The CSA AI Controls Matrix v1.1, released in June 2026 with 247 control objectives and an ISO 42001 mapping, is one source of candidates.

Applicability per AI system

ISO/IEC 42001 lets an organization justify excluding controls in general or for specific AI systems. One SoA can therefore record different decisions for different systems. A note to clause 6.1.1 allows for more than one AI system inside the AIMS scope, so per-system decisions are routine.

Two layouts work. The table below compares them; neither comes from the standard.

System IDs should come from the AI system inventory, and the two records must move together. When a system joins the inventory, every SoA row that says “All” now makes a claim about it. Check each of those rows. Run that check before each internal audit, so your own review finds the gap first.

An illustrative SoA extract

The extract below is illustrative only and describes a fictional company. It is built from the structure of clause 6.1.3 and the Annex A short titles. It is not a complete SoA and does not reflect any real organization.

Example Co, a US business software company, scopes three AI systems into its AIMS:

• AI-01 is a customer support assistant built on a third-party large language model, with retrieval over help center articles.
• AI-02 is an in-house churn prediction model trained on product usage data.
• AI-03 is a vendor-hosted invoice data extraction tool that the finance team uses unmodified.

The patterns in the extract matter more than its wording. Exclusions are made per system and each cites a record, while every inclusion points to a risk ID, a contract term or a policy decision. In the last row, an organization-defined control sits beside the Annex A controls, with the treatment plan as its evidence until it operates.

[TRAINER INSIGHT NEEDED: Which SoA rows do learners in GAICC Lead Implementer classes most often justify badly, and what correction do instructors give?]

How auditors test the SoA

Certification auditors can use the SoA as a map of the AIMS at both audit stages. Under ISO/IEC 17021-1, the rules for management system certification bodies, Stage 1 examines the documented system and the client’s readiness for Stage 2. It also gathers scope information, including applicable legal requirements. Stage 2 evaluates whether the system is implemented and effective. In its final draft, ISO/IEC 42006, the AI supplement to those rules, requires the audit team to know all Annex A controls and their implementation, collectively.

The tests below are GAICC editorial analysis of common audit practice. Neither standard prescribes them as a list.

Stage 1 ends with documented conclusions that name any areas of concern, and a concern left open can be raised as a nonconformity at Stage 2. The full sequence, from document review to certification decision, is in the guide to what happens at Stage 1 and the stages after it.

Keeping the SoA current

The SoA is documented information, so clause 7.5 governs it like any other controlled record. It needs a clear identity, review and approval before issue, version control and controlled access. ISO/IEC 42001 sets no fixed review frequency for it. Instead, events drive the update.

Reopen the SoA when any of these happens:

• A new AI system enters the scope or the inventory.
• An existing system changes in a significant way, such as a new model, data source or intended use. Clause 8.4 reruns the impact assessment at planned intervals or when significant changes are proposed, and new results can overturn a justification.
• The AI risk assessment is repeated in operation under clause 8.2 and a cited risk changes rating.
• A law, regulation or contract term changes the external requirements you cite.
• A supplier of an AI system or component changes.
• An internal audit (9.2) or a nonconformity (10.2) exposes a wrong decision.
• Management review (9.3) decides to change the AIMS, or a planned change under 6.3 goes ahead.

A short change log keeps the history auditable. The rows below continue the Example Co illustration.

Approve the SoA together with the treatment plan, by the same designated management. Two documents signed on different dates can drift apart, and an auditor who compares the two can spot the mismatch.

ISO 27001 SoA vs ISO 42001 SoA

The ISO/IEC 42001 SoA follows the same idea as the ISO/IEC 27001:2022 SoA but differs in six details. Teams that copy a 27001 workbook without adjusting it carry the wrong assumptions across.

Some organizations that hold both certificates keep one workbook with a tab per standard. Each tab keeps its own rows and fields, while approval and version history sit in one place. Add the status column to the 42001 tab anyway. Both tabs then read the same way. Where one control serves both standards, such as supplier management, cross-reference it rather than copy it. For the wider design of an integrated system, see the guide to running both standards together.

What a usable SoA template includes

A usable ISO/IEC 42001 SoA template starts from the clause 6.1.3 fields. Relabeling a 27001 sheet carries the wrong columns across. Search suggestions for this topic are dominated by template, example and PDF variants. Two template pages that rank for the topic present implementation status as a required column. Check any template for two more problems: pre-filled “N/A” justifications, and Annex A control text copied in full, which is ISO’s copyright.

Any template worth adopting has six parts:

• A control register with every Annex A ID and short title, plus blank rows for organization-defined controls.
• The nine fields from the specification table above, with the two required fields marked.
• A per-system view keyed to inventory IDs.
• Picklists for the inclusion source (risk, legal, contract, policy) and the exclusion ground (risk assessment, external requirement), each forcing a reference.
• Cross-reference columns for risk register IDs and treatment plan actions.
• A change log and an approval block.

[GAICC TEMPLATE LINK: insert the link to GAICC’s SoA template here once the asset is live. Do not publish a placeholder link. See blocking item B3.]

Routing by situation

• With ISO/IEC 27001 already certified, add a 42001 tab to the existing SoA workbook and change the fields as the comparison table shows.
• Organizations that only use AI systems built by others should expect more A.6 life cycle exclusions, recorded system by system. They should also give more weight to the controls for AI suppliers and vendors.
• Teams that build or train their own models will find most of their evidence in the A.6 and A.7 rows.
• While the document set is still taking shape, begin with the list of ISO 42001 mandatory documents and place the SoA after the risk assessment.
• Exam candidates can expect SoA reasoning under clause 6.1.3, part of Domain II of the Lead Implementer certification exam.
• Anyone who will draft and own the SoA can learn to build and defend an SoA in Lead Implementer training. Its modules cover clause 6 planning, risk and impact assessment under clauses 6.1.1 to 6.1.4, and the Stage 1 and Stage 2 audits.

Frequently asked questions

Is the Statement of Applicability mandatory for ISO 42001 certification?

Yes. Clause 6.1.3 requires an SoA listing the necessary controls, with a reason for including or excluding each one, so no AIMS conforms to ISO/IEC 42001 without it. The broader question of whether your organization needs certification at all belongs to the pillar guide on whether ISO 42001 is mandatory.

How many controls does an ISO 42001 SoA have to cover?

Every Annex A control needs a row, whether you include or exclude it, plus a row for each control your organization adds. Per Annex A of ISO/IEC 42001:2023, that comes to 38 controls across nine areas, A.2 to A.10. Check the control wording against your licensed copy before you finalize the register.

Can a whole Annex A area be excluded from the SoA?

A note to clause 6.1.3 allows justified exclusions of whole control objectives as well as single controls, in general or for specific AI systems. Each exclusion still needs its own ground in the risk assessment or in external requirements. Excluding area A.5 would be difficult to justify, because the clause 6.1.4 impact assessment it supports is a requirement in its own right.

Who approves the Statement of Applicability?

ISO/IEC 42001 names designated management as the approver of the AI risk treatment plan and of residual risk acceptance, and it names no separate approver for the SoA. Both records come out of the same clause 6.1.3 process. Having the same people approve the SoA and the plan at one sitting keeps the two documents consistent.

Can one SoA cover both ISO 27001 and ISO 42001?

One workbook can serve both, as long as each standard keeps its own rows and fields. Some organizations that run both systems use a tab per standard with a single approval block and version history. The 42001 tab must still justify every 42001 Annex A control, and the 27001 tab must still record whether each necessary control is implemented.

How often should the SoA be reviewed after certification?

ISO/IEC 42001 sets no fixed interval for reviewing the SoA. Review it at planned intervals that suit your rate of change, and whenever one of the triggers listed above occurs. Certification bodies working under ISO/IEC 17021-1 hold a surveillance audit every calendar year except the recertification year, so an SoA that nobody has reviewed surfaces quickly.

What happens if an auditor finds an SoA error after certification?

The auditor records a nonconformity, which clause 10.2 asks you to correct while you look for its causes and for similar errors elsewhere. For an SoA, the fix is often a new version with an approved change log entry. Check the matching risk register and treatment plan entries at the same time, and keep the records as evidence.