Disconnect or Observe: The Containment Call Nobody Prepares For
The call comes in at 2am. The SOC has flagged lateral movement from a workstation in finance. The credential looks compromised. Four people are on the call and every one of them is waiting for someone to make a decision.
Do you disconnect the machine, or do you watch it?
This is the containment decision, and most incident response plans have a placeholder for it that reads something like "assess the situation and take appropriate containment measures." That is not guidance. It is a commitment to figure it out later, under pressure, while an attacker may be actively moving.
What Disconnecting Actually Does
The case for immediate containment is obvious. You stop the bleeding. Lateral movement through that asset ends. Exfiltration over that connection stops. The compromised workstation can no longer be used to pivot elsewhere.
What immediate disconnection also does: it tells the attacker you saw them.
A patient threat actor operating in your environment is watching for defensive reactions. If a workstation they have been pivoting through suddenly drops off the network, they know something changed. Depending on the attacker, that knowledge triggers one of two responses. They may go quiet and wait, using other footholds they established before you noticed the first one. Or they may accelerate, deploying ransomware or destructive tools they had staged for later, moving faster across systems they were already positioned on.
Neither outcome is what you wanted. One of them ends with encrypted drives by morning.
What Watching Actually Does
The case for observing before you act: you learn the actual scope of the compromise.
By the time your SOC flags activity from a finance workstation, that is almost certainly not the first thing the attacker touched. It is just the first thing your monitoring caught. They may have been present for weeks. Additional persistence mechanisms may already be in place. Other accounts may already be compromised. Systems you have not looked at yet may already be staged.
If you contain the detected asset immediately and call it done, you have stopped one visible thread of activity. The investigation ends at "workstation was compromised," which is a finding but not a picture of what actually happened. The attacker's other footholds stay quiet, the lateral movement they already completed stays in place, and your remediation is incomplete before you start it.
Watching, even for a controlled period, lets you see where they go next, what credentials they use, and what systems they are trying to reach. That is the information you need to understand the real scope, which is the information you need to actually fix it.
The Variables That Actually Matter
There is no universally correct answer. There are factors that shift the calculus.
What type of incident is this? Ransomware operators move fast. An active ransomware deployment is not a scenario where you observe to gather intelligence. The moment you have confidence that ransomware is staging or deploying, you contain immediately regardless of what you might learn by waiting. The cost of continued observation is encrypted production systems. For a patient intruder with no immediate destructive capability in play, the calculation is different.
Do you have real visibility into what you are watching? Observation only works if you can actually see what the attacker is doing. If your logging and monitoring are incomplete, you are just leaving the door open longer without learning anything. Know what you can actually observe before deciding that observation is worth the time.
Is active exfiltration happening now? If data is confirmed leaving your environment in real time, the calculation tilts toward containment regardless of investigative value. The cost of waiting is data that is already gone.
What other persistence do they have? If your investigation has already identified multiple footholds, compromised accounts on other systems, or active sessions elsewhere, containing one asset while the others remain active does not meaningfully stop anything. Broad containment needs to be coordinated, not incremental.
Forensic Preservation Before the Plug
This gets less attention than the strategic question but matters operationally. When you abruptly disconnect a system, volatile memory disappears: running processes, active network connections, encryption artifacts, credentials held in memory. All of it is gone the moment the NIC drops.
If you have the time and capability, capture memory before you pull the network connection. Disk imaging and log preservation follow. This does not apply to every incident, and in a fast-moving situation you may not have the luxury. But in organizations that do have the option and do not take it, the forensic investigation suffers for it. The organizations most likely to contain immediately are often also the ones most likely to make their own investigation harder.
Decide This Before You Need To
The worst time to have this conversation is at 2am with an active intrusion in progress and executives demanding to know why you have not done something yet.
Your incident response plan should include a written decision framework for containment, not a generic directive to "assess and act." Define the conditions under which you observe versus act. Specify who has the authority to authorize disconnecting a production system. Clarify what forensic steps need to happen before containment is executed. Name who needs to be notified and in what order.
That framework will not cover every possible scenario. Incidents are creative. But working through the logic in advance, without pressure, without an attacker listening, and without four people on a conference call staring at you, produces better decisions than improvising it for the first time in the dark.
Build the decision tree now. At 2am, you will be glad you did.