← Build, buy and runFree decision tool · Build, buy and run

AI Incident Response Planner

Describe one AI system and answer eight questions about how ready you are. The result is a playbook for that system: what can go wrong, how severe each incident is, what to do in the first hour, day and week, who does it, and which notification clocks may already be running. No email required.

Listen to this briefing

The AI Incident Response Planner

0:00

AI incidents need their own playbook

Most incident plans I review were written for outages and cyber attacks. They assume the system either works or does not. An AI system can keep running while it gives the wrong answer to every customer who asks one question, follows instructions hidden in an email, or drifts until its scores no longer mean what the model risk committee approved.

Those failures need different detection, containment and evidence, and some of them start a regulatory clock before anyone has called them an incident. The MAS clock for a bank is one hour. This planner turns one system's profile into the playbook its owner would want on the desk when that hour starts.

Where the playbook starts

The system's profile sets the starting severity; your answers set readiness

Severity 4LowStaff only, with output that is easily corrected
Severity 3ModerateIt reaches customers, acts through tools, or reads personal data
Severity 2HighIt shapes decisions about individuals, touches sensitive data, or a critical service depends on it
Severity 1CriticalIts errors reach people outside the organisation and cannot be undone

The highest rung the profile meets sets the start. A confirmed incident moves up as soon as a higher trigger is met.

Readiness: Yes 2, Partly 1, No 0 per question, out of 100

No tested off switch, or no named owner, caps the result at Partly ready whatever the score.

Severity rules and readiness bands are my own calibration, recorded in the basis table below.

The clocks and references come from the published rules, checked on 25 October 2026. The severity triggers, the starting-severity rule and the readiness bands are my own calibration. The basis table below records the source of each rule.

0 of 8 readiness questions answered

Step 1 · The system

Describe the system

Answer for the system as it runs in production. If it serves several purposes, pick the riskiest.

Answers questions or drafts text from a model and, often, your own documents. A person acts on the output.

Only employees see or use the output.

Published material or internal information with no access restriction.

A wrong output or action is corrected at once and nobody outside the team is affected.

The model is called through a vendor API or runs inside a vendor product.

If it stops, the business carries on with some inconvenience.

Which of these apply? Tick all that apply
Step 2 · Readiness

How ready are you?

Answer "Yes" only if it is true today and someone has tested it. "Partly" covers plans that exist on paper only.

1. Off switch. Can a named person switch the system off, or fall back to a manual process, within minutes?

Yes means: The switch exists, the person knows where it is, and it has been tested in the last six months.

Not answered yet. The playbook needs an answer here.

2. Reconstruction logs. Could you reconstruct what the system did in a given hour: inputs, outputs, tool calls and model version?

Yes means: Inputs, outputs, retrieved sources, tool calls and model and prompt versions are logged and kept long enough to investigate.

Not answered yet. The playbook needs an answer here.

3. Named owner. Is one named person accountable for the system, with authority to take it offline?

Yes means: One individual, not a team, owns it and can order it offline without a further approval.

Not answered yet. The playbook needs an answer here.

4. Rollback. Can you return to the last known good model, prompt and configuration, and reverse what the system did?

Yes means: Previous versions are kept and can be redeployed, and there is a way to find and reverse affected records or decisions.

Not answered yet. The playbook needs an answer here.

5. Detection. Would you find out from your own monitoring before a customer, journalist or regulator tells you?

Yes means: Thresholds on error rate, drift, refusals, cost and complaints raise an alert to a named person.

Not answered yet. The playbook needs an answer here.

6. Communications plan. Is there an approved plan, with draft wording, for telling affected customers and staff?

Yes means: Holding statements and customer notices are drafted and approved, with a named spokesperson.

Not answered yet. The playbook needs an answer here.

7. Regulator route. Is it written down who decides whether an incident is notifiable, who files, and how?

Yes means: The decision owner, the filing route and the regulator contacts are documented and known to the on-call lead.

Not answered yet. The playbook needs an answer here.

8. Vendor terms. Does the vendor contract require notice of model changes and of incidents on their side, with a contact who answers?

Yes means: The contract or service terms give advance notice of model changes and prompt notice of vendor incidents, and the contact has been tested.

