Containment, Eradication and Recovery for AI Incidents

Why This Topic Matters

AI systems fail in ways that traditional IT systems do not. A compromised database leaks records; a compromised AI model can quietly produce biased decisions, leak training data through its outputs, follow attacker-injected instructions, or degrade over time without any obvious alarm. For the ISACA Advanced in AI Security Management (AAISM) exam, the Containment, Eradication and Recovery phase of AI incident response is tested because it is where an AI security manager proves that governance has translated into operational capability. Knowing how to stop the damage, remove the cause, and safely restore trusted AI operations is a core competency of the AI Governance and Program Management domain.

This phase also matters for accountability. Regulators (for example under the EU AI Act), customers and boards increasingly expect organizations to demonstrate that AI incidents were handled in a controlled, documented and repeatable manner. Poor containment can turn a minor model issue into a regulatory breach, reputational crisis or safety event.

What It Is

Containment, Eradication and Recovery (often abbreviated CER) is the middle phase of the classic incident response lifecycle described in NIST SP 800-61: Preparation → Detection and Analysis → Containment, Eradication and Recovery → Post-Incident Activity. ISACA adapts this lifecycle to AI systems, recognizing that the "asset" under attack may be a model, a dataset, a prompt pipeline, an API, an agent, or the human processes around them.

Containment – Limiting the scope and impact of an AI incident so it does not spread or cause further harm. Examples: disabling a model endpoint, switching to a fallback or previous model version, restricting inputs, adding human review, throttling API access, or isolating a poisoned data pipeline.

Eradication – Removing the root cause of the incident. Examples: purging poisoned training data, retraining or rolling back a model, removing malicious prompts or jailbreak artefacts from memory/vector stores, revoking compromised credentials, patching vulnerable ML libraries, or removing a malicious plugin or tool from an agent.

Recovery – Restoring the AI system to normal, trusted operation and verifying that it is safe. Examples: redeploying a validated model, re-running evaluation and red-team tests, monitoring outputs more intensively for a defined period, re-enabling features gradually, and confirming performance, fairness and safety metrics are within thresholds.

How AI Incidents Differ From Traditional Incidents

Understanding these differences is essential for exam scenarios:

1. The "infection" may be in the data or weights, not the infrastructure. Rebuilding a server does nothing if the trained model itself has been poisoned. Eradication often means retraining from a trusted dataset snapshot or restoring a known-good model artefact.

2. Harm can be probabilistic and ongoing. A model producing subtly biased or hallucinated outputs may be harming users with every inference. Containment must consider halting or degrading the service even when there is no classic "breach".

3. Attack persistence can live in memory and context. For LLM and agentic systems, prompt injections can persist in conversation history, retrieval-augmented generation (RAG) stores, or shared documents. Eradication must address these non-traditional storage locations.

4. Rollback is a primary containment tool. Model and data versioning (MLOps/ML lineage) allows rapid reversion to a previous validated state, which is why ISACA emphasizes model registries and version control as preparation controls.

5. Recovery requires re-validation, not just restoration. A restored model must be re-evaluated for accuracy, robustness, bias and safety before it is fully trusted again.

6. Third-party dependency. Many AI systems rely on external foundation models, APIs or datasets. Containment may require coordinating with vendors, and eradication may be partially outside the organization's direct control, which must be governed through contracts and shared-responsibility models.

How It Works – Step by Step

Step 1: Confirm and classify the incident. Use the detection and analysis outputs to determine incident type (data poisoning, model theft, prompt injection, evasion/adversarial input, privacy leakage, model drift, unsafe output, supply chain compromise) and severity. Severity drives how aggressive containment must be.

Step 2: Choose a containment strategy. ISACA and NIST describe short-term and long-term containment. Short-term: immediately stop the bleeding (take the model offline, block an IP, disable a tool). Long-term: implement interim controls that allow partial operation while eradication proceeds (fallback model, human-in-the-loop review, stricter input filtering). The decision balances business impact, safety risk, evidence preservation and legal obligations.

Step 3: Preserve evidence. Before changes are made, capture model versions, prompts, logs, input/output samples, data snapshots and configuration. This supports root cause analysis, regulatory reporting and potential legal action. AI-specific evidence includes model hashes, training data lineage records and inference logs.

Step 4: Eradicate the root cause. Identify and remove the underlying issue, for example removing poisoned records and retraining, revoking leaked API keys, patching a vulnerable library, deleting malicious content from a vector database, or terminating a compromised agent's access to tools. Eradication must be verified; assuming the cause is gone is a classic exam distractor.

Step 5: Recover and validate. Restore from trusted artefacts, redeploy, and perform validation: functional testing, performance benchmarking, bias and fairness testing, adversarial/red-team testing, and safety evaluations. Use phased or canary rollouts with heightened monitoring. Define explicit acceptance criteria and who has authority to declare the system back in production.

