ISO 42001 Statement of Applicability: Which Annex A Controls Apply?

The ISO 42001 Statement of Applicability (SoA) lists every control in Annex A of ISO/IEC 42001:2023, states whether each one applies to your AI management system, gives the reason, and records whether it is in place. Clause 6.1.3 requires it, the certification body reads it at Stage 1 before almost anything else, and the auditor keeps it open through the whole of Stage 2. For an organization that uses AI supplied by a vendor rather than building its own, in our experience roughly four fifths of the 38 Annex A controls apply, the exclusions cluster in the development and training-data areas, and every exclusion has to trace to a scope statement, a defined role, or an assessment that found nothing to treat. Here is how to make those calls and write them down so they hold.

What the Statement of Applicability is and where it comes from

Clause 6.1.3 (AI risk treatment) asks for five things in order: choose the controls needed to treat the risks found in the AI risk assessment (clause 6.1.2), compare that list against Annex A so nothing necessary is left out, produce a Statement of Applicability that records the necessary controls, the justification for each inclusion and exclusion, and whether each control is implemented, write a risk treatment plan, and get the risk owners to approve it. The standard says plainly that Annex A is a reference list and does not treat it as exhaustive. If you need a control that is not in Annex A, you add it, and it goes in the SoA too.

Two inputs feed the SoA that people coming from other standards sometimes miss. The first is the scope statement in clause 4.3, which rests on the context work in clause 4.1, where the standard asks you to determine your organization's role with respect to each AI system. The second is the AI system impact assessment in clause 6.1.4, which looks outward at the individuals, groups and society an AI system could affect. The risk assessment looks at what could go wrong for you; the impact assessment looks at what could go wrong for other people, and a justification that cites only the first will look thin to an auditor who has just read the second.

A working SoA has one row per control: reference, title, applicable (yes or no), justification with document references, implementation status, evidence reference, and owner, with a version, date and approver at the top. A spreadsheet under document control is fine. The documentation requirements article covers where the SoA sits among the other mandatory documents, and the clause-by-clause breakdown covers clause 6 in more depth.

Annex A in one table

Annex A groups its 38 controls into nine areas, A.2 through A.10. The last two columns are a starting expectation, not a verdict; your risk assessment and impact assessment can override either one.

The areas a vendor's customer can exclude are the ones written for the people who build and train the model. Everything about deciding to use AI, using it responsibly, telling people about it, and managing the vendor stays with you.

How the 42001 SoA differs from the 27001 SoA you already know

If you have built an ISO 27001 Statement of Applicability, you know the mechanics. The judgment is different in four ways.

The list is smaller and each control is wider. ISO 27001:2022 Annex A has 93 controls in four themes, and many can be satisfied by a configuration or a technical record. ISO 42001 Annex A has 38 controls in nine areas, and almost none is technical. Each describes a process, a decision, a record or a communication.

Exclusions are rare in 27001 and routine in 42001. Nearly every 27001 control applies to any organization with people, devices and data. ISO 42001 was written for both ends of the AI supply chain at once, so a company that only uses a vendor's model will legitimately exclude a cluster of controls written for developers. That makes the justification column the most important one in the document, because the auditor will test whether your role really is what you say it is.

Two assessments feed it, and Annex C gives you the vocabulary. The 42001 SoA rests on the AI risk assessment (6.1.2) and the AI system impact assessment (6.1.4), and the second is where the controls in A.5 and A.8 get their reason for existing. Annex C lists the AI objectives and sources of risk (fairness, safety, security, privacy, transparency and explainability, accountability, robustness, maintainability, environmental impact and others); use that language in your justifications so a reader can see which objective a control serves. Annex B plays the role ISO 27002 plays for 27001: implementation guidance, control by control.

"Covered by the ISMS" is not a justification. If you already hold 27001, the data controls in A.4 and A.7, the supplier control in A.10.3 and the event logging control in A.6.2.8 overlap with controls you already operate. Cross-reference the ISMS control and its evidence in the 42001 SoA row. A one-line note that the ISMS handles it, with no pointer, gets written up.

How to decide whether a control applies

Work every control through four questions, in this order. The later questions can pull a control back in after the earlier ones leaned toward exclusion.

