---
{
  "title": "Incident containment",
  "summary": "Limit the attacker’s access and the harm while preserving investigation options.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Limit harm while keeping options open

Incident containment reduces an adversary's ability to continue harmful activity. It can involve restricting an account, isolating a device, blocking a connection, removing an external sharing path, or temporarily disabling a vulnerable service. The best action depends on the evidence, ongoing impact, operational dependencies, and authority available.

Containment is not proof that the incident is over. An isolated laptop may still contain malicious software. A blocked domain does not remove a stolen credential. The team must distinguish the immediate interruption from later work to remove causes and restore trustworthy operation.

## Choose the boundary deliberately

In a fictional design company, endpoint monitoring reports that one workstation is accessing many shared documents unexpectedly. The responder considers isolating it from the network. That may prevent further access, but it could also interrupt the user's work, terminate connections useful to the investigation, and change what evidence remains available.

If the activity is ongoing and credible, limiting harm may take priority over a perfect capture. The decision should still identify the observed behavior, expected benefit, likely disruption, and person authorizing the action. Record the time so later investigators can separate response activity from adversary activity.

The team also checks whether the same account is active elsewhere. Device isolation alone might not stop cloud sessions or access from another endpoint. Conversely, disabling the account without controlling the compromised device could leave local access or other credentials exposed.

## Use the narrowest effective action

A temporary restriction on one identity may be less disruptive than shutting down a whole service, provided it actually blocks the harmful path. A broad action can be justified when the scope is uncertain and the potential harm is high. Avoid making narrowness an absolute rule at the expense of effectiveness.

Document exceptions and expiration or review times. Emergency firewall rules and temporary account restrictions often become forgotten configuration. Assign someone to assess whether the restriction remains necessary and whether the attacker has shifted to another path.

[[incident-playbooks]] can list approved options and prerequisites, but responders still need judgment. A playbook written for a single compromised mailbox may not fit a privileged identity used by several automated services.

## Check whether containment worked

Define an observable outcome before acting where possible. For the workstation case, look for cessation of the suspicious access, successful application of isolation, and evidence of related activity elsewhere. “The console accepted the command” does not always establish that the endpoint enforced it.

Practice with a tabletop decision: a suspicious process is active on a server supporting an essential service. Compare isolation, restricted network access, and service failover. Explain which evidence would change the choice. Continue with [[eradication-and-recovery]] once immediate harm is limited, preserving a clear record through [[incident-reporting]].

## Related concepts

- [[sessions-and-cookies]]
- [[persistence]]
- [[cloud-incident-response]]