ISO 42001 Annex A: Select and Implement the 38 AI Controls

Understand the structure before counting controls

The 38 controls sit within nine broad themes: policies, internal organisation, resources, impact assessment, lifecycle, data, information for interested parties, use, and third-party and customer relationships. The lifecycle theme has two subthemes: development guidance and lifecycle stages. Theme headings and control objectives provide structure; they are not additional individual controls.

The counts are three policy controls, two internal-organisation controls, five resource controls, four impact controls, nine lifecycle controls, five data controls, four information controls, three use controls and three relationship controls. The lifecycle group comprises two development-governance controls and seven lifecycle controls. This distinction prevents an inflated count based on headings rather than actual entries.

Start from treatment, then compare with Annex A

Clause 6.1.3 connects assessment results with treatment options and all necessary controls. The organisation compares those controls with Annex A, considers relevant reference controls and identifies whether additional controls are needed. An important control is not unnecessary simply because it is absent from the reference list.

A useful implementation conversation follows one consequential scenario. What result is the treatment intended to achieve? Which arrangements can achieve it? Who operates them, and what evidence would show that they work? Only then does a control label become useful. Starting with a fully ticked Annex A table can hide that reasoning.

Roles influence implementation. An organisation using a purchased service may not perform model training, but it still decides purpose, inputs and reliance on outputs. A developer has different design and evaluation responsibilities. A supplier's involvement can change an interface without removing every responsibility from the organisation using the service.

Read Annex B with the correct status

Annex B is normative, and clause 6.1.3(e) requires consideration of its implementation guidance. Calling it entirely optional would miss that requirement. At the same time, B.1 recognises that the guidance may not suit every situation and permits extending or modifying it, or designing a suitable implementation.

The organisation does not need a separate SoA justification for accepting or declining each implementation example in Annex B. Necessary-control selection and the choice of a suitable implementation method are connected but different decisions. The guidance informs the method without requiring every example to become an identical compulsory procedure.

Make the Statement of Applicability explain the choice

The Statement of Applicability identifies necessary controls and explains inclusion and exclusion. It should reflect identified risks and the measures used to address them. A linked information arrangement can support that relationship; the useful test is whether someone can follow the reasoning without relying on the original author's memory.

Keep the SoA distinct from the treatment plan and operating evidence. The SoA explains applicability, the plan directs treatment work, and records show implementation and results. A control marked selected is not automatically implemented, and implementation is not automatically effective. Those differences matter when management accepts remaining risks.

Illustrative software example: a customer-facing assistant

A software provider proposes an AI assistant that drafts technical answers for customers. Assessment identifies the consequence of plausible but unsupported instructions and the possibility that customers will misunderstand the feature's limits. A generic “human oversight” control description would not explain how those issues are managed.

The provider connects development objectives with requirements and evaluation, examines the data and tooling behind answers, and determines what users need to know. It allocates responsibility for release, monitoring and responding to concerns. Supplier information becomes one part of the evidence, rather than a substitute for evaluating the provider's actual service.

The selected controls work together. User instructions cannot compensate for an interface that encourages uncritical reliance; testing cannot preserve suitability after changed inputs unless monitoring and reassessment operate. The SoA explains why the relevant controls are necessary, while the implementation makes the relationships visible in development and service processes.

Illustrative manufacturing example: a purchased inspection aid

A manufacturer purchases an AI inspection aid. It does not design the underlying model, but it determines the product variants, operating conditions and role of employees reviewing uncertain cases. Assessment reveals that performance differs under some lighting conditions and that temporary staff need clearer instructions.

The organisation examines resource, data, deployment, operating and use controls. It clarifies the supplier relationship and the evidence available about limitations. It does not automatically exclude all lifecycle controls because the model was purchased, or pretend to perform the supplier's internal development activities.

Verification asks whether the local arrangements address the identified consequence. A review signature proves an activity occurred; it does not prove reviewers could recognise the missed defect. The manufacturer's AIMS decision also remains distinct from technical product conformity and any applicable safety obligations.

Use the themes to find related decisions

Policy controls connect direction, alignment and review. Internal organisation makes responsibilities and concern reporting workable. Resource controls reveal the data, tooling, computing and people on which a use depends. These themes help explain why an apparently technical issue may require a management decision.

Impact controls examine consequences for people and society and preserve the assessment evidence. Lifecycle controls connect development objectives, requirements, evaluation, deployment and continuing operation. Data controls address the decisions behind acquisition, quality, provenance and preparation rather than treating data as a passive asset.

Information controls connect user guidance, external reports and reporting obligations. Use controls examine objectives, processes and intended conditions. Relationship controls clarify responsibilities with suppliers and customers. Follow the actual decision across themes instead of treating each family as an isolated department's checklist.

Build evidence around the intended result

For each necessary control, distinguish the required outcome from the chosen method. A documented policy or process may be part of the control, but evidence of its operation also matters. Follow an ordinary case and a difficult exception to see whether people can apply the arrangement.

Choose proportionate records. An overly complex control library can create duplication and conflicting versions, while an unexplained status field can hide missing reasoning. Relevant evidence should show purpose, responsibilities, operating conditions and the result being evaluated. Protect sensitive information while making it available to authorised people who need it.

Sequence implementation around dependencies

Begin with the scope and consequential uses, then clarify assessment, responsibilities and necessary controls. Develop the information and competence that operating teams need, and test important interfaces before describing the system as ready. The sequence can be iterative; it should preserve the decisions rather than postpone them until an audit.

Effivity ISO & GRC automation software can be considered within an agreed consulting and documentation work scope. Software arrangements should support the organisation's control design and evidence needs. They do not determine applicability, supply missing expertise or guarantee certification simply by being installed.

Why Annex A works best after risk treatment

Annex A can look like a shopping list, and treating it as one is the commonest way to waste effort. Its real value is as a cross-check: after an organisation has assessed its AI risks and chosen treatments, the list helps confirm that nothing important was missed. Working in that order saves money, because effort goes where the exposure is, and it gives clients a coherent story about why each control is in or out. It also keeps an auditor's questions manageable, since the organisation can explain the reasoning behind the Statement of Applicability. Businesses that start from a fully ticked table usually discover later that their evidence does not match what the ticks claim.