1. Scope. Is the activity this control governs inside the AIMS scope defined under clause 4.3? If your scope covers the AI assistant in your quality system and nothing else, a control about a forecasting model in the ERP is outside scope, and you say so by reference to the scope statement.
2. Role. Does your organization perform this activity at all, in any role? The standard talks throughout about organizations that develop, provide or use AI systems, and those three verbs are the safest vocabulary for a scope statement. If you use a vendor's model and do not design, train or fine-tune it, the development and design-record controls are not yours. Be honest about the edges: writing prompts at scale, building retrieval over your own documents, or fine-tuning on your own records can move you back toward the developer side for the affected controls.
3. Risk and impact. Does the risk assessment or the impact assessment identify anything this control would treat? If yes, the control applies regardless of role. An organization that only uses AI can still have an impact assessment showing that individuals could be harmed by the outputs, and A.5 then applies in full.
4. Obligation. Does a law, regulation, contract or customer requirement call for this control? For a GMP manufacturer, 21 CFR 211.22(c) on the quality unit's review of procedures and specifications is the obvious one, and 21 CFR Part 11 governs the records and audit trails. State AI laws are moving (Texas's TRAIGA took effect on 1 January 2026, and Colorado's narrower SB 26-189 takes effect on 1 January 2027), so record what applied on the date you approved the SoA and revisit it.

If either of the last two questions says yes, the control is applicable. If all four say no, you have an exclusion, and the justification comes straight from whichever question ended the analysis.

How to write a justification that holds up

Every row follows the same shape: this control is applicable (or excluded) because of this scope boundary, role, risk, impact or obligation, and here is the document, risk ID or contract clause that shows it. Applicable rows add the implementing procedure, the owner, the status and the evidence.

A weak exclusion reads: "A.7.3 Acquisition of data. Not applicable. We do not do this." A strong one reads: "A.7.3 Acquisition of data. Excluded. The organization does not acquire data for the development or enhancement of AI models. The AIMS scope statement (AIMS-001, section 2) records the organization's role as a user of third-party AI systems, and the vendor agreement (clause 7.2) prohibits use of customer data for model training. Reviewed against risk register entries R-001 to R-014; no risk requires this control."

Three grounds for exclusion are accepted: the activity is outside your scope, your organization does not perform it in any role, or no identified risk, impact or obligation calls for the control. Three are refused: the control is expensive, the control is hard, or the organization is small. "The vendor handles it" sits in between. It can support an exclusion or a scaled application, but only when A.10.2 (allocating responsibilities) has been done, the allocation is in the contract, and you hold evidence that the vendor actually does the thing.

Worked example: a 200-person contract manufacturer using a vendor's AI assistant

Take a 200-person contract manufacturer of over-the-counter drug products, operating under 21 CFR Part 211, with an ISO 9001 certificate and an electronic quality management system. The eQMS vendor has added an AI assistant that drafts deviation investigations, CAPA summaries and SOP revisions from a prompt and from the company's own controlled document library. The vendor hosts the model. The company does not train or tune it, and the contract says customer data is never used to train the vendor's model (they asked, and got it in writing).

The scope statement reads, in part: "The AIMS covers the use of the eQMS AI assistant for drafting quality records and procedures at the company's manufacturing site. The organization uses AI systems supplied by third parties and does not design, develop, train or fine-tune AI models." That one sentence about role is what makes every exclusion below possible.

The impact assessment found one impact that drives most of the SoA: a specification, procedure or master record drafted by the assistant and released without qualified review could reach a batch, and then a patient. That is the failure FDA cited in April 2026 in its Purolea warning letter, which called out AI-written specifications, procedures and master records released without qualified review under 211.22(c). The GMP manufacturer's guide to ISO 42001 covers that letter in detail.

Here is how the SoA came out, with related controls grouped.

Six controls excluded, 32 applicable, and every exclusion rests on the same two facts: the role in the scope statement and the training clause in the vendor agreement. That is what an auditor wants to see, because the exclusions stand or fall together and can be checked in ten minutes.

The company also added one control that is not in Annex A: qualified review and approval of every AI-drafted record before it enters the quality system, with the reviewer's name on the record. It sits in the SoA as an added control, justified by 211.22(c) and the impact assessment. In my experience this is the control an FDA investigator will ask about first, and it is the one the AI-in-the-quality-system review is built to test.

