INC-004 Incident Containment and Eradication
Description
Documented containment procedures exist for common incident types, including account compromise, malware, data exfiltration and denial of service. Containment actions are taken within defined timeframes based on severity classification. Eradication steps, including root cause removal, are completed before recovery begins. Actions taken are logged. An information spillage procedure identifies the information involved, alerts responders through a channel not associated with the spill, isolates the contaminated systems, removes the spilled information from them and identifies the systems it reached next. Personnel whose systems are under corrective action continue their assigned work through a stated route, and the controls applied to a person who saw information outside their authorisations are recorded.
Rationale
Speed and discipline in containment decide how far a breach spreads, and documented procedures prevent ad-hoc decisions that spread the incident or destroy evidence. Spillage is the case a generic exfiltration playbook handles badly. The information is inside the organisation and in the wrong place, the people who received it are colleagues rather than attackers, and alerting through the contaminated channel copies the spill to everyone reading it. Taking a team's systems out of service for corrective action stops their work as well, so the continuation route is part of the procedure rather than an afterthought.
Applicability (9 profiles)
Framework Mappings (12)
| SEF-07 | Incident Management and Response | full |
| SEF-07 | Incident Management and Response | full |
| HIPAA-164.308.a.6.ii | Response and Reporting | informative |
| 5.26 | Response to information security incidents | full |
| NIS2-CIR-3.5 | Incident Response | partial |
| IR-4 | Incident Handling | full |
| IR-9 | Information Spillage Response | full |
| IR-9(3) | Information Spillage Response | Post-spill Operations | full |
| IR-9(4) | Information Spillage Response | Exposure to Unauthorized Personnel | full |
| MG-2.4-003 | AI System Deactivation and Override Mechanisms | MG-2.4-003 | informative |
| CC7.4 | Responds to Identified Security Incidents | full |
| CC7.5 | Identifies, Develops, and Implements Activities to Recover from Identified Security Incidents | full |
Evidence (3)
Incident containment and eradication procedures documenting response steps for common incident types, containment timeframes, and eradication criteria.
Example: Incident Response Runbooks or IRP appendices for at least three common incident types (e.g., account compromise, ransomware/malware, data exfiltration), version-controlled, reviewed within the last 12 months
Test: Request containment and eradication runbooks for at least three incident types. Verify: (1) procedures are defined for each covered incident type; (2) containment steps are specific and actionable (not generic); (3) eradication criteria are defined (what constitutes root cause removal); (4) recovery may not begin until eradication is confirmed; (5) all actions are required to be logged.
Incident action log or containment timeline records showing documented actions taken during containment and eradication for actual incidents.
Example: Incident ticket or war-room log from the last significant incident, showing timestamped containment actions, responsible analyst, and confirmation of eradication steps completed before recovery began
Test: Request the incident action logs for the last two significant incidents. Verify: (1) containment actions are timestamped and attributed to a named analyst; (2) containment was initiated within the SLA defined for the incident's severity; (3) eradication steps are logged as complete before recovery actions were started; (4) logs are stored in the incident management system and are not modifiable by the responder.
Information spillage runbook and the record of its most recent use or exercise.
Example: Spillage runbook v3 and exercise record SPL-2026-02
Test: Request the spillage runbook and its most recent use or exercise record. Verify: (1) the runbook names the out-of-band alerting channel and that channel is reachable without the contaminated systems, (2) it states how affected personnel keep working while their systems are under corrective action, (3) it states the controls applied to a person who saw information outside their authorisations and who records them, (4) the most recent use or exercise shows each step completed with a timestamp and a named actor, (5) the step that identifies systems reached after the initial spill produced a result rather than being skipped.
Questions (2)
Do documented containment procedures exist for common incident types?
Containment procedures should be specific and actionable, not generic guidance. At minimum, runbooks should exist for account compromise, malware, and data exfiltration incident types.
Which incident types have documented containment and eradication runbooks?
Options run from the most commonly documented to the least. Account compromise, malware and exfiltration are the minimum. Spillage is handled badly by a generic exfiltration playbook: the data is inside the organisation and in the wrong place, the recipients are colleagues rather than attackers, and alerting through the contaminated channel copies the spill to everyone reading it. AI-specific runbooks are expected where AI systems run in production.