The ISO 42001 Statement of Applicability is the document that records, for every control in Annex A of ISO/IEC 42001:2023, whether that control applies to your AI management system, whether it is implemented, and why. Annex A carries 38 controls across nine control objectives numbered A.2 to A.10, and the SoA is where you commit to a decision on each one in writing.
It is the artefact an auditor opens first, for a reason that is not administrative. The SoA is the only document in the standard that forces a decision and a reason for every control. Everything else in the AI management system can be written in the abstract; the SoA has to say something specific about your systems 38 times in a row.
For anyone arriving from ISO 27001 the document looks familiar, and that is the trap. The mechanics transfer exactly — same columns, same selection logic, same relationship to risk treatment. The judgement does not transfer at all.
What the ISO 42001 Statement of Applicability Records
The ISO 42001 Statement of Applicability records three things per Annex A control: whether it is applicable, whether it is implemented, and the justification for whichever answer you gave. A fourth column — a pointer to the risk, impact assessment or obligation that put the control in scope — is not mandated, and it is what turns the document from a register into an argument.
Clause 6 requires you to determine the controls your AI risk treatment needs, then compare that set against Annex A to confirm nothing relevant was overlooked. The SoA records that comparison, and it runs the opposite way from how teams fill it in: controls come out of your assessments first, and Annex A is the completeness check rather than the starting list. Our guide to the 38 Annex A controls covers what each objective asks for; this one is about deciding which are yours.
Why the Justification Is the Auditable Part
The justification column is the auditable part of the SoA, because an applicability flag is an assertion while a justification is a position someone can test. "Not applicable" with an empty cell beside it is not a judgement. It is a gap, and it is the finding.
Compare two exclusions of the same control. The first says "N/A." The second says: we do not develop or fine-tune models; we deploy a third-party system under a contract that assigns training-data governance to the provider; our role here is that of a user rather than a provider; and the provider obligations are carried through the third-party controls under A.10. The second is a claim an auditor can attack, which is the point. They can read the contract, check the role determination under clause 4, and see whether A.10 carries the obligation. If it holds, the exclusion stands.
Inclusions need reasons too. A control marked applicable with no reason behind it is how you end up operating something nobody can connect to a risk.
Most ISO 42001 SoAs fail on the justification column, not the applicability column.
Drop your work email and we will review your Statement of Applicability against the 38 Annex A controls and tell you which exclusions an auditor will push on.
AIMS Scope Drives Everything in the SoA
The AIMS scope drives everything in the SoA, which is only ever as good as the scope statement behind it. Applicability is a question about systems, so if the set of systems is wrong, every row is wrong however carefully it is reasoned.
This is where ISO 27001 experience misleads. Information security scope is drawn around things that announce themselves: a product, an environment, a set of offices, a legal entity. You can walk the boundary. An AI boundary is drawn around capability rather than infrastructure, and capability moves.
Why AI Scope Is Harder to Draw Than Security Scope
AI scope is harder to draw than security scope for four reasons, each producing in-scope systems that nobody put in scope.
- Shadow AI. Teams adopt models the way they once adopted SaaS: on a card, in an afternoon, without a review. An unapproved assistant summarising customer tickets is an AI system processing customer data whether or not procurement knows.
- Features that became AI without a decision. A ranking heuristic is replaced with a model; rules-based triage becomes a classifier. Nobody filed an approval because from the product side nothing changed, and the feature crossed into scope silently.
- Embedded AI inside purchased software. Your CRM, support desk and code editor all shipped model-backed features in their last release. You procured a tool that became an AI system, and the responsibility split with that vendor is an A.10 question.
- A boundary that moves quarterly. A mature product's security perimeter changes slowly. An AI estate changes with every release, so a scope statement written in January describes a different organisation by April.
Scope work is therefore not a prerequisite you finish. A control excluded because "we do not build models" needs revisiting the moment a team starts fine-tuning, and nobody will tell compliance. Our ISO 42001 implementation checklist puts inventory ahead of control selection.
Developer or Deployer: The Main Driver of Applicability
Whether you are a developer or a deployer of AI is the main driver of applicability, and the single determination that changes the most rows in the SoA. An organisation that trains and ships its own models and one that embeds a vendor's system will exclude very different controls, and both SoAs can be correct.
The standard's own vocabulary is providers, producers and users, and the determination belongs in your clause 4 context work rather than in the SoA, which inherits it. This goes wrong when an organisation is both — building one model, deploying three vendor systems — and writes a single role into the document. Applicability is per system.
What a Model Developer Usually Includes
A model developer carries the full weight of the life-cycle and data objectives. The controls under A.6 covering responsible design, development, verification and validation apply in full, because you make those design decisions. The data governance controls under A.7 apply hardest: provenance for development and enhancement data, quality expectations and how data was prepared are facts only you hold, and none can be pushed to a supplier. Impact assessment under A.5 is broader too, because a developer's range of downstream uses is wider than the single use a deployer has in mind.
What a Deployer Usually Excludes
A deployer that neither trains nor fine-tunes has legitimate exclusions, clustered in one place: controls governing the development of a model. Design objectives for a system you did not design, provenance for training data you never touched, validation of a model you cannot inspect — each can sit outside a deployer's control set if the justification names the contract and the role.
What a deployer cannot exclude is the governance of its own use. The third-party and customer relationship controls under A.10 become the centre of the SoA, because the obligations you excluded did not disappear; you asserted someone else holds them, and A.10 is where you evidence that. Responsible-use controls under A.9 stay in scope, since intended use and operational monitoring are yours whoever built the model, as do the transparency duties under A.8. A.5 applies to the deployment too, because the impact lands on your users whoever trained the weights, and the AI system impact assessment is the artefact most deployers wrongly assume their vendor has done.
Selecting Annex A Controls From Assessments, Not Templates
Selecting Annex A controls is a tracing exercise, not a template exercise: every control you mark applicable should trace back to something — a risk in the register, a finding in an AI system impact assessment, a contractual commitment, a legal obligation. A control that traces to nothing means either an unrecorded risk or a control you do not need. The standard is published by ISO and will never tell you which controls are yours; only your assessments can.
The risk assessment and the impact assessment do different jobs here and both feed the SoA. The risk assessment asks what could go wrong for the organisation. The impact assessment asks what the system could do to individuals, to groups and to society — a genuinely different question, and the one with the least precedent in an existing ISMS. Controls under A.5 and A.8 are usually selected on the strength of the impact assessment, so an SoA whose every row points back to the risk register alone tends to reveal the impact assessment was never really used.
Apply one test to each row: asked why a control is applicable, the answer should name a risk or impact finding, not the fact that it appears in Annex A.
How an Auditor Spots an Inconvenient Exclusion
An auditor distinguishes a reasoned exclusion from an inconvenient one by testing it against evidence outside the SoA, and excluding a control because it is hard is the failure mode they hunt for. Difficulty is not a justification. "We cannot evidence data provenance for our older training sets" describes a nonconformity to fix, not a control to exclude. Three checks catch it.
- The exclusion contradicts another document. The SoA says no model development; the engineering roadmap, the job adverts or the architecture diagram say otherwise. Inconsistency across artefacts is the cheapest finding an auditor can raise.
- The obligation has gone missing. You excluded a control because a supplier holds it, but the contract is silent and no A.10 allocation exists. Nobody holds it.
- The justification is generic. A reason that would read identically at any other company came from a template. Reasons naming your systems, contracts and role survive questioning; paraphrases of the control title do not.
Justifying excluded controls for AI systems well has one tell: the reason is narrower than you would like. It names the system, states the role, cites the term in the agreement, and says where the residual obligation is carried. Specificity feels like it invites scrutiny; it survives it. The ISO 42001 internal audit is where you want exclusions tested first, by someone with no stake in the answer.
Keeping the SoA Current in a Moving AI Estate
The SoA goes stale faster than anything else in an AI management system, and a stale SoA is worse than a thin one: a thin document is incomplete, a stale one asserts something untrue. An exclusion that was accurate when written and is now false is a misstatement to an auditor, read as a failure of the management system rather than a clerical slip.
The decay mechanism is always the same: scope changes and the SoA does not. A team starts fine-tuning. A vendor ships a model-backed feature into a tool you own. A pilot becomes production. Each can flip a row from not applicable to applicable, and none generates a ticket for compliance.
The fix is a trigger, not a cadence. An annual review is the floor and, at the pace AI features ship, not enough alone. Tie SoA review to the events that change applicability: a new or materially changed AI system, a change of role for an existing one, a new AI-touching supplier, a completed or refreshed impact assessment. Record the date and reason for each change — an SoA with a visible revision history reads as a document in use, one with a single creation date as a document produced for an audit. Surveillance audits look closely at that gap, as our ISO 42001 certification guide covers.
Statement of Applicability Questions Teams Ask
The questions teams ask about the Statement of Applicability cluster around how much justification is enough and how far the ISO 27001 version carries over.
Yes. Clause 6 requires you to determine the controls needed for AI risk treatment, compare that set against Annex A, and document which apply and the justification either way. That documented information is the Statement of Applicability, and a certification body asks for it early.
The format carries over cleanly: same columns, same selection logic driven by risk treatment. The content and reasoning do not. ISO 42001 holds 38 controls across nine objectives against ISO 27001's 93 in four themes, and the AI-specific objectives have no security equivalent to copy from.
Enough that someone outside your organisation could test it and reach the same conclusion. A workable justification names the systems it covers, states your role, and points to the evidence — a contract term, a risk, an impact finding. "Handled by vendor" is not a justification.
Yes. The SoA tracks applicability and implementation as separate facts, so a control can be in scope with implementation in progress, provided a treatment plan with an owner and a date sits alongside it. An applicable control with no implementation and no plan is a nonconformity.
At least annually, and whenever something changes applicability: a new or materially changed AI system, a change in the role you occupy for one, a new AI-touching supplier, or a completed impact assessment. The event triggers matter more than the annual review.
Keep the Statement of Applicability true as the AI estate changes
Book a demo and we will show how Konfirmity ties each Annex A control to the risk, impact assessment and system that justifies it, and flags the rows a new AI feature just invalidated.
Book a demo
Write the Reasons Before the Rows
The way to build a Statement of Applicability that holds is to write the reasons before the rows. Settle the scope, determine your role per system, run the risk and impact assessments, and let the control selection fall out of them. Every row then arrives with an argument already behind it.
Built the other way — download a 38-row template, mark the awkward ones not applicable, fill justifications in last — you get a file that looks complete and collapses under the second question. Three rows is usually all an auditor needs to find that out.
Start with the inventory and the role determination, because applicability is a question about systems before it is a question about controls. Then take the objectives one at a time against the systems you found: our guide to the ISO 42001 requirements covers the clauses that oblige the SoA to exist.
