ISO 42001 Statement of Applicability Template

Statement of Applicability header

The header is what tells a reader which management system this SoA belongs to. If the risk assessment or the risk treatment plan is not identifiable from here, the justifications below have nothing to hang from.

A.2 Policies related to AI

This objective is the AI policy itself: whether the organization has one, whether it agrees with the policies it already runs (security, privacy, people, and the rest), and whether anyone reviews it. Typical evidence is the policy, a short cross-reference to the policies it has to live with, and the minutes or the ticket of the last review. Use the licensed standard for the exact control text.

A.3 Internal organization

This objective is who is allowed to do what, and how a person raises a concern that the system is being misused or is causing harm. Typical evidence is role descriptions or a RACI that names individuals, and a reporting path with at least one record that a concern was received and dealt with. A mailbox nobody reads is not the control.

A.4 Resources for AI systems

This objective is whether you can say what an AI system actually depends on: the data, the tools, the compute, and the people. Typical evidence is a resource inventory for the systems in scope, data-catalog entries, a toolchain list, a note of the system and computing resources, and competence records for the people who develop or use them. An architecture diagram with no owner is a start, not the control.

A.5 Assessing impacts of AI systems

This objective is the impact assessment: a process you can repeat, a record that you did it, and coverage of individuals or groups and of wider societal impacts, not only the benefit to the organization. Typical evidence is the procedure, completed assessments for the systems in scope, and the decision that followed an assessment. An assessment that cannot change a release decision has not been implemented.

A.6 AI system life cycle

This objective runs from why you are developing the system responsibly through to logs of what it does in operation. It covers objectives and processes for responsible development, then requirements, design records, verification and validation, deployment, operation and monitoring, technical documentation, and event logs. Typical evidence is the development procedure, specifications, test records, a release record, an operating procedure, the technical documentation, and a log configuration someone has checked. Annex B of the standard is where the implementation guidance for these controls lives; this table is only the inventory.

A.7 Data for AI systems

This objective is the data the system is developed and improved with: where it comes from, how it was acquired, whether its quality is known, whether its provenance is kept, and how it was prepared. Typical evidence is data documentation, acquisition records, quality checks, lineage, and the preparation steps. A dataset name with no source is not provenance.

A.8 Information for interested parties

This objective covers what people outside the development team are told, and how they can report back. Users need system documentation (A.8.2). A.8.3 is an inbound channel: interested parties can report adverse impacts of the AI system to the organization. Evidence for A.8.3 is the reporting channel itself, plus intake and handling records. That is distinct from A.8.4, which is outbound communication of incidents to users and other interested parties. A.8.5 is the remaining information those parties need. Do not treat the inbound channel and the outbound notice as the same control.

A.9 Use of AI systems

This objective is responsible use, as distinct from responsible development. The organization needs processes for how systems may be used, objectives for that use, and a statement of intended use so that misuse is visible. Typical evidence is the use procedure, the objectives, and an intended-use statement for each system in scope. Intended use is also what an impact assessment and a risk classification are written against; if it is vague here, it is vague everywhere.

A.10 Third-party and customer relationships

This objective is the split of responsibility with suppliers and with customers. Someone has to allocate who does what, the supplier relationship has to be managed, and the customer relationship has to say what the customer is taking on. Typical evidence is the allocation (a matrix or contract clauses), supplier assessments, and customer terms that match the allocation. "The vendor is responsible for the model" is not an allocation until the contract says which obligations stay with you.

Additional controls

Annex A is a reference list, not a ceiling. Clause 6.1.3 is about the controls the organization has determined are necessary. If the risk treatment plan requires a control from another source — an ISO/IEC 27001 Annex A control, or a category from the NIST AI Risk Management Framework — record it here with the same justification and evidence you would give an Annex A control.

Exclusions and document control

An exclusion is a decision. It has to point at the risk assessment, and the approver named in the header has to be able to stand behind it. The SoA is a controlled document: version, date, and a record of what changed. Auditors sample it against the risk assessment, the risk treatment plan and the evidence you named. A row with no evidence is a finding waiting for a sample.

Excluding a control needs a justification tied to the risk assessment, not a blank cell and not the phrase "not applicable" on its own. Keep this Statement of Applicability as a controlled document. It is what an auditor samples. It is not a certificate, and completing it does not mean an accredited certification body has audited the management system. Control titles in the tables are paraphrases; confirm each one against your licensed copy of ISO/IEC 42001:2023 before you issue the SoA.