Statement of Applicability for ISO 42001: how to draw it up

Anyone familiar with ISO 27001 knows the Statement of Applicability (SoA): the document in which you record, for each Annex A control, whether it applies and why. ISO/IEC 42001 uses exactly the same mechanism, but for AI. Clause 6.1.3 requires you to produce a SoA for the 38 controls in Annex A of the standard as part of risk treatment. In the certification projects we support, the SoA is one of the first documents the external auditor asks for. Reason enough to set it up properly. This article covers where the SoA comes from, what belongs in it, how to justify exclusions and where things go wrong.

Where the SoA sits in the standard

The SoA is not a standalone document but the outcome of the risk treatment process in clause 6.1.3. That process consists of a number of steps. For each identified AI risk you select a treatment option: mitigate, avoid, transfer or accept. You then determine which controls are needed to carry out the chosen options. You compare those self-determined controls with Annex A to verify that nothing has been overlooked. The Statement of Applicability follows from that comparison. Finally, you work everything out in a risk treatment plan with actions, responsible parties and deadlines.

That order matters. A SoA that cannot be traced back to a risk assessment falls apart during a certification audit. The auditor wants to see why a control was declared applicable, and that answer should lie in your risks, not in "the standard says so".

What the SoA contains

The core is a table with all 38 controls from Annex A, from A.2.2 (AI policy) through A.10.4 (customer relationships). For each control you record whether it applies, with a justification for both inclusion and exclusion. We also recommend a column with the implementation status and a reference to the document or process in which the control is implemented. The standard does not require those extra columns, but they make the SoA usable as a management tool and save time during the audit.

Annex A is organized into nine domains: policies related to AI (A.2), internal organization (A.3), resources for AI systems (A.4), assessing impacts of AI systems (A.5), the AI system life cycle (A.6), data for AI systems (A.7), information for interested parties (A.8), use of AI systems (A.9) and third-party and customer relationships (A.10). That structure helps when assigning ownership: the data domain belongs somewhere different from the domain on information for interested parties.

Watch out for copyright when describing the controls. You may not copy the text of the standard into your own documents. Describe each control in your own words and refer to its number.

Justifying exclusions

Not every control is relevant to every organization, and the standard allows for that. The role you play determines a lot. An organization that only uses third-party AI systems and develops nothing itself will implement or exclude several controls from the life cycle domain differently than a party that trains its own models. The reverse also holds: an organization that only develops and does not deploy to end users looks differently at the controls around use.

The justification does need to be sound and documented. "Not relevant" is not a justification. A good exclusion describes the factual situation (we do not develop our own models, all AI functionality is procured as part of SaaS services) and draws the conclusion for the control from it. Be cautious with exclusions: in practice, controls that seem inapplicable at first glance often turn out to apply on closer inspection. Procured AI, for example, remains your responsibility towards users and affected individuals.

The link with the risk treatment plan

The SoA states which controls apply, the risk treatment plan states how and when they are implemented. Those two documents should match. The treatment plan contains, per control, the implementation actions, the responsible party, the deadline and the expected residual risk. Residual risks that remain after treatment must be formally accepted by an authorized risk owner. That sounds like a formality, but missing residual risk acceptance records are a nonconformity we encounter regularly.

Difference with the ISO 27001 SoA

The mechanism is identical, the content is not. Annex A of ISO 27001:2022 contains 93 controls focused on information security; Annex A of ISO 42001 contains 38, focused on responsible development and use of AI. There is overlap in themes such as policy, roles and supplier relationships, but the AI controls require different expertise: impact assessments on individuals and society, data quality for training, transparency towards users.

Organizations with both certifications sometimes opt for a single combined SoA document. That is possible, as long as it remains clear per standard which controls fall under which Annex and the justifications remain separately traceable. Two separate documents with cross-references often work better in practice.

Common nonconformities

In internal audits and certification projects we keep seeing the same patterns around the SoA. There is no SoA, or it is incomplete: not all 38 controls are addressed with a justification for inclusion or exclusion. Treatment decisions are not documented, making it impossible to trace why a control was selected or a risk accepted. Residual risks are not formally evaluated or accepted by an authorized owner. The treatment plan lacks deadlines, responsible parties or progress tracking. And the implemented controls do not match the risks from the risk assessment, leaving assessment and treatment disconnected.

Each of these points can be avoided by treating the SoA not as a form-filling exercise but as the outcome of your risk process.

Which documents the auditor expects

Expect an external auditor to ask, around clause 6.1.3, for: the risk treatment procedure, the Statement of Applicability itself, the risk treatment plan, the records of accepted residual risks and evidence of implementation and effectiveness of the controls. The SoA should also carry a version number and an approval date, and is reviewed at least annually and updated in between after major changes. A new AI system in scope or a changed role (you start developing models yourself, for example) is such a change.

Want to set up the SoA and the underlying risk process in a structured way? The Secure Audit platform includes an internal audit module with concrete criteria, interview questions and examples of good practice and common nonconformities for every ISO 42001 control. Contact us for a no-obligation conversation.