Containment, eradication and recovery are the operational phases used to stop an incident, remove the threat, and restore affected systems. Containment limits spread, eradication removes malicious presence, and recovery brings services back safely. Together they form the core remediation stage of incident handling.
Expanded Definition
Containment, eradication and recovery are the remediation phases of incident handling that begin after detection and triage. Containment narrows the incident’s spread or impact, eradication removes the malicious artefact, foothold, or condition, and recovery restores business services while confirming the environment is safe to resume normal operation.
The term is often used as a single phrase, but each phase answers a different operational question. Containment is about limiting active harm, eradication is about removing what caused or sustained the incident, and recovery is about reintroducing systems with acceptable trust. A common boundary mistake is to treat restoration as the same thing as cleanup. In practice, systems can look “back online” before the underlying cause is fully removed, which creates relapse risk. For that reason, disciplined incident handling separates temporary stabilisation from full restoration.
In NHI, identity, and cloud environments, this sequence matters because compromised credentials, tokens, service accounts, or workloads can persist even when a visible workload is rebuilt. The phrase therefore covers both technical repair and trust reset, not just server restoration.
Examples and Use Cases
- A phishing-driven account compromise is contained by disabling the session and limiting further mailbox access while investigators assess scope.
- A ransomware event is contained by segmenting affected hosts and preserving evidence before any broad restoration begins.
- A compromised API key is eradicated by revoking the secret, rotating dependent credentials, and removing any backdoor access paths.
- A cloud workload incident is recovered by redeploying from a trusted baseline after confirming that images, tokens, and configuration have been cleansed.
- For autonomous or NHI-driven systems, recovery may require reissuing machine credentials and validating that delegated access has not survived the incident.
The practical tradeoff is speed versus assurance. Fast recovery reduces downtime, but overly aggressive restoration can reintroduce the same compromise if the root cause or persistence mechanism remains in place. When the incident involves shared identities or reusable tokens, the recovery window often becomes an access-control problem as much as an infrastructure problem.
Security Implications
If containment is too narrow or too slow, the incident can spread laterally, trigger further data exposure, or corrupt more systems before the response team regains control. If eradication is incomplete, dormant persistence, hidden scheduled tasks, malicious configuration, or stolen credentials can allow the threat to return after apparent cleanup. If recovery is rushed, organisations may restore services before integrity is confirmed, which can re-expose users and automate reinfection across dependent systems.
These phases also shape evidence preservation and decision quality. Overzealous cleanup can destroy logs, volatile artefacts, or timeline data needed to understand how the compromise happened. Conversely, waiting too long to recover can extend outage impact and create unnecessary operational drag. Practitioners should watch for repeated alerts after restoration, unexpected authentication failures, orphaned sessions, and configuration drift because these often indicate that the incident was contained superficially but not removed fully.
Containment, eradication and recovery therefore function as a control sequence: each step reduces a different kind of exposure, and weakness at any step can leave the organisation in a partially compromised state.
Domain and Governance Relevance
In cybersecurity governance, the phrase defines the operational core of incident response. It connects detection to restoration and makes clear that response is not complete when the first alert is acknowledged. Organisations need ownership for each phase because containment decisions may be made quickly, eradication may require specialist tooling or forensic support, and recovery usually depends on business tolerance for downtime and residual risk.
In identity-heavy environments, the governance question changes from “is the host clean?” to “is the trust relationship clean?” That distinction matters for privileged users, service accounts, machine identities, and API-integrated systems, where a compromised credential can survive long after the original endpoint is rebuilt. For NHI governance, the term highlights the need to treat secret revocation, token invalidation, and workload re-authentication as part of recovery rather than as optional follow-up tasks.
NHIMG treats this phrase as a reminder that operational restoration and trust restoration must both succeed before the incident can be considered closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.RP — Response Plan Execution | Directly covers executing incident response phases. |
| RS.MI — Incident Mitigation | Maps to limiting spread and removing active compromise. | |
| RC.RP — Recovery Plan Execution | Applies to restoring services and validating return to operation. | |
| Recommendation — Execute your containment, eradication, and recovery plan with clear decision gates and owner handoffs. Use RS.MI to isolate affected assets and remove malicious presence before restoring service. Apply RC.RP to restore systems from trusted sources and confirm they are safe before reopening access. | ||
| CIS Controls v8 | 17 — Incident Response Management | Defines operational incident handling from response through recovery. |
| Recommendation — Use Control 17 to coordinate response phases and preserve evidence through restoration. | ||
| MITRE ATT&CK | T1562 — Impair Defenses | Relevant where containment or eradication must address adversary defence suppression. |
| Recommendation — Map defence impairment activity to T1562 and remove the mechanisms that preserve attacker access. | ||
Related resources from NHI Mgmt Group
- What is the difference between containment and recovery in an incident response plan?
- What is the difference between ransomware containment and recovery planning?
- Who owns ransomware containment when IAM, PAM, and recovery teams are involved?
- What breaks when recovery planning is used instead of containment planning for cyberattacks?
