AI incident response mini-playbook

This is a short playbook for the first hours of an AI-related incident. It sits alongside your normal incident plan. It will not cover every case, but it gives a team without a dedicated security function a clear order of operations.

Print it, fill in the contact boxes, and put a copy somewhere you can reach when email is down.

Not legal advice. If personal data may be involved, or you are in a regulated sector, take advice early, and check your reporting duties.

Incident lead: ______________ Deputy: ______________ Security contact (out of hours): ______________ Legal / data protection contact: ______________ Insurer helpline: ______________

What counts as an AI incident

Treat any of these as an incident, even if you are not sure yet:

• Confidential, personal or secret information was entered into an AI tool that is not approved for it.
• An AI agent or assistant did something it was not asked to do, or acted on instructions from content it read (prompt injection).
• An AI tool, plug-in, model, package or container you use was reported as compromised (a supply chain incident).
• API keys, tokens or credentials for an AI service were exposed, or there is unexplained usage or spend.
• An AI tool exposed one user's data to another.
• Someone used a deepfake or voice clone to impersonate a colleague, supplier or customer, for example to ask for a payment.
• AI output caused harm, such as a wrong decision, discrimination or a published error, and it needs a managed response.

1. Spot and report

• Anyone who notices something wrong tells the incident lead straight away. Staff are never blamed for reporting in good faith.
• Write down what was seen, by whom, and when. Use the box: time (24-hour, UK), what happened, which tool, which account, which data.
• Do not delete anything. Do not "try it again" to see what happens.

2. Triage in the first 30 minutes

• Name an incident lead, and a person to keep a written log of decisions and times.
• Decide the type: data exposure, agent misbehaviour, supply chain, credential exposure, impersonation or harmful output.
• Ask the key questions: What data or systems could be affected? Is it still happening? Could personal data be involved? Is money at risk right now?
• Set a severity (low, medium, high) and decide who else needs to know. When unsure, rate it higher and downgrade later.

3. Contain

Pick the actions that fit the type.

The LiteLLM compromise of 21 October 2026 is a useful example of the supply chain row. LiteLLM's own guidance was not to run Python or pip in an affected environment, to remove the malicious files, to rebuild using a pinned earlier version, to rotate every credential the environment could reach, and to check cloud audit logs. Microsoft's analysis of the incident recommends hash-pinned dependency lockfiles, image digests instead of floating tags, and restricted outbound traffic.

4. Preserve evidence

• Keep logs, conversation exports, screenshots, prompts, outputs, file lists and the time of each action. For agents, keep the record of inputs, outputs and tool calls.
• Record who did what and when. Do not alter the originals. Work on copies.
• If you may need to prove what happened later, write down how and when the evidence was captured.

5. Assess impact and duty to report

• What data was involved, how many people, how sensitive, and who could have seen it?
• Personal data: if there is a personal data breach, the ICO says you must report it within 72 hours of becoming aware, unless it is unlikely to result in a risk to people's rights and freedoms. You must record all breaches either way. Use the ICO's guidance. If the risk is high, you may also need to tell the affected individuals.
• Regulated sectors and contracts: check your regulator's rules, your contracts and your insurance policy for notification duties and deadlines. The Cyber Security and Resilience Bill, now in the House of Lords, would introduce incident reporting duties for more organisations if it becomes law. Track it in our tracker.
• Customers and suppliers: decide who needs to be told, and what you can accurately say.
• Fraud: report to your bank and to Report Fraud. In the UK, you can also report a cyber incident to the NCSC.

6. Eradicate and recover

• Remove the cause: malicious files, unauthorised connections, risky permissions, unapproved tools.
• Rotate credentials and tokens that may have been exposed. Rebuild systems from known good sources if integrity is in doubt.
• Restore normal service in stages. Watch logs closely for a period afterwards.
• Re-enable AI features only with tighter permissions and approvals than before.

7. Communicate

• Agree one source of truth and one spokesperson.
• Give staff short, factual updates. Avoid speculation.
• Tell customers or regulators only what you have confirmed. Correct earlier statements if they change.
• Keep a copy of every external statement.

8. Learn and improve

Within two weeks, hold a blameless review.

• What happened, in order, with times?
• What worked? What slowed us down?
• Which control would have prevented it or reduced the damage? (Approved tools, data rules, least privilege, logging, approvals, supplier terms.)
• Update the acceptable use policy, the checklist and this playbook.
• Record actions with owners and dates, and check they are done.
• Run a practice scenario at least once a year. For example: "an agent has emailed customer data to an unknown address. What do we do in the first hour?"

Decision log template