ISO 42001 Statement of Applicability: Annex A controls explained

What the Statement of Applicability is for

The Statement of Applicability, usually shortened to SoA, records which Annex A controls apply to the AI management system, why, whether they are implemented, and where the evidence lives. It is the document an auditor reads first and returns to constantly.

It also has an internal purpose that organisations underuse: it forces a conversation about which controls actually reduce the risks identified in clause 6, rather than adopting the full annex because it exists.

A good SoA is a table with a short justification per control. A bad SoA is a copy of the annex with "yes" in every row.

How Annex A is organised

ISO/IEC 42001 Annex A groups its controls into themes covering policies for AI, internal organisation and reporting, resources for AI systems, assessing impacts, the AI system lifecycle, data for AI systems, information for interested parties, use of AI systems, and third-party and customer relationships.

Annex B provides implementation guidance for each control, and Annex C lists potential organisational objectives and risk sources. Read Annex B before you decide whether a control is applicable — several controls are broader than their titles suggest.

Unlike ISO 27001, several Annex A controls are documentation-and-decision controls rather than technical safeguards. They ask whether the organisation determined something and recorded it, which makes them cheap to satisfy properly and obvious when faked.

Policies, organisation and resources

The first themes cover the AI policy, alignment with other organisational policies, review of the policy, AI roles and responsibilities, reporting of concerns, and the resources needed for AI systems — data, tooling, compute, human capability and system components.

The resources controls are commonly skipped and commonly audited. The requirement is to identify and document the resources each AI system depends on. In practice this is a per-system record of the model and version, the compute and hosting arrangement, the data sources, the tooling, and the people whose skills the system relies on.

The reporting-of-concerns control needs a named route. Staff must be able to raise an AI concern without going through the person who owns the system.

Impact assessment and lifecycle controls

The impact assessment theme requires a documented process, assessment of impacts on individuals and societies, and the recording and retention of those assessments. Point these controls at the ISO 42005-aligned process described in your clause 6 work rather than duplicating it.

The lifecycle theme is the substantive engineering block: objectives for responsible development, processes for the design and development of AI systems, requirements specification, documentation of design and development, verification and validation, deployment, operation and monitoring, and technical documentation and event logs.

For organisations that buy rather than build, these controls still apply but shift emphasis. Verification becomes acceptance testing of a configured system. Design documentation becomes a record of prompts, retrieval configuration, grounding data and guardrails. Event logging becomes a requirement you place on the supplier and verify.

Data controls: provenance, quality and preparation

The data theme covers the organisation's approach to data for AI systems, data for development and enhancement, acquisition, quality, provenance and preparation. These are the controls most likely to expose real gaps, because they demand knowledge many organisations do not have about data they already hold.

Satisfying them requires a documented position on which data classes may be used for which purposes, recorded provenance for datasets used in development or grounding, defined quality expectations, and a record of preparation steps such as cleaning, labelling and de-identification.

Where a third-party model is used without fine-tuning, the applicable subset narrows, but grounding and retrieval data remain squarely in scope. Do not exclude the data theme on the basis that "we do not train models".

Transparency, use and third parties

The information-for-interested-parties theme covers system documentation for users, external reporting, communication of incidents, and information provided to affected parties. This is where transparency obligations become concrete: telling people they are interacting with an AI system, explaining its purpose and limitations, and providing a route to human contact.

The use theme covers processes for responsible use and objectives for it — effectively the acceptable-use position translated into an operating control with monitoring behind it.

The third-party theme covers allocation of responsibilities across the AI value chain, suppliers, and customers. Record, per system, which obligations sit with the model provider, which with the platform, which with you, and which with your customer. Ambiguity here is the most common cause of an unmanaged risk.

Justifying inclusions and exclusions

For each control, record one of three states: applicable and implemented, applicable and planned with an owner and date, or not applicable with justification. The justification must reference scope or risk. "We do not develop models, so controls specific to model development are not applicable to systems in scope" is defensible. "Not resourced this year" is a nonconformity written in advance.

Keep justifications short and specific to your organisation. Auditors quickly recognise annex text paraphrased back at them.

Link each applicable control to the risk it treats and to the evidence artefact. Three columns — control, treated risk, evidence location — turn the SoA from a claim into a navigable index.

Reusing your ISO 27001 control set

Organisations already certified to ISO 27001 can satisfy a meaningful share of Annex A by extending existing controls rather than building new ones. Access control, logging, supplier management, change management, incident response, classification and awareness all carry across with an AI-specific extension.

The efficient approach is one integrated management system with a combined risk register, a single supplier process that adds AI-specific due-diligence questions, and one incident process with AI failure modes added to the taxonomy.

Be explicit in the SoA about where a control is inherited. "Implemented via ISMS control A.5.19 supplier management, extended with the AI due-diligence questionnaire" tells the auditor exactly where to look and demonstrates system maturity rather than duplication.

Keeping the SoA alive

The SoA should change when the scope changes, when a new AI system enters production, when a supplier relationship shifts responsibility, or when a risk treatment completes. Version it and record the reason for each change.

Review it before every internal audit and every management review. A SoA that has not changed in a year, in an organisation whose AI usage has changed substantially, is itself a finding.