Two changes would redraw this picture. If the vendor started fine-tuning on the company's records, the A.7 exclusions would come back in. If the company built its own retrieval layer or prompt library on top of the vendor's model, A.6.2.3 would partly return. Both belong on the list of triggers for an SoA review.

The mistakes that get an SoA rejected at Stage 1

Stage 1 is a document review. The auditor is checking that the system on paper is complete, consistent and ready to be tested at Stage 2. With auditor backlogs where they are in 2026 (some Stage 2 audits have waited six months or more), a Stage 1 that ends in areas of concern costs real calendar time. These are the findings we see most often.

1. Only the applicable controls are listed. All 38 Annex A controls must appear, the excluded ones with their reason. A list of 30 rows is a finding before the auditor reads a single justification.
2. Exclusion by role, with no role in the scope statement. If the SoA says "we do not develop AI" and the scope statement never says what the organization's role is, the exclusion has nothing to stand on.
3. "The vendor handles it" with nothing behind it. No responsibility allocation under A.10.2, no contract clause, no evidence the vendor does what is claimed.
4. Not applicable used to mean not yet implemented. The second answer is honest and the standard allows it, provided the treatment plan shows when the control will be in place. The first, used for a control that plainly applies, is the fastest way to lose the auditor's trust.
5. No trace to the risk assessment or the impact assessment. Auditors read dates. An SoA approved before the risk assessment was finished was not derived from it.
6. 27001 logic carried over. Justifications like "standard security practice" or "covered by the ISMS" with no cross-reference, and rows that point to technical settings for controls that ask for a process.
7. No status, owner, version or approval. The standard asks whether each control is implemented and requires the risk owners to approve the treatment.
8. A control you rely on that is not in the SoA. If your evidence at Stage 2 leans on an added control, such as qualified review of AI-drafted records, it needs to be in the SoA from Stage 1.

The most common ISO 42001 gaps article covers what tends to fail at Stage 2 once the paperwork has passed.

Keeping the SoA current

The SoA is reviewed at management review under clause 9.3, at least annually, and whenever something changes that could move an applicability decision. The triggers that matter most for an organization using a vendor's AI are the ones a 27001 team does not usually watch for: the vendor updates or swaps the underlying model, the vendor changes its terms on training with customer data, the tool is pointed at a new record type, a state or federal rule takes effect, or an incident shows the intended use was wider than the SoA assumed. Write those triggers into change control, and record the vendor's model version in the supplier file so a change is visible when it happens.

Where to start

If you already run a quality system, most of what the SoA asks for exists in some form: a scope, a risk register, supplier qualification, document control, training records. The work is deciding which Annex A controls your AI use pulls in and writing the reasons down. Our ISO 42001 gap assessment (fixed fee, $9,750) works every Annex A control against your scope and your systems, which is the same analysis the SoA records. Regulated manufacturers who want their AI-drafted records checked before an investigator reads them can start with the AI-in-the-quality-system review at $5,000. The ISO 42001 consulting page explains how we work.

Frequently Asked Questions

Is a Statement of Applicability mandatory for ISO 42001 certification?

Yes. Clause 6.1.3 of ISO/IEC 42001:2023 requires a Statement of Applicability that lists the necessary controls, justifies every inclusion and exclusion, and states whether each control is implemented. The certification body reviews it at Stage 1 and tests it at Stage 2.

Can I exclude Annex A controls from an ISO 42001 Statement of Applicability?

Yes, if the exclusion traces to your scope, your role with respect to the AI system (for example, you use a vendor's model and do not develop one), or the absence of a related risk, impact or obligation. Cost, difficulty and company size are not accepted grounds.

How is the ISO 42001 SoA different from the ISO 27001 SoA?

The 27001 SoA covers 93 security controls that apply to almost every organization, so exclusions are rare. The 42001 SoA covers 38 AI controls whose applicability depends on whether you develop, provide or use AI, so exclusions are routine and the justification carries more weight.

What is the difference between not applicable and not yet implemented in an SoA?

Not applicable means the control has no bearing on your AI systems, scope or risks. Not yet implemented means it applies and you have not done it yet. Marking an unimplemented control as not applicable is one of the fastest ways to fail Stage 1.