AI Risk: What UK Boards Should Ask

UK boards should prepare now for the 2027 requirement under the UK Corporate Governance Code to declare whether material controls worked, since more of those controls run on AI, according to a board-risk guide that cites an AI coding agent deleting a production database in July 2025 despite a plain-English instruction not to change anything. The guide maps eight frameworks — including Provision 29, the EU AI Act and ISO/IEC 42001 — onto one set of controls and offers eight board questions, a nine-field AI risk register, and four incident steps. It also flags four actions to take before the ICO's call for evidence on agentic AI closes on 20 November, quoting the ICO's Tech Futures analysis that "AI agency does not mean the removal of human, and therefore organisational, responsibility.

← All posts https://reinvently.co.uk/blog/ Key Takeaways - One Set of Controls, Mapped to Every Framework one-set-of-controls-mapped-to-every-framework : Eight frameworks, from Provision 29 to the EU AI Act, ask for the same few things, so one set of controls can evidence all of them. - Eight Questions for the Board eight-questions-for-the-board : Eight questions to put to the executive, each with what a credible answer contains and the answer that should prompt a follow-up. - What an AI Risk Register Should Record what-an-ai-risk-register-should-record : Nine fields that record what each AI system can read, change and send, each tied to a logged incident, with a template to request. - Four Steps the Board Owns in an AI Incident four-steps-the-board-owns-in-an-ai-incident : Define, contain, notify and learn, with the reporting clocks mapped before they are needed. - What to Do Before 20 November what-to-do-before-20-november : Four actions to take before the ICO’s call for evidence on agentic AI closes. - Appendix: Every Framework, Mapped appendix-every-framework-mapped : All eight frameworks, from Provision 29 to ISO/IEC 42001, with who each applies to and which part of this guide answers it. For your board pack: a one-page brief https://reinvently.co.uk/briefs/board-ai-risk/ with the eight questions and four actions, and a risk register template get-register to request. From 2027, boards reporting against the UK Corporate Governance Code will declare whether their material controls worked. More of those controls now run on AI, often as a feature switched on inside software the organisation already pays for. So ask yourself a simple question: could your board say what those systems can actually do? Consider one case. In July 2025, an AI coding agent deleted a production database during a code freeze. It had been told, in plain English, not to change anything. It had also been given production credentials. The instruction was a policy. The credential was the control. One Set of Controls, Mapped to Every Framework You do not need a programme for each framework. Eight touch AI risk in UK boardrooms, and only one, the EU AI Act, is AI law. All eight ask for the same four things: know what AI you run and who owns it, prove the controls work, rehearse incidents, and report to the board on a fixed cycle. One set of controls that does those four things evidences them all. The questions, register and plan below are that set; the appendix appendix-every-framework-mapped maps each framework onto it. For most boards, two matter most. Provision 29 makes AI a declaration question: if AI approves payments, screens customers or changes production systems, it is part of a control you may be declaring effective. And data protection law applies to everyone. As the ICO’s Tech Futures analysis puts it, “AI agency does not mean the removal of human, and therefore organisational, responsibility.” Our ICO analysis https://reinvently.co.uk/blog/ico-agentic-ai-call-for-evidence/ has the detail. So AI risk does not need its own committee. It needs a place in the register, the controls review and the incident plan you already oversee. Eight Questions for the Board Put these to your executive. Each comes with what a good answer looks like, and the answer that should prompt a follow-up. | Question | A credible answer includes | Follow up if you hear | |---|---|---| | 1. Which AI systems do we run, including features inside tools we already pay for, and who owns each one? | A current inventory with a named owner for each, including vendor features. | “IT keeps a list of the projects it approved.” | | 2. Which of them perform, feed or could bypass a material control? | A map from AI systems to material controls. | “AI is outside the scope of our controls review.” | | 3. What can each system read, and where can it send data? | Documented data scope and outbound channels for each system. | “It only sees what the user can see.” | | 4. What can each system change without a person approving, and how do we stop it? | Least-privilege access, no standing production credentials, and a tested stop. | “The prompt tells it not to.” | | 5. Does any system make or shape significant decisions about people? | A list of those decisions, with notice, a right to contest and real human review. | “A manager approves every recommendation.” | | 6. What do our suppliers tell us when their AI fails or changes? | Contract terms for incident and change notice, and for exit. | “We would see it on their status page.” | | 7. What counts as an AI incident here, and when did we last rehearse one? | A written definition that includes near misses, and an AI exercise in the past year. | “It would follow the cyber incident plan.” | | 8. What AI risk information reaches this board, and how often? | Quarterly risk measures with agreed tolerances. | Adoption figures with no risk measures. | Questions 3 and 4 need someone to check the configuration, not the policy. Start there. What an AI Risk Register Should Record A register that lists the use case, owner and risk rating tells you what a system is for. Your questions are about what it can do, so record what it can read, change and send. Each field below is tied to a case from our incident log https://reinvently.co.uk/tools/agent-incidents/ . | Field | What to record | Incident that shows why | |---|---|---| | Owner and stop authority | Who owns it, and who can stop it | Replit, July 2025: told not to touch production, but held the credentials | | Data scope | Everything it can read, including new connectors | EchoLeak, June 2025: one email could make Copilot leak internal files | | Untrusted inputs | The emails, forms, documents and web pages it reads | ForcedLeak, 2025: a web form hijacked Salesforce Agentforce | | Permitted actions | What it can do without approval | Manus, October 2026: a malicious email made it run code | | Outbound channels | Where it can send or publish data | PixelLeak, September 2026: agents posted internal screenshots publicly | | Instruction supply chain | Where its prompts and extensions come from | Amazon Q, July 2025: a poisoned prompt shipped in an extension | | Decision significance | Decisions about people, and their safeguards | UK GDPR Articles 22A to 22D; our employer guidance https://reinvently.co.uk/blog/uk-ai-regulation-ico-employment-2026/ | | Supplier and change triggers | Provider terms, and what forces a review | EchoLeak and ForcedLeak: fixed only by vendor patches | | Incident route | Threshold and reporting clocks | See the plan below | Several were research demonstrations or were patched without harm. Each still shows a control that existed on paper but not in the system. Start with the ten systems that touch customer data, money or production. Template · CSV · opens in Excel or Google Sheets Get the AI risk register template A column for each field above, plus risk tier, reporting clocks, frameworks in scope and review dates, with one worked example row to replace. Enter your email and we will send you the link. We use your email to send the template link. We only add you to our mailing list if you tick the box. See our privacy policy https://reinvently.co.uk/privacy/ . Four Steps the Board Owns in an AI Incident Your cyber or breach plan can handle an AI incident, if it has been tested for three differences: AI incidents can start from content, agents act faster than people can review, and the fix often sits with a supplier. Four steps belong to the board. 1. Define. Write down what counts as an AI incident and a near miss: an agent acting outside its scope, data sent somewhere it should not go, a significant decision made without its safeguards, a supplier change that alters results. 2. Contain. Know how to stop each high-risk system before you need to: revoke its credentials, cut the connector, switch off the feature. Name who can do it, and how fast. 3. Assess and notify. Map the reporting clocks now: 72 hours to the ICO for a personal data breach where feasible UK GDPR Article 33 , a 24-hour first notice under the Cyber Security and Resilience Bill if you are in scope, and your regulator’s own rules. Decide who makes each call before the incident. 4. Learn. Feed every incident and near miss back into the register and the next exercise. Run an AI scenario at least once a year, as the Cyber Governance Code expects of incident plans. Leave detection and recovery to your technical team, but check they have a searchable record of what each agent did, and backups that restore. The deleted database came back only because the backups worked. What to Do Before 20 November The ICO’s call for evidence on agentic AI closes on 20 November 2026. Read it even if you do not respond: its sections are the questions the regulator will ask after an incident. - Put the eight questions on the next risk committee agenda. Ask for written answers for the ten highest-risk AI systems, not a presentation on the AI strategy. - Add AI to the Provision 29 scoping. For boards reporting against the Code, ask which material controls depend on AI, before the first declaration in 2027. - Run a 90-minute tabletop exercise. Use a logged case: an email that makes your assistant send internal documents outside the organisation. Time how long it takes to identify the owner, stop the system and decide whether the ICO must be told. - Check two supplier contracts. Pick the two AI suppliers with the widest data access and confirm what they must tell you, and how quickly, when their AI fails or changes. None of this needs new technology. It needs a board that asks what its AI can do, not only what it is for. Appendix: Every Framework, Mapped Where each framework applies, what it asks for, and which question, register field or plan step answers it. | Framework | Who it applies to | What it asks for | Answered by | |---|---|---|---| | UK Corporate Governance Code, Provision 29 https://www.frc.org.uk/docs/9097/html/ | Companies on the Code, from 1 January 2026 | An annual review and declaration that material controls work, first in 2027 reports | Questions 1, 2 and 8; the register | | Cyber Governance Code of Practice https://www.gov.uk/government/publications/cyber-governance-code-of-practice/cyber-governance-code-of-practice | Boards that adopt it | Owned digital risk, an annual incident exercise, quarterly board reporting | Questions 1, 3, 4 and 6 to 8; the plan | | UK GDPR https://www.legislation.gov.uk/eur/2016/679/contents and the ICO https://ico.org.uk/about-the-ico/ico-and-stakeholder-consultations/2026/10/agentic-ai-call-for-evidence/ | Anyone whose AI processes personal data | Accountability, safeguards for automated decisions, 72-hour breach notice | Questions 3, 5 and 7; the register | | Cyber Security and Resilience Bill https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/incident-reporting | Essential services and key suppliers, once enacted | A 24-hour first notice and 72-hour report; AI incidents may be added | Question 7; the plan | | FCA rules https://www.fca.org.uk/publications/good-poor-practice/ai-financial-services and the FSB practices https://www.fsb.org/2026/10/sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-final-report/ | Financial firms | Existing FCA rules; the FSB’s 12 lifecycle practices | Questions 2, 4 and 6 | | EU AI Act https://eur-lex.europa.eu/eli/reg/2024/1689/oj , as amended by the Digital Omnibus https://eur-lex.europa.eu/eli/reg/2026/1744/oj | UK firms whose AI is used in the EU | Bans since February 2025, transparency since August 2026, high-risk duties from December 2027 | Questions 1, 2 and 5, plus conformity work | | NIST AI Risk Management Framework https://www.nist.gov/itl/ai-risk-management-framework | Voluntary; common in multinationals | Govern, Map, Measure and Manage; under revision | Govern: questions 1, 2, 6, 8. Map: 3 to 5. Manage: 7 | | ISO/IEC 42001:2023 https://www.iso.org/standard/42001 | Voluntary; certifiable | An AI management system | The whole guide | Sources - FRC, Provision 29 Mythbuster: Preparing to report https://www.frc.org.uk/docs/9097/html/ , 29 January 2026, reproducing Provision 29 of the UK Corporate Governance Code 2024. - UK Government and NCSC, Cyber Governance Code of Practice https://www.gov.uk/government/publications/cyber-governance-code-of-practice/cyber-governance-code-of-practice , 8 April 2025. - ICO, agentic AI call for evidence https://ico.org.uk/about-the-ico/ico-and-stakeholder-consultations/2026/10/agentic-ai-call-for-evidence/ , open 8 October to 20 November 2026. - ICO, Tech Futures: agentic AI data protection and privacy risks https://ico.org.uk/about-the-ico/research-reports-impact-and-evaluation/research-and-reports/technology-and-innovation/tech-horizons-and-ico-tech-futures/ico-tech-futures-agentic-ai/data-protection-and-privacy-risks . - NIST, AI Risk Management Framework https://www.nist.gov/itl/ai-risk-management-framework , version 1.0, January 2023; revision announced, no date given checked 23 October 2026 . - UK General Data Protection Regulation https://www.legislation.gov.uk/eur/2016/679/contents , as amended, including Articles 22A to 22D and Article 33. - FCA, AI in financial services: good practice and areas for improvement https://www.fca.org.uk/publications/good-poor-practice/ai-financial-services , October 2026, and FSB, Sound Practices for Responsible Adoption of AI https://www.fsb.org/2026/10/sound-practices-for-responsible-adoption-of-artificial-intelligence-ai-final-report/ , 15 October 2026. - Regulation EU 2024/1689, the AI Act https://eur-lex.europa.eu/eli/reg/2024/1689/oj , as amended by Regulation EU 2026/1744, the Digital Omnibus on AI https://eur-lex.europa.eu/eli/reg/2026/1744/oj , in force from July 2026. Dates also tracked in our UK AI deadlines tracker https://reinvently.co.uk/tools/uk-ai-deadlines/ . - ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system https://www.iso.org/standard/42001 , December 2023. - UK Government, Cyber Security and Resilience Bill factsheet: incident reporting https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/incident-reporting , updated 30 June 2026. - Incident details from the Reinvently agent incident log https://reinvently.co.uk/tools/agent-incidents/ , each entry linked to its primary report: Replit https://www.theregister.com/2025/07/21/replit saastr vibe coding incident/ , EchoLeak https://thehackernews.com/2025/06/zero-click-ai-vulnerability-exposes.html , ForcedLeak https://noma.security/blog/forcedleak-agent-risks-exposed-in-salesforce-agentforce , Manus https://salt.security/blog/how-we-hijacked-an-ai-agent-with-a-single-email , PixelLeak https://www.glow.io/blogs/how-ai-agents-exposed-developer-screenshots-from-leading-tech-companies and Amazon Q Developer https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ . This is the first of five decision pieces for technology leaders. Get the next ones by email https://reinvently.co.uk/contact/ . ← All posts https://reinvently.co.uk/blog/ Editorial note, 23 October 2026: This guide is not legal advice. Provision 29 applies to companies reporting against the UK Corporate Governance Code on a comply-or-explain basis, and the Cyber Governance Code of Practice is voluntary. Incident summaries are drawn from our log, which records what primary sources reported; several were research demonstrations or were patched with no reported exploitation.