Step 6: Communicate. Inform stakeholders, affected users, regulators and third parties as required by policy and law. Transparency about AI incidents is increasingly a regulatory expectation.

Step 7: Hand off to post-incident review. Lessons learned feed back into AI risk assessments, model cards, policies, training, monitoring thresholds and the incident response playbooks themselves.

Key Governance Elements

• AI-specific incident response plan and playbooks integrated with the enterprise IR plan.
• Defined roles: AI security manager, data scientists/ML engineers, legal, privacy, communications, business owners, and vendors.
• Model and data versioning enabling rollback and forensic comparison.
• Kill switches / circuit breakers and fallback modes designed in advance (a Preparation control that makes Containment possible).
• Criteria for decisions: when to take a model offline, when it is safe to restore, who approves.
• Metrics: time to contain, time to recover, recurrence rate, residual risk after recovery.
• Regulatory alignment: reporting obligations (e.g., EU AI Act serious incident reporting, data protection breach notification).

Common Scenario Patterns

Data poisoning discovered post-deployment: Contain by rolling back to the last known-good model; eradicate by identifying and removing poisoned records and hardening the data pipeline; recover by retraining, validating and redeploying with monitoring.

Prompt injection via RAG documents: Contain by disabling retrieval from the affected source or restricting the agent's tools; eradicate by removing malicious documents and adding content sanitization; recover by re-enabling retrieval with filtering and monitoring.

Model producing discriminatory outputs: Contain by introducing human review or suspending automated decisions; eradicate by diagnosing the bias source (data, features, drift) and correcting it; recover by re-validating fairness metrics before resuming automation.

Leaked model weights or API keys: Contain by revoking credentials and rate-limiting; eradicate by rotating secrets and closing the exposure path; recover by assessing intellectual-property and privacy impact and restoring service with strengthened access control.

Exam Tips: Answering Questions on Containment, Eradication and Recovery for AI Incidents

1. Identify the phase being asked about. If the question describes stopping ongoing harm, it is Containment. If it describes removing the cause (poisoned data, malicious prompt, vulnerable component), it is Eradication. If it describes restoring and verifying normal operation, it is Recovery. Many wrong answers are correct actions from the wrong phase.

2. Safety and harm reduction come first. When an AI system is actively causing harm (unsafe outputs, biased decisions, data leakage), the BEST first action is usually to contain – take the model offline, switch to fallback, or add human oversight – not to start root cause analysis or notify the public.

3. Remember evidence preservation. If an option involves immediately retraining or wiping a model before capturing versions and logs, it is usually wrong because it destroys forensic evidence.

4. Rollback to a known-good, validated version is the classic AI containment answer. This relies on model versioning and a model registry, so questions about "what enables rapid containment" often point to these preparation controls.

5. Eradication for AI means addressing data and model artefacts, not just infrastructure. If a scenario involves poisoning, the root cause is in the data; patching servers is a distractor.

6. Recovery is not complete until the model is re-validated. Look for answers that include re-testing for accuracy, robustness, bias and safety, and phased redeployment with enhanced monitoring. "Redeploy immediately" without validation is a trap.

7. Think like a manager, not a technician. AAISM is a management certification. When choices include both a technical fix and a governance action (defining criteria, assigning accountability, coordinating stakeholders, following the IR plan), the governance action is often the BEST answer, especially for "what should the AI security manager do FIRST/BEST" questions.

8. Balance business continuity with risk. Questions may test whether you know that long-term containment can allow degraded or supervised operation rather than a full shutdown, provided risk is acceptable and documented.

9. Third-party incidents still require your action. If a vendor's foundation model is compromised, the organization must still contain its own exposure (disable integration, switch providers, restrict use) and manage communication – "wait for the vendor" is rarely the best answer.

10. Watch for qualifier words such as FIRST, MOST important, BEST and PRIMARY. FIRST in a CER scenario typically favors containment or evidence preservation; MOST important for recovery typically favors validation and stakeholder approval before resuming operations.

11. Link to post-incident improvement. Options that feed lessons learned back into playbooks, risk registers, monitoring thresholds and training reflect ISACA's lifecycle mindset and are often correct in "what should happen after recovery" questions.

Summary

Containment, Eradication and Recovery for AI incidents applies the proven NIST incident response structure to the unique realities of AI: harm that can be probabilistic, root causes that live in data and model weights, persistence in prompts and retrieval stores, and recovery that demands re-validation of trust. For the AAISM exam, master the distinction between the three sub-phases, prioritize harm reduction and evidence preservation, remember that rollback and retraining are AI-specific tools, insist on validation before declaring recovery, and always frame your answer from the perspective of a governance-minded AI security manager.