What an AI control is, and where controls come from

The definition the risk standards use is deliberately broad. A control can be a process, a policy, a device, a practice, a condition, or an action. It does not have to be a document, and with AI it usually is not: an access boundary, an input validation step, a logging configuration, a threshold that halts a model, and a mandatory human checkpoint are all controls, and none of them is written prose.

The standards also separate the control from the control objective. The objective is the outcome you are trying to secure; the control is the measure taken to secure it. ISO/IEC 42001’s Annex A is a table of both, which is why two organizations can share an objective and implement quite different controls against it, and why an auditor asks what you were trying to achieve before asking what you built.

One property is worth stating plainly, because the rest of this page depends on it. A control may not exert the effect assumed of it; the risk standards say so explicitly. A control can be present, documented, approved, and still modify nothing. That is why design effectiveness and operating effectiveness are tested as separate questions, as our article on AI controls in production explains, and why a control inventory is not an assurance programme.

The standard is built in two parts. Clauses 4 to 10 carry the requirements — context, leadership, planning, support, operation, performance evaluation, improvement — and conformity is assessed against those. The controls reach the audit through the Statement of Applicability that clause 6.1.3 itself requires. The annexes then supply the control material: Annex A lists the reference control objectives and controls, Annex B gives implementation guidance under the same numbering, Annex C sets out candidate organizational objectives and risk sources, and Annex D covers running the management system across domains and sectors.

Annexes A and B are normative; C and D are informative. That distinction is narrower than it sounds, and it cuts both ways. Normative does not mean apply everything — Annex A is explicitly a reference set, selected from through the Statement of Applicability. What it does mean is that clause 6.1.3 requires Annex B’s guidance to be taken into account when implementing the controls you did select. Annex B is part of the standard, not commentary running alongside it, and working from the Annex A titles alone leaves half of what the standard provides unused.

Annex A is a reference set, and reading it as a mandatory checklist inverts how it is meant to work. Clause 6.1.3 introduces it as reference material; Annex A itself states that not all of its control objectives need be applied, and that an organization may design and implement its own. The mechanism runs the other way round: determine the controls your risk treatment actually requires, then compare against Annex A to verify that nothing necessary was left out.

The EU AI Act works differently again, and the difference matters in practice. It imposes requirements rather than controls: Articles 9 to 15 state what a high-risk system must achieve — risk management, data governance, documentation, logging, transparency, human oversight, accuracy, robustness and cybersecurity — not how to achieve it. Those requirements have to be mapped onto the controls you actually implement, so that every obligation has something concrete answering it, and so that one control can answer several obligations instead of each being built separately.

That mapping is the substance of an AI management system built for a specific organization. One control list, derived from your own risk treatment, cross-referenced to the legal obligations attaching to the systems in scope and to the Annex A objectives, with the gaps visible. Without it the failure is predictable: a control set that satisfies an annex, a separate compliance workstream chasing the Act, and no single view of whether anything is actually covered.

Your own controls are the normal case rather than an exception. Clause 6.1.3 is explicit that the Annex A set is not exhaustive, that additional controls may be required, and that an organization may design them itself or adopt them from other sources. That matters most where published sets have not caught up: for agentic systems there is no adequate control catalogue anywhere yet, so controls have to be designed against the specific action space, and no annex will supply them.

The Statement of Applicability is where the choices get justified. It records the necessary controls together with a reason for each inclusion and each exclusion. An exclusion is defensible where the risk assessment did not find the control necessary and no external requirement demands it, and a justification for excluding a control objective may be given in general or for specific AI systems, whether the objective came from Annex A or was determined in-house. An auditor reads the SoA closely, because it is where judgement is visible.

NIST AI RMF is absent from this section by design. It specifies outcomes, not controls: an outcome taxonomy sits above any catalogue, so it can be satisfied with ISO/IEC 42001 controls, another set, or your own. Used as a control set it would leave a list of desired states with no measures underneath, nothing to exclude and therefore no Statement of Applicability. It belongs upstream, in the risk process, deciding which outcomes you are aiming at.