Not answered yet. The playbook needs an answer here.

Basis

Sources behind the playbook

Each rule in the playbook traces to a published framework, standard or regulation. Where the rule is my own calibration, the table says so.

Show the rules and their sources ▸
RuleSource
Response, recovery and communication plans are documented for identified AI risks, and incidents are communicated to affected partiesNIST AI Risk Management Framework 1.0, MANAGE 4, 4.1 and 4.3 Source →
A system that behaves outside its intended use can be superseded, disengaged or deactivatedNIST AI RMF 1.0, MANAGE 2.4 Source →
Contingency processes cover failures in third-party data or AI systemsNIST AI RMF 1.0, GOVERN 6.2 Source →
Incident response is part of risk management, organised under Govern, Detect, Respond and RecoverNIST SP 800-61 Rev. 3 (April 2025), a CSF 2.0 Community Profile Source →
A plan exists for communicating incidents to users, a channel exists for external reports, and incidents feed corrective actionISO/IEC 42001:2023 Annex A.8.3 and A.8.4; clause 10.2; A.6.2.6 and A.6.2.8 for monitoring and event logs Source →
The incident categories for generative systems and agentsOWASP Top 10 for LLM Applications 2025: LLM01 to LLM10 Source →
Banks notify MAS within 1 hour of discovering a relevant incident and send a root cause and impact analysis within 14 daysMAS Notice FSM-N05, paragraphs 7 and 8 (in force 10 May 2024); sibling FSM notices for other licensees Source →
Incident management practice for financial institutionsMAS Technology Risk Management Guidelines (January 2021) Source →
A notifiable data breach is reported to the PDPC within 3 calendar days of assessing it as notifiablePersonal Data Protection Act 2012, ss 26B to 26D Source →
A personal data breach is reported to the supervisory authority within 72 hours where feasibleGDPR, Articles 33 and 34 Source →
Providers of high-risk systems report serious incidents within 15, 10 or 2 days; deployers inform the provider immediatelyEU AI Act, Articles 73, 26(5) and 3(49) Source →
The severity triggers, the starting severity for each profile, the readiness scoring (yes 2, partly 1, no 0) and its bands (80 and above, 50 to 79, below 50)Practitioner calibration by Terence Kok. None of the sources prescribes them. Re-cut them to your own risk criteria and incident policy.

Annex A references are to ISO/IEC 42001:2023. The EU AI Act high-risk obligations, including Article 73, apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems, after the 2026 AI Omnibus amendment. MAS notices bind the institutions they are addressed to; check the notice for your licence type.

How to use it

Using the playbook

  1. One system per playbook. A customer service assistant and a credit model fail in different ways and start different clocks. Run the planner once for each system on your AI inventory that reaches customers or touches personal data.
  2. Fill the names before you file it. The PDF leaves a name, a deputy and a phone number blank for each role. A role with no name is the first thing that goes wrong at two in the morning.
  3. Rehearse the first hour. Pick the highest category, walk the first-hour steps with the people named, and time it. Most teams find the off switch or the logs take longer than they assumed.
  4. Re-run it after a change. A new model version, a new tool for an agent or a new market can add a category or a clock.
Related governance tools

To rate how much oversight an agent needs before it goes live, use the Agent Risk Assessment Matrix. To test whether your board could answer for technology incidents the way MAS expects, use the Technology Risk Board Pack. To check the management system around both, use the ISO 42001 AIMS Readiness Checklist.

Go deeper

Rehearsing an AI incident

The planner gives you a written playbook. Running a tabletop exercise on it with your risk, technology and business owners is work I do directly with clients.

Book a private session
Terence Kok
Before You Go

The questions that slow an AI incident down are rarely technical. Does this count as an incident at all? Who is allowed to switch it off? Are the logs still there? This planner makes you answer them while nothing is on fire. Fill in the names on the printed playbook, then walk the first hour with those people before you need to.

Terence Kok

Last updated 25 Oct 2026

More in Build, buy and run

Next in this group · DashboardModel Performance and Health DashboardIs our deployed model drifting, slowing down or failing?Open the dashboard →
← All 8 in Build, buy and run