6.1 Annex A Overview & The Statement of Applicability (SoA)

Annex A, Annex B, and the Statement of Applicability

ISO/IEC 42001 combines mandatory management-system requirements in Clauses 4–10 with AI-specific reference controls in Annex A. The relationship is risk-based: the organization determines what controls it needs, compares those controls with Annex A, and records the decision in the Statement of Applicability.

Annex status

The annex designations are important:

Calling Annex B informative is incorrect. It is normative implementation guidance. That does not mean every example in the guidance is the only permitted implementation; Clause 6.1.3 requires the organization to consider the guidance for determined controls.

Annex A is a reference catalogue

Annex A states that not all listed control objectives and controls are required to be used. An organization can design and implement its own controls. The catalogue is a completeness reference for risks related to design and operation of AI systems.

The nine groups and correct counts are:

The total is 38. Objective rows such as A.2.1 or A.6.1.1 are not controls. That is why the first actual A.2 control is A.2.2 and the first A.3 control is A.3.2.

The control-selection sequence

Clause 6.1.3 connects risk treatment to Annex A:

1. Select appropriate treatment options.
2. Determine all controls necessary to implement the chosen options and compare them with Annex A so none is omitted.
3. Consider Annex A controls relevant to the options and identify additional controls needed beyond Annex A.
4. Consider Annex B implementation guidance for the determined controls.
5. Produce the SoA.
6. Formulate the risk-treatment plan and obtain designated-management approval for the plan and residual risk.

The sequence prevents two opposite errors. Blindly implementing all 38 controls ignores context and can create ineffective bureaucracy. Ignoring Annex A after choosing familiar controls can leave an AI-specific gap.

What the SoA must contain

Clause 6.1.3 requires the SoA to contain necessary controls and provide justification for inclusion and exclusion. The standard also explains that an exclusion can be justified where a control is not deemed necessary by risk assessment or is not required by, or falls under an exception in, applicable external requirements.

A common implementation uses a table with:

• control reference and title;
• selected or excluded status;
• inclusion or exclusion rationale;
• implementation status;
• owner and evidence references.

That is an effective way to demonstrate completeness, especially by accounting for all 38 Annex A controls. However, distinguish this practical format from the clause text. ISO/IEC 42001 does not expressly prescribe “four mandatory elements for every control,” and it does not expressly name implementation status as a required SoA field.

Inclusion and exclusion logic

A control is included because it is necessary to treat risk, achieve objectives, address impact findings, or meet applicable requirements. A control is excluded because it is not necessary in the defined scope and context—not merely because it is inconvenient.

Examples:

• A pure user of a fixed vendor system may find some internal model-development controls unnecessary. It still needs to consider requirements, deployment, use, supplier, information, and impact controls.
• An organization that does not supply AI to customers may find some customer-facing control aspects inapplicable, but it should examine whether it still has AI users or interested parties needing information.
• A control can be necessary even if a different implementation achieves its objective. The organization can design an additional or alternative control and document the reasoning.

Cost can be considered when selecting among effective treatments, but “too expensive” alone does not demonstrate that a control is unnecessary when risk and applicable requirements demand it.

Control objective versus control

Each group states an objective and then lists controls. The objective explains intended outcome. The controls state actions. For example, A.8’s objective is that relevant interested parties have necessary information to understand and assess risks and impacts. Its four controls address user information, adverse-impact reporting, incident communication, and reporting obligations.

Do not count the objective itself as a control. In A.6, two subgroups each have an objective row, and the nine controls use numbers such as A.6.1.2 and A.6.2.2.

SoA versus risk-treatment plan

The SoA identifies necessary controls and explains selection. The risk-treatment plan says how treatment will be carried out. They are connected but not interchangeable. The plan can include actions, owners, resources, timing, measures, and residual-risk acceptance.

Maintaining applicability

The SoA should remain aligned with scope, context, risk, impacts, objectives, suppliers, and system changes. New AI use, a new customer relationship, a supplier change, or an impact finding can change which controls are necessary. The exact review cadence is determined by the organization’s processes rather than a universal annual rule.

Exam decision path

When presented with an Annex A scenario:

• Ask whether the control is necessary for the assessed risks and impacts.
• Check whether another applicable requirement makes it necessary.
• Confirm Annex A comparison occurred.
• Expect inclusion or exclusion rationale in the SoA.
• Do not assume all controls are mandatory or that a control disappears merely because a supplier performs part of it.