5.1Incident Response and Business Continuity Planning
When an AI system fails or is attacked, the organization needs a rehearsed plan to detect, contain, report, recover and learn, with AI-specific triggers such as drift, harmful output, data leakage and prompt injection. Business continuity and disaster recovery keep the business running by rolling back to a known-good model or falling back to a manual process within agreed recovery times.
An AI incident response plan is the fire-drill manual for AI systems: who spots trouble, who decides, who fixes it and who tells the regulator. NIST's current guide no longer treats response as a separate four-step loop. It spreads response across the six functions of the Cybersecurity Framework (CSF) 2.0, and lessons learned flow back in all the time.
diagram
NIST SP 800-61r3 treats Govern, Identify and Protect as preparation and Detect, Respond and Recover as incident response. Lessons learned go to the Improvement Category (ID.IM) and feed back into every Function.
Key points
NIST Special Publication (SP) 800-61 Revision 3, published April 2025, is a Cybersecurity Framework (CSF) 2.0 Community Profile for incident response and supersedes Revision 2 from 2012.
In its model, Govern, Identify and Protect form the preparation layer, while Detect, Respond and Recover form incident response itself.
Lessons learned feed the Improvement Category (ID.IM) of the Identify Function at any time, instead of waiting for a final post-incident phase.
The retired Revision 2 phases (Preparation, Detection and Analysis, Containment, Eradication and Recovery, Post-Incident Activity) map onto these six Functions.
A response policy covers management commitment, purpose, scope, definitions, roles and authorities (such as who may shut down assets), prioritization guidelines and performance measures.
ADG (Adopt, Defend, Govern) Minimum Control MC-9 requires AI-specific incident response procedures with replayable evidence capture, a documented playbook and at least one tabletop exercise a year.
ADG maps MC-9 to EU AI Act Article 73, the NIST AI Risk Management Framework (AI RMF) MANAGE function and ISO/IEC 42001 clause 10.2 on nonconformity and corrective action.
Exam tip
Asked which NIST document now frames incident response around CSF 2.0? Pick SP 800-61r3; the old four-phase life cycle is the distractor. In ADG the incident control is MC-9, not MC-8 (runtime monitoring).
AI systems fail in ways classic IT does not. A model can quietly get worse as the world changes, say something harmful, leak private data it memorized, or obey hidden instructions planted in a web page. Naming these incident types in advance lets the team recognize them fast and route each one to the right playbook.
diagram
The ADG harm taxonomy sorts AI failure modes into four classes. Runtime monitoring under MC-8 is what usually surfaces them as incidents.
Key points
The Organisation for Economic Co-operation and Development (OECD) defines an AI incident as an event where an AI system's development, use or malfunction directly or indirectly leads to harm.
OECD harms are injury to health, disruption of critical infrastructure, human rights or legal violations, and harm to property, communities or the environment.
An OECD AI hazard is an event that could plausibly lead to an AI incident, so it is potential harm rather than actual harm.
Model drift is an Operational harm in the ADG (Adopt, Defend, Govern) taxonomy, and the NIST AI Risk Management Framework notes data, model or concept drift can trigger corrective maintenance.
Prompt injection (OWASP LLM01:2026) is input that alters a large language model's behavior in unintended ways; indirect injection hides the instructions in external content such as websites or files.
Data leakage maps to OWASP LLM02:2026 Sensitive Information Disclosure, and harmful output includes misinformation (LLM07:2026) and unsafe content the ADG Safety Layer must block before impact.
ADG Minimum Control MC-8 monitors production for abuse, drift, data leakage, unsafe actions, bias emergence and configuration drift, the usual triggers for an AI incident.
Exam tip
Actual harm makes an event an AI incident; harm that could plausibly occur makes it an AI hazard. Expect a distractor that treats every drift alert as a reportable serious incident.
Under the EU AI Act, a provider of a high-risk AI system starts a legal clock once it learns of a serious incident, much like a carmaker that must report a dangerous defect. The worse the harm, the shorter the clock. A rough first report is allowed so the deadline is never missed.
diagram
Article 73 picks the deadline by severity: 10 days after a death, 2 days for a widespread infringement or critical infrastructure disruption, and 15 days otherwise. Reporting starts immediately once a causal link is likely.
Key points
Article 3(49): a serious incident leads to death or serious health harm, irreversible critical infrastructure disruption, a breach of fundamental-rights law, or serious harm to property or the environment.
Providers report to the market surveillance authority where it occurred, immediately once a causal link or its reasonable likelihood is established, and within 15 days of becoming aware.
Shorter limits apply: no later than 10 days if a person died, and no later than 2 days for a widespread infringement or a serious critical infrastructure disruption.
An incomplete initial report may be followed by a complete one, and the provider must not alter the system in ways that affect cause analysis before informing the authorities.
Under Article 26(5), a deployer that identifies a serious incident informs the provider first, then the importer or distributor and the market surveillance authorities.
Providers of general-purpose AI models with systemic risk report serious incidents to the AI Office without undue delay under Article 55(1)(c), applicable since 2 August 2025.
The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved high-risk obligations to 2 December 2027 (Annex III) and 2 August 2028 (Annex I), and Article 73 duties follow that timing.
Exam tip
Memorize the clock as 15, 10, 2: general case, death, then widespread infringement or critical infrastructure. High-risk reports normally go to the national market surveillance authority; general-purpose AI models with systemic risk report to the AI Office.
Running the response means triage, investigate, contain, fix and restore, in roughly that order. For AI, containment often means switching off a tool, blocking a prompt pattern or rolling back to the last good model. Evidence means saving the prompts, retrieved context and tool calls so the event can be replayed later.
diagram
Response flows from triage through analysis and mitigation to recovery, using the CSF 2.0 Respond and Recover categories. Evidence is preserved before anything is changed.
Key points
Cybersecurity Framework (CSF) 2.0 Incident Management (RS.MA) executes the plan once an incident is declared, triages and validates reports, categorizes and prioritizes, and escalates as needed.
Incident Analysis (RS.AN) finds what happened and the root cause, estimates magnitude, and preserves the integrity and provenance of incident data and investigation records.
Incident Mitigation (RS.MI) contains the incident to stop its expansion, then eradicates its effects, such as removing persistence mechanisms and entry points.
The ADG (Adopt, Defend, Govern) AI Incident Evidence Pack is the forensic capture package, and agentic hardening calls for replay of prompts, retrieved context, policy decisions and tool calls.
ADG containment levers include kill switches, human override and emergency stop pathways, and circuit breakers at agent-to-agent boundaries.
Under EU AI Act Article 26(5), a deployer that believes a high-risk system presents a risk informs the provider or distributor and the market surveillance authority and suspends use.
Under Article 73(6), the provider must not alter the AI system in a way that could affect evaluation of the incident's causes before informing the competent authorities.
Exam tip
Contain while preserving evidence: capture prompts, context and logs, then disable the tool or roll back. Retraining the model mid-investigation is a trap answer because it changes the system before the cause is known.
Seal and hash an AI incident evidence pack (example paths) · bash
An AI incident touches many people at once: leadership, legal, privacy, the vendor, regulators, customers and sometimes the press. Good communication means deciding ahead of time who tells what to whom and when, with one approved voice for the public. Missing a regulator deadline can turn a contained incident into a compliance failure.
diagram
A deployer reports a serious incident to the provider first, and the provider reports to the market surveillance authority. A personal data breach runs on a separate GDPR clock, and only a named spokesperson speaks to the public.
Key points
NIST SP 800-61r3 lists leadership, incident handlers, technology professionals, legal, public affairs, human resources, physical security and asset owners as response roles.
Cybersecurity Framework (CSF) 2.0 Incident Response Reporting and Communication (RS.CO) notifies internal and external stakeholders and shares information with designated parties.
Incident Recovery Communication (RC.CO) reports restoration progress to designated stakeholders and shares public updates using approved methods and messaging.
NIST SP 800-34 says a crisis communications plan typically names the only individuals authorized to answer questions from the public.
For personal data breaches, General Data Protection Regulation (GDPR) Article 33 requires notifying the supervisory authority within 72 hours where feasible; a pending Digital Omnibus proposal would make it 96.
The NIST AI Risk Management Framework (AI RMF) MANAGE 4.3 expects incidents and errors to be communicated to relevant AI actors, including affected communities.
ISO/IEC 42001 Annex A control A.8.4 covers communication of incidents, and ADG (Adopt, Defend, Govern) vendor due diligence requires contract clauses on incident notification.
Exam tip
An AI incident with personal data runs parallel clocks: GDPR 72 hours to the data protection authority and the AI Act Article 73 report to the market surveillance authority. The governance answer coordinates both through one approved communication plan.
After the fire is out, the team reviews what happened, why, what worked and what must change. In AI, the fixes often land in data, prompts, guardrails or the model itself, and each fix is retested before it ships. The lessons then update policies, risk records and the next round of testing.
diagram
Post-incident work closes the loop: document, fix the cause, retest, get governance sign-off, then update the plans that will handle the next incident.
Key points
NIST SP 800-61r3 places lessons learned in the Improvement Category (ID.IM), often through a lessons-learned meeting as recovery concludes, especially after a major incident.
Ending recovery (RC.RP-06) means declaring it over against criteria and completing documentation, including an after-action report on the incident, actions taken and lessons learned.
ISO/IEC 42001 clause 10.2 requires reacting to a nonconformity, evaluating and removing its causes, reviewing corrective action effectiveness and updating the management system.
Under EU AI Act Article 73(6), the provider investigates each serious incident, including a risk assessment and corrective action, in cooperation with the authorities.
ADG (Adopt, Defend, Govern) process step 7 is post-incident remediation with retest and governance review, owned by the Defend pillar.
In the ADG Retire and Learn stage, Defend preserves evidence and validates closure, while Govern updates policy, records and accountability decisions and feeds lessons into sourcing.
NIST AI 600-1 suggests after-action reviews of generative AI incident response and disclosure to find gaps and update those processes.
Exam tip
A lesson is not learned until the fix is retested and the plan or policy is updated. Answers that stop at writing the report miss the corrective action loop.
Business continuity asks a blunt question: if the AI stops working or cannot be trusted, how does the business keep serving people? The answer is a pre-approved fallback, such as the previous model version, a simple rules-based tool, or trained staff doing the task by hand. Like a pilot ready to fly without autopilot, the organization practices the manual path before it needs it.
diagram
When an AI system drifts outside tolerance, roll back to the last approved version if it is healthy. Otherwise stop it in a safe state and switch to the manual or rules-based fallback.
Key points
Per NIST SP 800-34, a Business Continuity Plan (BCP) sustains mission and business processes during and after a significant disruption, while system plans recover the technology.
The Business Impact Analysis (BIA) sets Maximum Tolerable Downtime (MTD), the total outage time the system owner will accept for a business process, including all impacts.
NIST AI Risk Management Framework (AI RMF) MANAGE 2.1 weighs viable non-AI alternative systems, approaches or methods, the basis for a manual fallback.
AI RMF MANAGE 2.4 requires mechanisms and assigned responsibilities to supersede, disengage or deactivate AI systems whose outcomes are inconsistent with intended use.
EU AI Act Article 15(4) allows robustness through technical redundancy, including backup or fail-safe plans, and Article 14(4)(e) requires a stop button that halts in a safe state.
ADG (Adopt, Defend, Govern) vendor due diligence requires defined rollback and exit strategies for vendor AI dependencies (see 3.2).
NIST SP 800-61r3 recommends synchronizing business continuity plans with incident response plans, and ISO 22301 specifies a business continuity management system.
Exam tip
The continuity answer keeps the business process running, not the model. If no trustworthy model version is available, choose the pre-approved manual or rules-based fallback over continuing to run a model that cannot be trusted.
Disaster recovery is the technical side of getting back up: restoring systems, data and, for AI, the exact model, prompts and knowledge index last known to be good. Two numbers drive the design. The recovery time objective says how fast service must return, and the recovery point objective says how much recent data you can afford to lose.
What it measures
AI recovery example
Recovery Point Objective (RPO)
Tolerable data loss
Point in time data returns to
Not part of MTD
Last good model, prompts and index
Feedback after that snapshot is lost
Recovery Time Objective (RTO)
Max time a resource can be down
Must be shorter than MTD
Time to roll back or fail over
Includes verifying hashes first
RPO looks backward at how much data can be lost, and RTO looks forward at how fast service must return. RTO must fit inside the Maximum Tolerable Downtime from the business impact analysis.
Key points
Recovery Time Objective (RTO) is the maximum time a system resource can stay unavailable before unacceptable impact, and it must be shorter than the Maximum Tolerable Downtime (MTD).
Recovery Point Objective (RPO) is the point in time to which data can be recovered after an outage; it reflects tolerable data loss and is not part of MTD.
In NIST SP 800-34, a Disaster Recovery Plan (DRP) relocates systems to an alternate location and activates Information System Contingency Plans (ISCPs) that recover single systems.
For AI, the recovery set includes approved model versions, prompts and configurations under change control, and vector stores, which ADG (Adopt, Defend, Govern) says need backup and recovery.
Cybersecurity Framework (CSF) 2.0 RC.RP-03 requires verifying backup integrity before restoring, which for AI means checking model and data hashes for tampering or poisoning.
ADG requires release through a controlled change process with rollback readiness, and the MC-5 change log with approval records shows which version is safe to roll back to.
A recovery fix beyond what the initial conformity assessment foresaw can be a substantial modification, which needs a new conformity assessment under EU AI Act Article 43(4).
Exam tip
RTO is time to restore service; RPO is how much data you can lose. If the question stresses that the restored model must not be poisoned, the answer is integrity-verified backups (RC.RP-03), not just a faster restore.
Verify and restore a known-good AI release (example names) · bash
git tag -v prompts-v12 # verify the signed release tag
git checkout prompts-v12
sha256sum -c models/claims-model-v3.sha256
cp models/claims-model-v3.onnx /srv/serving/current.onnx
A plan nobody has practiced is a guess. Organizations test the technology, train the people and run exercises that walk through realistic AI failures, from a discussion around a table to a live failover. Each exercise produces findings that make the plan and the controls better.
Discussion based
Operations based
Exercise type
Tabletop exercise
Facilitator walks a scenario
No equipment deployed
Functional exercise
Duties run in a simulation
Full-scale adds failover
Where SP 800-34 uses it
Low-impact systems
Functional for moderate impact
Full-scale for high impact
Tabletops test decisions and roles through discussion, while functional and full-scale exercises test that people and systems can actually recover. NIST SP 800-34 scales the exercise to the system impact level.
Key points
NIST SP 800-34 step 6 is plan testing, training and exercises: testing validates recovery capabilities, training prepares personnel and exercising the plan finds gaps.
NIST SP 800-84 is the guide to test, training and exercise (TT&E) programs for IT plans and capabilities.
Tabletop exercises are discussion-based with no equipment deployed, while functional exercises perform duties in a simulated operational environment.
SP 800-34 expects a tabletop for low-impact systems, a functional exercise for moderate-impact, and a full-scale functional exercise with failover for high-impact systems.
ADG (Adopt, Defend, Govern) MC-9 evidence includes at least one tabletop exercise per year on the AI incident response playbook.
Cybersecurity Framework (CSF) 2.0 ID.IM-02 identifies improvements from security tests and exercises, including those run with suppliers and other third parties.
ADG outcome metrics include mean time to detect (MTTD) and mean time to contain (MTTC) AI-specific incidents, which show whether practice is paying off.
Exam tip
Match the exercise to the purpose: a tabletop validates roles and decisions cheaply, a functional or full-scale exercise proves recovery actually works. For a high-impact AI system, a tabletop alone is not enough.