Mitigate: Selecting and Sequencing Annex A Controls Without Drowning in Them

Annex A gives you a menu, not a mandate. Implementing every control in document order is how organizations spend a year on compliance work that addresses none of their actual risk.

Annex A of ISO 42001 organizes controls into categories spanning governance policies, resourcing, impact assessment processes, data management, system lifecycle, information for stakeholders, use of AI systems, and third-party/customer relationships. It’s comprehensive by design, which is exactly why treating it as a sequential checklist produces bad outcomes. Some organizations need heavy investment in data governance controls and comparatively light third-party controls. Others are the reverse. The standard doesn’t tell you which; your risk assessment does.

Control selection is a mapping exercise, not a completeness exercise

The organizing question for this stage should be: for each material risk identified in the Assess stage, which specific Annex A control (or combination of controls) actually addresses it? This produces a risk-to-control map that looks different for every organization, because every organization’s risk profile is different, even when everyone is nominally implementing “the same standard.”

A control that exists in Annex A but doesn’t map to any risk finding in your assessment isn’t a gap. It may simply be a control your organization doesn’t need to prioritize, and the standard explicitly allows exclusions with documented justification via your Statement of Applicability. The mistake is implementing controls because they’re listed, without asking what risk they’re supposed to be addressing. That produces implementation effort with no corresponding risk reduction, and it produces control documentation that an auditor can see straight through, because the justification for the control’s existence is “it’s in Annex A” rather than “it addresses risk finding 14.”

Sequencing: what has to come first, structurally

Independent of your specific risk profile, a small set of controls function as prerequisites for others and should generally be implemented first:

• Governance and policy controls: without a documented AI policy and defined roles, every other control lacks an owner and a mandate
• Human oversight controls: because oversight mechanisms often need to exist before you can accurately assess whether other controls (like automated decision review) are functioning
• Documentation and record-keeping controls: because every other control’s implementation needs to be evidenced, and retrofitting evidence collection after the fact is far more expensive than building it in from the start

After that foundational layer, sequencing should follow your risk map: highest-severity, highest-likelihood findings get controls implemented first, not controls that happen to be easiest to implement. This is a genuine tension but an implementation plan optimized for visible velocity rather than risk reduction is exactly the pattern an auditor is trained to notice and probe.

A practical control-implementation workplan structure

For each control you’re implementing, the workplan entry should specify: which risk finding(s) it addresses, who owns implementation, what “implemented” concretely means (the control needs an operational definition, not just a document), what evidence will demonstrate the control is functioning, and the review/reassessment cadence.

A control implemented once and never revisited is a control that degrades silently. Data governance controls in particular tend to erode as new data sources get added to systems without anyone revisiting whether the original control still covers the new source.

The ownership trap

Control implementation frequently gets assigned to whoever is available, rather than whoever has the authority and context to actually maintain it. A data governance control assigned to a compliance analyst with no ability to influence how the data science team sources training data will produce documentation, not control. Ownership should sit with the role that has both visibility into the risk and authority to act on it.

Phasing for a realistic first year

A workable phasing approach for most organizations building this for the first time: Phase one covers foundational governance, policy, and oversight controls plus documentation infrastructure (roughly the first quarter). Phase two addresses the highest-severity risk findings from your assessment, control by control, with evidence collection built in from the start rather than retrofitted (the bulk of the implementation timeline). Phase three addresses lower-severity findings and third-party/supply-chain controls, which tend to take longer because they depend on vendor cooperation you don’t fully control.

Organizations that try to run all three phases in parallel from day one typically end up with shallow implementation across everything and defensible depth in nothing, which is precisely the pattern that produces nonconformities at the certification audit, because auditors sample, and shallow implementation gets caught by sampling far more often than organizations expect.

Controls implemented without a corresponding decision to actually deploy the system they govern are only half the job. The next stage is where risk assessment and control implementation convert into an actual, accountable decision to proceed.