ISO 42001 Statement of Applicability (SoA): How to Build One

What the SoA is

Clause 6.1.3 requires you to produce a Statement of Applicability that:

• Contains the necessary controls determined by 6.1.3(b) and (c)
• Provides justification for their inclusion
• States whether they are implemented or not
• Provides justification for any exclusion of Annex A controls

The SoA is the bridge between your risk assessment (6.1.2) and your operational controls. Auditors use it as the table of contents for the rest of the AIMS.

SoA structure

A defensible SoA has columns for each of the 38 Annex A controls:

1. Control ID (e.g., A.5.2)
2. Control title
3. Control objective
4. Applicability (Applicable / Not applicable)
5. Rationale (why applicable or not)
6. Implementation status (Implemented / Partial / Planned / Not implemented)
7. Evidence location (where to find the evidence)
8. Responsible owner
9. Last review date

AIMS-07 in the Starter tier is pre-populated with all 38 controls and the first three columns. You complete the rest based on your scope and risk decisions.

How to decide applicability

Controls that are almost always applicable

A.2.2 (AI Policy), A.3.2 (AI roles), A.4.2 (Resource documentation), A.5.2 (Impact assessment process), A.6.1.2 (Responsible development objectives), A.8.2 (User documentation), A.9.2 (Responsible use), A.10.2 (Responsibility allocation) are applicable for nearly every AIMS scope.

Controls that may be excluded, with justification

• A.7.2–A.7.6 (data controls), if you're a pure deployer using only vendor AI and handling no training data, you may exclude some. Justification: "Organisation does not develop AI systems or handle training data".
• A.6.2.2–A.6.2.8 (development lifecycle), deployers-only can exclude development-phase controls. Justification: "Organisation does not develop AI systems; lifecycle controls apply to vendor, governed via A.10".
• A.10 (supplier and customer controls), if you have no AI suppliers and no AI customers, these may be excluded. Rare in practice.

Be cautious about exclusions. Every exclusion is scrutinised. Justifications like "we don't think we need it" are rejected; justifications grounded in your actual scope (no development, no training data, etc.) are accepted.

What auditors test

• "Show me your SoA.", First document they open.
• "This control is marked Applicable, where's the implementation evidence?", They pick 3–5 controls and sample.
• "This control is Excluded, walk me through the justification.", They verify the exclusion is consistent with your scope.
• "This control is marked Partial, what's the plan and timeline?", Partial is fine if it has a plan; Partial without a plan is a finding.
• "When was this SoA last reviewed?", Should be within the last 12 months.

Common SoA mistakes

• Excluding a control because "we're not doing that yet", that's a Not Implemented with a plan, not an exclusion.
• Marking everything Applicable to be safe, this inflates audit scope and creates findings for controls you haven't actually implemented.
• Justifying exclusions with vague language ("this doesn't apply to us"), must reference specific scope or context.
• Not updating the SoA after scope changes.
• Evidence-location column empty, auditors can't find the evidence, they mark it a finding.

SoA lifecycle

The SoA is reviewed at planned intervals (at least annually) and after any material change: new AI system in scope, scope expansion/contraction, regulatory change, significant incident, management-review decision. Every update is logged in the document-control section.