AI incident readiness
Readiness is planning and exercising, done before anything happens. That is the whole of what this page offers, and the distinction matters: the decisions that are cheap to make on a quiet Tuesday — who can switch off a model, what gets preserved, who is called — are the ones nobody can make well at two in the morning.
What your plan probably does not say about AI
Your existing plan almost certainly covers who declares an incident and who talks to customers, and almost certainly does not say who can switch off a model, what an agent did with its credentials, or which logs answer that question. The plan was written for systems that fail in familiar ways, and an AI incident is a different shape: the compromise may be a document rather than a payload, the actor may be your own system acting on someone else’s instructions, and the evidence may not exist at all.
The additions are specific rather than a rewrite: declaration criteria that recognize an AI incident as one; containment options that do not mean taking the product down; roles that include whoever owns the model and the retrieval corpus; communications wording for a failure mode customers will not have a mental model for; and evidence requirements that are impossible to satisfy retroactively.
Who can disable a model or an agent, and how fast
This is the first question the tabletop asks and it is rarely answered cleanly. The plan has to name, for each AI system: who has the authority to disable it; who has the technical ability, which is frequently a different person; how long it takes; what the graduated options are between fully on and fully off — revoke a tool credential, disable retrieval, force approval on every action, restrict to internal users; and what the business impact of each is, decided in advance rather than argued during the incident.
Agents need a further answer, because disabling an agent mid-run can leave work half done in systems that were partway through a change.
Runbooks
Three scenarios cover most of what actually happens. Each runbook is written to your systems, with the commands, consoles and contacts named.
| Scenario | What the runbook has to settle |
|---|---|
| Prompt-injection compromise | A model acted on instructions embedded in content the organization does not control. Establish which sessions were affected, what was retrieved and what was emitted; quarantine the poisoned source; decide whether the feature stays up. |
| Agent-driven destructive action | An agent took an irreversible action outside its mandate. Freeze the agent’s credentials, enumerate every action taken in the window, determine reversibility, and find the instruction that caused it. |
| Model-mediated data leakage | The system disclosed data to someone not entitled to it. Establish what was disclosed and to whom, whether it crossed a tenancy boundary, and assemble the record your counsel needs to assess obligations. |
Classification uses the OWASP Top 10 for LLM Applications 2025, so the incident is typed against a named failure mode rather than described from scratch under pressure. The management frame is NIST AI RMF 1.0 and its Generative AI Profile (NIST AI 600-1); the general security posture for generative AI is set out by Canada’s Centre for Cyber Security in ITSAP.00.041.
AI forensic readiness
Every other kind of incident has a substrate to work from. An AI interaction that was not logged leaves nothing: no packet capture shows what the model was told, no disk image shows what it retrieved, and the model itself remembers nothing. If the telemetry was not designed in beforehand, the reconstruction cannot be done at any price.
So readiness here means deciding, now, what must be retained and for how long: prompts with their assembled context, retrieval results with their source and permission labels, tool calls with arguments and results, outputs, model and configuration versions, and the correlation identifier that ties one interaction together. Retention has to outlast discovery, and prompts containing personal information need minimization and access control of their own — a log that creates a second privacy problem is not readiness.
Where that telemetry does not exist, the work begins in secure AI environment establishment; where it exists but nothing watches it, AI security monitoring and detection is the next step.
The evidence-preservation checklist
Written to be followed by whoever is on call, not by a specialist. It covers what to capture before anything is changed; the instruction to disable automated log rotation and retention expiry for the affected systems immediately; how to snapshot the retrieval corpus and the model configuration as they were; how to record the chain of custody; and the standing rule that containment actions are logged as they are taken, because the first thing an investigation has to establish is which changes were the attacker and which were the responders.
This engagement is forensic readiness, not forensic investigation: it establishes what must be retained and how evidence is preserved, before anything happens. Where an investigation is needed, it is delivered with appropriately licensed partners where the law requires it.
The tabletop
A facilitated exercise on one AI scenario, with the people who would really be in the room: the incident lead, the application owner, the platform or security engineer who would do the containment, communications, and your counsel where they would be involved. It runs in real time against the plan as written, and the facilitator’s job is to keep asking who does that, with what access, and how they know.
The output is a written findings and gap report: the decisions that could not be made because nobody had the authority, the evidence that turned out not to exist, the contacts that were wrong, and the containment step that would have taken four hours. Each gap gets an owner and a date. Teams that run incident response readiness more broadly usually fold this scenario into that programme; prompt injection incidents is the scenario most rehearse first, and the first 24 hours of an incident sets out the shape of the day.
Where this stops
Notification decisions are not ours to make. Whether an incident triggers a reporting obligation is a legal determination that rests with your counsel, and this work supports it by making sure the facts they need have been preserved and assembled. We work alongside them: the runbooks specify what facts to assemble and in what form, so that when the question is asked the answer is available rather than reconstructed.
If an incident is running right now, readiness work is the wrong call to make first: contact your incident response retainer, your insurer’s breach hotline and your counsel, in whatever order your policy specifies, and preserve rather than delete. Readiness is for the time before that call, and it is what makes that call shorter.
What you receive
- AI additions to your incident response plan, written into the plan you already have rather than delivered as a separate document nobody opens.
- Three runbooks, named to your systems, for prompt-injection compromise, agent-driven destructive action and model-mediated data leakage.
- A forensic readiness specification: what to retain, for how long, with what access control.
- An evidence-preservation checklist for whoever is on call.
- A tabletop findings and gap report, with an owner and a date against every gap.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
Investigation and forensic work is delivered with appropriately licensed partners where the law requires it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
What if we are in an incident right now?
If an incident is running right now, readiness work is the wrong call to make first: contact your incident response retainer, your insurer’s breach hotline and your counsel, in whatever order your policy specifies, and preserve rather than delete.
Can you decide whether we have to notify?
Notification decisions are not ours to make. Whether an incident triggers a reporting obligation is a legal determination that rests with your counsel, and this work supports it by making sure the facts they need have been preserved and assembled.
Do you do the forensic investigation?
This engagement is forensic readiness, not forensic investigation: it establishes what must be retained and how evidence is preserved, before anything happens. Where an investigation is needed, it is delivered with appropriately licensed partners where the law requires it.
How is this different from our existing incident response plan?
Your existing plan almost certainly covers who declares an incident and who talks to customers, and almost certainly does not say who can switch off a model, what an agent did with its credentials, or which logs answer that question.
Rehearse it while it is cheap
Describe the AI systems in production and what your current plan says about them. The reply says which runbooks would be written and what the tabletop would exercise.