Organisational controls: A.2 to A.5

A.2 — Policies related to AI (3 controls)

A.2.2 AI policy — document a policy for the development or use of AI systems. This is the same policy clause 5.2 demanded; the control makes its existence and content an auditable object. A.2.3 Alignment with other organizational policies — determine where AI intersects your existing policy estate (information security, privacy, HR, procurement, quality) and reconcile them, so the AI policy never contradicts the data-retention schedule. A.2.4 Review of the AI policy — review at planned intervals and when significant changes occur: new regulation, a serious incident, a pivot into a new AI role.

Evidence: the signed policy, a policy-alignment mapping, review minutes showing the policy actually changed when the world did.

A.3 — Internal organization (2 controls)

A.3.2 AI roles and responsibilities — define and allocate them: who owns each AI system, who runs risk assessments, who signs off impact assessments, who answers the regulator. Unowned systems are where incidents incubate. A.3.3 Reporting of concerns — a mechanism for people to report concerns about the organisation’s role in an AI system throughout its lifecycle, without fear of reprisal.

That second control is quietly radical for a management-system standard. The engineers usually know first — before the monitoring dashboard, before the press. Google’s handling of Timnit Gebru’s 2020 objections and the internal dissent that leaked around it became a case study in what happens when concern-raising has no safe channel: the concern surfaces anyway, in public, with interest.

Evidence: role assignments (org chart, RACI), the reporting channel, records showing reports were received, triaged, and answered.

A.4 — Resources for AI systems (5 controls)

One control for the habit — A.4.2 resource documentation: identify and document the resources each AI system needs — and four controls for the categories: A.4.3 data resources (training, validation, test, and operational data), A.4.4 tooling resources (frameworks, libraries, pipelines — the place your open-source model dependencies get written down), A.4.5 system and computing resources (compute, storage, where it runs), and A.4.6 human resources (the competences each lifecycle stage demands: data science, security, domain expertise, ethics review).

Why regulators love this grouping: you cannot govern what you have not inventoried. Most organisations that start a 42001 programme discover shadow AI here — the marketing team’s unapproved chatbot subscription, the fine-tuned model living in one engineer’s notebook.

Evidence: per-system resource records; competency matrices; training plans tied to actual lifecycle roles.

A.5 — Assessing impacts of AI systems (4 controls)

A.5.2 establish an impact assessment process — one that evaluates consequences for individuals, groups of individuals, and societies, not just for the organisation. A.5.3 document the assessments. A.5.4 assess impacts on individuals and groups — fairness, privacy, safety, economic harm. A.5.5 assess societal impacts — environment, labour markets, misinformation, culture.

This grouping is the AIMS hook for AI system impact assessment — the discipline ISO/IEC 42005:2025 turns into a full method (next module in this domain). Clause 6.1.4 requires the process; A.5 makes each piece independently auditable.

Evidence: the procedure; completed assessments for in-scope systems; follow-up actions traceable into the risk register.