Extend the existing incident plan
An AI incident response plan should fit the organisation’s established incident process. Add the system-specific facts needed for AI workloads: owners, model and application versions, retrieval sources, delegated identities, available tools and records. A separate plan with no connection to security operations, change control or business continuity leaves important decisions unowned.
This page is a planning structure, not a completed policy or an assessment of your environment. Fill in real names, channels, permissions and constraints, then exercise the plan.
The operational record for each AI workload
| Plan field | What a usable entry contains |
|---|---|
| Service and business purpose | Application name, workflow, criticality and accountable owner |
| Dependency map | Provider, hosting, orchestration, sources, memory, tools and destinations |
| Authority | Who can pause a run, disable a connector, revoke access and approve restart |
| Evidence | Record types, retention, export permission, time source and collection owner |
| Escalation | Internal lead, suppliers, existing responders and out-of-band contact method |
| Continuity | Manual fallback, affected customers and consequences of containment |
| Recovery | Validation conditions, staged restart, observation window and acceptance owner |
Use observed impact for escalation
Record the observation, supporting evidence and what remains uncertain. A blocked injection attempt, a successful unauthorised tool action and confirmed external disclosure should not be collapsed into one category. Set severity using business impact, continuing activity, data sensitivity and ability to contain. Do not wait for a perfect forensic conclusion before escalating credible ongoing harm.
Prepare a decision log
For each important decision, record the time, decision maker, evidence considered, action approved, expected impact, result and follow-up. Include the choice to defer an action. If logs are incomplete or a provider cannot supply a record, note the limitation rather than substituting an assumption.
The evidence checklist identifies records; AI digital forensics explains how they support conclusions. Keep sensitive operational details in your controlled incident repository.
Define a restart gate
Verify the implicated permissions, source integrity and relevant configuration before reconnecting a workload. Check queued work and resulting system state. Test intended use and the identified failure condition in an authorised environment, assign unresolved risks and name the person who accepts restart. An absence of fresh alerts is one observation, not complete proof of recovery.
Maintain and exercise the plan
Review after a material tool, provider, permission or architecture change and after an incident or exercise. A tabletop exercise can expose dependencies while systems remain untouched. Agree review ownership and evidence of completed improvements. NIST SP 800-61 Rev. 3 provides the wider risk-management context.
Discuss your situation
Build an incident brief with non-sensitive context, or request a scope discussion. We confirm people, access, fees and availability before work begins.
