An AI risk assessment template should give the board one approval record: the proposed use, affected people and data, expected benefit, material risks, controls, evidence, named owners, residual risk and the decision requested. It is not legal advice and does not replace a DPIA.
Key takeaways
- Assess the use case, not the product name: the UK government's AI Playbook tells teams to assess risks, benefits, harms and controls early in the AI project life cycle.
- Treat personal data as a separate gate: the ICO's DPIA guidance and AI guidance sit alongside the board risk assessment where UK GDPR is engaged.
- Use the assessment to decide, not to describe: approve, approve with conditions, defer for evidence, or decline.
- Record evidence against each control, because the NIST AI RMF Core expects risk work to move from mapping to measuring and managing, not just listing concerns.
- Feed the outcome into the policy and register: the policy says what is allowed, the assessment decides this use, and the risk register tracks the residual risk over time.
AI risk assessment template for board approval
Use this section as the front page of a board paper. The GOV.UK AI Playbook says an AI risk assessment should be part of project design, should weigh benefits against risks, and should identify harms to individuals or groups, misuse, bias, legal risk, operational risk and security risk before the system is built or adopted.
| Field for the board paper | What to record | Evidence to attach |
|---|---|---|
| Proposed use | The exact process, decision or service the AI will support | One-page use-case description and process map |
| People affected | Staff, customers, tenants, pupils, service users, suppliers or the public | Stakeholder list and harm analysis |
| Data involved | Personal data, special-category data, confidential data, public data, synthetic data or no data held by the organisation | Data-flow note, lawful-basis view where personal data is involved, supplier data terms |
| Level of autonomy | Drafting aid, recommendation, triage, decision support, or automated decision | Human role description and escalation path |
| Expected benefit | Time saved, consistency, access, quality, cost reduction or risk reduction | Baseline metric and target metric |
| Material risks | Bias, inaccuracy, hallucination, security, data leakage, over-reliance, contestability or supplier dependency | Risk notes linked to tests, DPIA findings or procurement evidence |
| Controls | Technical, contractual and human controls that reduce the risk | Test results, access controls, audit logs, approval workflow, supplier clauses |
| Residual risk | The risk left after controls, with rationale | Owner sign-off and review date |
| Decision requested | Approve, approve with conditions, defer, pilot only, or decline | Conditions, review trigger and named accountable owner |
The assessment should sit before the approval decision, not after procurement has already committed the organisation. That sequence is consistent with the AI Playbook's recommendation to establish ownership of AI risks at a senior level, integrate oversight into governance processes, and maintain an AI systems inventory with purpose, risk, ownership and key dates.
Risk assessment, DPIA, risk register and policy are different controls
A board risk assessment is the decision record for one proposed AI use. A DPIA is the data-protection assessment required where personal-data processing is likely to create high risk, and the ICO's DPIA guidance says the process covers whether a DPIA is needed, how the processing works, necessity and proportionality, risks, mitigations and whether the ICO must be consulted. The ICO's AI and data protection guidance is under review following the Data (Use and Access) Act 2025, so a board paper should date any legal assumption and ask the DPO or legal adviser to confirm it before approval.
The AI policy sets the standing rules: permitted uses, prohibited uses, data handling, human oversight, supplier requirements, incidents and review. The risk assessment applies those rules to one proposal. A living AI risk register then tracks the residual risk, controls, evidence and review rhythm after the decision. If staff are already using unsanctioned tools, assess the proposed use alongside the shadow AI policy, because the hidden use may be the real risk baseline.
Do not let one artefact pretend to be all four. A policy without assessment becomes a rulebook nobody applies. A DPIA without a board risk decision answers only the data-protection part of the case. A register without evidence is a stale list. The board assessment is the point where these controls meet and a named decision is made.
Controls and evidence for the paper
The control table is where the board can test whether the paper is ready. The ICO AI risk toolkit is designed to help organisations reduce risks to individuals' rights and freedoms from their own AI systems, while the NIST AI RMF Core frames work through Govern, Map, Measure and Manage. Use those sources to make the controls measurable.
| Risk question | Minimum control | Evidence the board should see | Owner |
|---|---|---|---|
| Is the use in scope and lawful? | Named approval route, policy fit check, lawful-basis view where personal data is used | Policy exception note or confirmation, DPIA screening, legal or DPO view | Executive sponsor and DPO |
| Could the system harm people through bias or inaccuracy? | Test plan covering relevant groups, quality thresholds, human escalation | Evaluation results, sample failures, threshold rationale, mitigation log | Product or service owner |
| Could confidential or personal data leak? | Approved tool only, supplier terms, access control, retention setting | Data-processing terms, access list, retention configuration, security review | Information governance or security lead |
| Could users over-trust the output? | Human role defined, output labelling, mandatory review for high-impact use | Workflow screenshot, training record, decision log, review checklist | Operational owner |
| Can affected people challenge or correct an outcome? | Contestability route and named human reviewer | User-facing notice, complaint or appeal path, response standard | Service owner |
| Will the board know if risk changes? | Review triggers for model change, data change, incident, regulator update or scale-up | Register entry, monitoring metric, incident route, next review date | Risk owner |
The evidence column matters because approval conditions should be testable. If the paper says "human review", it should name who reviews, when they can overrule the AI, and where that overrule is recorded. If the paper says "bias testing", it should show what was tested, against which population or proxy, when, and what failed. For a fast first pass, the free AI risk register tool can turn the proposal into a draft register entry before the board paper is finalised.
Framework mapping for UK boards
The UK government's 2024 response to the AI regulation white paper confirms five cross-sectoral principles for existing regulators to interpret within their remits: safety, security and robustness; appropriate transparency and explainability; fairness; accountability and governance; and contestability and redress. A board assessment should therefore map each proposal to those principles rather than waiting for one consolidated UK AI Act.
| Framework | What it adds to the assessment | Board evidence |
|---|---|---|
| UK regulatory principles | A principles map for safety, transparency, fairness, accountability and contestability | One row per principle, with a control and owner |
| ICO and UK GDPR | A personal-data gate covering DPIA need, lawful basis, data minimisation, transparency and safeguards | DPIA screening, DPIA where needed, DPO or legal review |
| NIST AI RMF | A risk-management structure: Govern, Map, Measure and Manage, with governance infused through the other functions | Owner, system context, metric, control and residual risk |
| ISO/IEC 42001 | A management-system lens for policies, objectives, processes and continual improvement in responsible AI use | AI management-system owner, review cycle, statement of applicable controls |
| GOV.UK AI Playbook | A practical delivery benchmark for inventory, senior ownership, risk assessment, escalation and monitoring | Inventory entry, escalation route, project controls, post-approval monitoring |
This mapping is not certification. NIST says the AI RMF is voluntary, and ISO describes ISO/IEC 42001 as a management-system standard for establishing, implementing, maintaining and continually improving AI-related policies, objectives and processes. The board value is simpler: the same evidence can satisfy several frameworks when it is recorded once and kept current. The wider structure is set out in our guide to a UK AI governance framework.
Common mistakes before approval
The first mistake is assessing the vendor instead of the use. A general-purpose tool can be low risk when summarising public documents and high risk when applied to complaints, safeguarding, eligibility or employment. The GOV.UK AI Playbook's inventory section records purpose, usage, risks, data elements, ownership, development and key dates because risk changes with context.
The second mistake is treating a DPIA as the whole approval case. DPIAs are necessary where the data-protection threshold is met, but they do not decide whether the benefit is strong enough, whether the supplier dependency is acceptable, or whether the board's risk appetite allows the level of autonomy. Those are board-risk questions, supported by the DPIA rather than replaced by it.
The third mistake is approving a pilot without exit conditions. A pilot should state what would stop it: an accuracy threshold missed, an unresolved DPIA issue, an incident, low user compliance, evidence of unfair impact, or a supplier term the organisation cannot accept. NIST's Core is continuous across the AI life cycle, so the approval paper should also define what moves from pilot to scale-up.
The fourth mistake is burying the decision in prose. The board paper should end with a clear approval line: "approve subject to these three conditions by this date"; "defer until the DPIA and supplier terms are complete"; or "decline because the residual risk exceeds appetite." If the board cannot minute the decision in one sentence, the assessment is not yet ready.
Next step: turn the assessment into evidence
Start with the board paper fields above, then create the register entry before approval. That gives the board a concrete object to challenge: the owner, risk, control, metric and review date. It also makes the post-approval handover cleaner, because the approved conditions already have a place to live.
If the proposed use is still rough, use the Board AI Scorecard to identify governance gaps before the paper is drafted. If the use is ready for scrutiny, generate a first-pass entry with the AI risk register tool, then bring the residual-risk judgement into the board paper. For an assessor-led review across policy, register, DPIA readiness and control evidence, the AI governance diagnostic is the paid next step.
Last reviewed: 18 June 2026.
Sources: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/; https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/ai-and-data-protection-risk-toolkit/; https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/; https://airc.nist.gov/airmf-resources/airmf/; https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10; https://www.gov.uk/government/publications/ai-playbook-for-the-uk-government/artificial-intelligence-playbook-for-the-uk-government-html; https://www.gov.uk/government/consultations/ai-regulation-a-pro-innovation-approach-policy-proposals/outcome/a-pro-innovation-approach-to-ai-regulation-government-response; https://www.iso.org/standard/42001
