An AI incident response plan tells the board how to triage, contain, evidence and report AI failures before the first incident. It should cover data leakage, harmful outputs, model or retrieval drift, prompt injection, poisoning, ADM harm and statutory reporting routes.
Key takeaways
- A cyber incident plan is not enough on its own: NCSC says an incident plan should name contacts, escalation criteria, a process, regulatory guidance, playbooks and records, while the UK AI Cyber Security Code guide adds AI-specific threats such as poisoning, drift, adversarial attacks and jailbreaking (NCSC incident processes; UK AI Cyber Security Code implementation guide).
- The board should see the plan, not just hear that it exists: NCSC's board toolkit says board members should expect direct sight of incident plans, exercise reports and lessons learned (NCSC board response planning).
- Personal data leakage into AI tools belongs on the breach route: the ICO says notifiable personal data breaches must be reported without undue delay and, where feasible, within 72 hours of awareness, and all breaches must be recorded (ICO personal data breach guide).
- EU AI Act serious-incident reporting is scoped, not universal: it applies where the organisation is within the Act's operator scope, especially high-risk AI, and the Commission says Article 73 reporting becomes applicable from August 2026 (EU AI Act; European Commission draft Article 73 guidance).
- The evidence pack matters as much as the response: NCSC and DSIT both point to logging, documentation, decision records and post-incident learning as the material that later supports regulators, courts and internal improvement (NCSC incident processes; UK AI Cyber Security Code implementation guide).
What an AI incident response plan must cover
Start with scope. The plan should apply to sanctioned AI systems, embedded AI inside existing software, staff use of consumer tools, suppliers operating AI on your behalf, and any automated decision-making process that can materially affect a person. That is the practical extension of an AI policy and a shadow AI policy: the policy says what is allowed; the incident route says what happens when the boundary is crossed.
NCSC's incident management collection frames response as a planned capability covering people, process and technical evidence, not a document written during the event (NCSC incident management). For AI, add event classes that ordinary cyber playbooks often miss:
| AI incident class | Immediate containment | Evidence the board should ask for | Usual owner |
|---|---|---|---|
| Personal data entered into an unsanctioned AI tool | Stop further use, preserve the prompt and output, assess whether a personal data breach occurred | Tool, user, data category, recipient terms, risk assessment and ICO decision | DPO or data protection lead |
| Hallucinated or fabricated output sent externally | Correct the recipient record, pause similar output, check review controls | Output, source material, reviewer record, correction note | Service owner |
| Model, prompt or retrieval change causes harmful output | Roll back to a known good version, freeze the release, compare outputs | Change log, model or prompt version, test results, retrieval index snapshot | Product or system owner |
| Prompt injection, data poisoning or model tampering | Isolate the channel, revoke affected access, validate the model and retrieval store | Attack route, affected prompts, logs, dataset or index integrity checks | Security lead |
| Bias or automated decision-making harm | Suspend the decision route, move to human review, sample affected cases | Decision logic, affected cohort, reviewer notes, remediation record | Risk, compliance or accountable executive |
| Potential serious incident under the EU AI Act | Check EU scope, provider or deployer role and high-risk classification before reporting | System classification, causal-link assessment, incident timeline and authority contact | Legal and accountable AI owner |
The table is deliberately operational. A board cannot use "AI failure" as a category. It needs classes, containment choices, evidence and an owner.
Triage: what happened and who owns the decision
NCSC says incident triage should determine type and severity so the organisation knows how urgent the response is and who needs to be involved from the outset (NCSC incident processes). For AI, the severity test should ask four questions: what data went in, what decision or output came out, who saw or acted on it, and whether the system remains live.
The board should approve the decision rights in advance. Who can disable an AI feature out of hours? Who can require a supplier to preserve logs? Who decides whether to notify the ICO, an EU market surveillance authority, a sector regulator, customers or affected individuals? NCSC's CEO guidance treats a serious cyber event as a business continuity, communications, financial and legal issue, and recommends governance structures that bring senior decision-makers together during the incident (NCSC CEO incident guidance).
The practical triage record should be short enough to complete under pressure:
| Board decision | Test | Evidence |
|---|---|---|
| Severity | Has there been harm, rights impact, data exposure, service disruption or public reliance on wrong output? | Incident timeline, affected users, data classes, output samples |
| Containment | Should the model, connector, workflow, supplier access or decision route be paused? | Change log, access log, system dependency map |
| Notification | Is there a notifiable personal data breach, sector notification duty or EU AI Act route? | Legal assessment, causal-link note, reporting clock |
| Recovery | What is the known good state and how will it be verified before restart? | Previous model or prompt version, test pack, human sign-off |
| Learning | What control failed and who owns the correction? | Post-incident review, control owner, date for board follow-up |
If those fields cannot be completed, that is itself a governance finding. It usually means the organisation has allowed AI use without the evidence layer needed to govern it.
Contain the system without destroying the evidence
Containment should reduce harm without cleaning away the facts. NCSC says careful records of decisions made, actions taken and data captured are useful for post-incident reviews and especially where evidence may be presented to a regulator or court (NCSC incident processes). That matters for AI because a well-meaning rollback can erase the prompt version, retrieval index or model configuration that explains the incident.
The safe sequence is: preserve, pause, narrow, then recover. Preserve prompts, outputs, model or provider version, retrieval sources, user actions, supplier notices and decision logs. Pause the affected workflow, not every AI tool by default. Narrow access by revoking compromised connectors or supplier tokens. Recover only after the system has been checked against a known good state.
The UK AI Cyber Security Code implementation guide is explicit that AI systems need logging for security compliance, incident investigations and vulnerability remediation, and it warns against logging full prompts or responses unless anonymised or necessary for troubleshooting with data protection controls in place (UK AI Cyber Security Code implementation guide). That is the balance: enough evidence to investigate, not a new store of unnecessary personal data.
For externally visible mistakes, do not let communications run ahead of the evidence. NCSC's CEO guidance says crisis communications should be factual and clear, and should not misrepresent or downplay the incident in a way that creates later difficulty (NCSC CEO incident guidance). That applies directly to AI hallucinations, biased recommendations and wrong automated decisions: correct what the affected person saw, but keep the technical finding separate from the apology until the facts are known.
Regulatory routes: data breach and serious incident reporting
The first route is data protection. The ICO defines a personal data breach as a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data, including accidental and deliberate causes (ICO personal data breach guide). If personal data is pasted into an external AI tool without the right basis or controls, the response team should assess whether confidentiality, integrity or availability of personal data has been affected.
The ICO's clock is not optional. Where a breach is likely to result in a risk to people's rights and freedoms, the organisation must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it; where the risk is high, affected individuals must also be told without undue delay (ICO personal data breach guide). The same guidance says incomplete information can be provided in phases, but the breach must still be notified when the organisation becomes aware of it.
The second route is EU AI Act serious-incident reporting, but only where the Act applies. Article 2 covers providers placing AI systems or general-purpose AI models on the EU market, EU-based deployers, and third-country providers or deployers where the AI system's output is used in the Union (EU AI Act). UK-only organisations with no EU market or output route should not describe every AI incident as an EU AI Act reportable event; they should record the scope check.
Where Article 73 does apply, providers of high-risk AI systems placed on the Union market must report serious incidents to the relevant market surveillance authorities. The Act defines a serious incident as an AI incident or malfunction leading directly or indirectly to death or serious harm to health, serious and irreversible disruption of critical infrastructure, infringement of obligations under Union law intended to protect fundamental rights, or serious harm to property or the environment (EU AI Act). The Commission's draft Article 73 guidance says these reporting rules become applicable from August 2026 and provides a draft template for preparation (European Commission draft Article 73 guidance).
Framework mapping for board papers
An incident plan is easier to govern when it maps to frameworks the board already recognises. Use this as the board-paper appendix, not as a substitute for the plan.
| Framework or regulator | What it contributes | Evidence to keep |
|---|---|---|
| NCSC incident management | Plan, team roles, triage, categorisation, escalation, technical response, post-incident review and playbooks (NCSC incident processes) | Response plan, role list, severity matrix, incident log, review actions |
| NCSC board toolkit | Board sight of the plan, exercising, lessons learned and board accountability for incidents as the governing body (NCSC board response planning) | Exercise report, board minutes, risk-register update |
| ICO and UK GDPR | Breach recognition, 72-hour notification where required, individual notification for high-risk cases, record of all breaches (ICO personal data breach guide) | Breach assessment, notification decision, Article 33 record |
| EU AI Act | Scope check, high-risk system route, serious-incident definition and Article 73 report timing where applicable (EU AI Act) | EU scope note, system classification, causal-link assessment |
| NIST AI RMF | The AI RMF Core uses Govern, Map, Measure and Manage functions to organise AI risk activity (NIST AI RMF) | Incident mapped to governance owner, context, measurement and treatment |
| ISO/IEC 42001 | ISO describes ISO/IEC 42001 as an AI management-system standard for establishing, implementing, maintaining and continually improving an AIMS (ISO/IEC 42001) | Policy link, objective, control owner, corrective action and review cadence |
| UK AI Cyber Security Code | AI-specific operational controls for threats including prompt injection, poisoning, evasion, excessive agency and information disclosure (UK AI Cyber Security Code implementation guide) | Threat model, logs, rollback evidence, system validation |
This is also where the plan connects to the AI governance framework. The framework names the owner and cadence; the incident plan proves whether those controls worked when the organisation was under pressure.
Common mistakes and the next step
The first mistake is copying the cyber plan and changing the title. That misses model drift, retrieval failures, hallucinated output, biased recommendations, supplier model changes and staff use of consumer tools. The second is waiting for certainty before escalation. The ICO expects timely reporting where a breach is notifiable, and NCSC's incident guidance assumes decisions will be made with incomplete information during a serious event (ICO personal data breach guide; NCSC CEO incident guidance).
The third mistake is allowing the supplier to be the only investigator. Suppliers hold important technical evidence, but the board still needs its own record of the incident, decisions, notifications and customer impact. NCSC's board toolkit is clear that responsibility for incidents and data breaches sits with the organisation and the board is ultimately responsible as the governing body (NCSC board response planning).
The fourth mistake is treating zero incidents as success. NCSC tells boards to learn from incidents and exercises, and the ICO expects staff to know how to escalate suspected breaches and to record breaches even where notification is not required (NCSC board response planning; ICO personal data breach guide). If an organisation is using AI and has no near misses, no staff reports and no paused outputs, the likely finding is not safety. It is weak detection.
The board's next step is not a longer PDF. It is a short exercise using a real scenario: a staff member pastes tenant, employee or client data into an unsanctioned AI tool; a retrieval update sends fabricated advice externally; a scoring model produces a biased shortlist. Run the exercise, capture the missing evidence, then update the AI policy, shadow AI controls and risk register.
If you want a quick gap view before the exercise, the Board AI Scorecard gives a first-pass governance read-out. For an assessor-led route, the AI governance diagnostic tests your live AI use, policy evidence and incident readiness against the control set above.
Sources: NCSC incident management · NCSC incident response processes · NCSC CEO incident guidance · NCSC board response planning · ICO personal data breach guide · EU AI Act · European Commission draft Article 73 guidance · UK AI Cyber Security Code implementation guide · NIST AI RMF · ISO/IEC 42001
