A.2 Policies Related to AI: Writing, Approving and Reviewing Them

Control A.2 requires that your organisation establishes, implements and maintains policies related to AI. These are not generic policies copied from a template. They must address the specific decisions your organisation makes about how it develops, deploys and uses AI systems. This lesson explains what policies belong in A.2, who must approve them and how auditors test whether they are actually in use.

What belongs in your AI policies

Your AI policies should cover at least three areas. First, they should state your organisation’s approach to AI governance and risk. This policy describes roles, responsibilities and escalation paths. Second, you need a policy on data use for AI, including what data sources are permitted, how data provenance is verified, and who approves data selection. Third, a responsible use policy should define what your organisation considers acceptable versus unacceptable uses of AI systems in your business processes.

Many organisations add a fourth policy on third-party AI systems and model selection. This policy documents how vendor models are evaluated, whether internal testing is required before deployment, and what contractual controls must be in place. Some add a policy on AI incident response that defines what constitutes an incident, who should be notified and how you handle system failures or outputs that cause harm.

Approval and review cycles

Policies are not approved once and forgotten. Clause A.2 requires that policies are approved at an appropriate level of your organisation. For AI governance policy, this often means approval from your Chief Information Officer, Chief Risk Officer or an AI steering committee. Approval by a single project manager is insufficient; the auditor will challenge this.

Policies must also be reviewed and updated on a defined schedule. Many organisations review their AI policies annually or when significant changes occur, such as adoption of a new model class or a documented incident. Your control register should list each policy’s approval date, next review date and the role responsible for review. During audit, if a policy is overdue for review, the auditor will flag this as a finding.

Testing that policies are followed

An auditor does not assume your policies are followed because they exist. A common finding is “policies exist but are not evidenced in operation”. To evidence policy compliance, you need records showing that staff have read the policies, completed training on them, or followed their requirements when making decisions.

For example, if your data policy requires that training data be logged before it is used in an AI system, then your audit evidence must include logs of data sources, dates they were reviewed and signatures from the responsible person. If your responsible use policy requires that new AI systems undergo impact assessment before deployment, you must have records showing that each deployed system has an impact assessment document that was completed before go-live.

Linking policies to control objectives

Control A.2 is about policy creation and maintenance, but its purpose is to support all other controls. An auditor will look at your policies to understand what processes you have committed to, then examine whether those processes are followed. If your policy says data provenance must be verified but your actual projects skip this step, this is a control failure.

Many organisations create a “policies matrix” that maps each Annex A control to the policies that support it. This matrix helps auditors see that your policies cover all your selected controls and helps your team understand why each policy exists. For instance, your data quality policy might address controls A.4 (Resources), A.7 (Data for AI Systems) and A.10 (Supplier Controls).