Skip to Content

CIM - Containment

June 4, 2026 by
CIM - Containment
Resilix, Hendrik Noben

In the previous post, we covered Identification: detecting that something is wrong, validating the threat, and understanding its scope. You've confirmed an incident is real. Now what? This is where Containment comes in. The goal is simple to state but difficult to execute: stop the bleeding without shutting down the entire business. 

Think back to our building analogy. You've discovered an intruder in your office complex. They've been seen on the third floor, and you suspect they may have accessed other floors as well. The question isn't whether to act. It's how to act in a way that limits damage while preserving your ability to continue operating.

Do you lock down the entire building, sending everyone home? Do you seal off just the third floor? Do you quietly increase security presence while you figure out exactly where the intruder has been? Each choice has consequences for business operations, for your investigation, and for how much additional damage the intruder can do while you decide.

This is the containment dilemma: moving too slowly lets the attacker dig deeper, but moving too aggressively can cause more disruption than the attack itself.

The Two Phases of Containment

Immediate actions vs. Lasting controls

Containment isn't a single action. It's two distinct phases, each with different goals.

Immediate containment is about stopping active damage right now. If an intruder is actively carrying files out of your building, your first priority is to stop them, even if that means locking doors that inconvenience employees. If a fire is spreading, you pull the alarm and close the fire doors, even though that disrupts normal movement through the building.

In cyber terms, this might mean disconnecting a compromised system from your network, disabling a user account that's being misused, or blocking communication to servers the attacker is using. These actions are urgent, imperfect, and often disruptive. The goal is to stop active harm, not to solve the entire problem.

Sustained containment is about preventing the same attack from spreading or recurring while you work on a permanent solution. Going back to the intruder analogy: once you've intercepted them on the third floor, you need to secure the other floors, check if any doors were left unlocked, and ensure they don't have accomplices elsewhere in the building. This takes longer and requires more information than your initial response.

The distinction matters because these phases require different decision-making. Immediate containment often can't wait for full executive approval. Sustained containment involves tradeoffs that leadership needs to weigh.


The Core Tradeoffs

What makes Containment decisions hard

Every containment decision involves balancing competing priorities. Understanding these tradeoffs is essential for making good decisions under pressure.

Speed vs. Thoroughness

The faster you act, the less time the attacker has to cause damage. But fast action with incomplete information risks missing parts of the compromise or causing unnecessary disruption.

Consider this scenario: your security team identifies that an attacker has accessed one employee's account. They can immediately disable that account, stopping any ongoing misuse. But what if the attacker has already used that access to compromise other accounts? Disabling one account gives a false sense of security while the attacker continues operating through others.

The practical answer is usually a staged approach. Take immediate action against known compromises while rapidly investigating whether the problem extends further. Accept that your first actions will be incomplete and plan for multiple rounds of containment as you learn more.

Security vs. Operations

Aggressive containment can disrupt business operations as much as the attack itself. Disconnecting an entire department from the network might stop an attacker, but it also stops the department from working. Resetting every password in the organization might eliminate compromised credentials, but it creates chaos for thousands of employees trying to do their jobs.

This is where executive judgment matters. The security team can tell you what containment options exist and their likely effectiveness. They can estimate how much attacker activity each option would stop. But the business impact of those options, whether a day of disruption is acceptable to prevent a week of compromise, is a leadership decision.

Evidence vs. Urgency

Taking aggressive containment action can destroy evidence your investigators need. Shutting down a compromised system might stop the attacker, but it might also erase the memory-resident evidence that shows what they did. This creates tension between the immediate need to limit damage and the longer-term need to understand the full scope of the breach.

In most incidents, limiting damage takes priority. However, if you anticipate legal action (either pursuing the attacker or defending against regulatory penalties), evidence preservation becomes more important. This is why legal counsel should be involved in containment decisions for significant incidents.

Visibility vs. Tipping Off

Some containment actions are visible to the attacker. If you reset a password they're using, they know you've detected them. If you block their communication channel, they know their access is compromised. Sophisticated attackers may have backup access methods they'll activate once they realize they've been discovered.

For serious intrusions, your team may recommend quieter containment measures that limit the attacker without obviously revealing detection. This requires more coordination and takes longer but may prevent the attacker from causing additional damage in response to being discovered.


Who Decides What

Authority & Escalation

Containment decisions happen under time pressure, but that doesn't mean they should happen without proper authority. The key is establishing clear decision rights before an incident occurs.

Pre-authorized actions

Your incident handling plan should specify containment actions that security staff can take immediately without additional approval. These are typically low-impact, high-confidence actions: disabling a user account that's clearly compromised, blocking communication to known malicious servers, isolating a single workstation.

Escalation triggers

Certain containment actions should require leadership approval because of their business impact: shutting down customer-facing systems, resetting credentials for large groups of users, disconnecting entire network segments, or taking actions that might affect business partners.

Decision criteria

Make the criteria explicit. Don't require approval for "significant" containment actions (too vague). Require approval for "actions affecting more than X users" or "actions taking any customer-facing system offline for more than Y minutes" (specific enough to apply under pressure).

Out-of-hours authority

Incidents don't respect business hours. Establish who has authority to make containment decisions at 3 AM on a Saturday, and ensure they're reachable. If your executive team can't be reached quickly, consider delegating emergency authority to senior security staff with post-incident review requirements.


Containment in Practice

What good looks like

Effective containment shares several characteristics regardless of the specific incident type.

Documented actions

Every containment action should be logged: what was done, when, by whom, and why. This creates an audit trail for post-incident review, supports any legal proceedings, and helps the team track what's been done versus what's still needed. A dedicated scribe role, as discussed in the People post, is valuable here.

Coordinated timing

When multiple containment actions are needed, coordinate their timing. Blocking an attacker's known access point while leaving other access routes open just teaches them which doors to use. If you're going to reset passwords, reset them all at once rather than giving the attacker time to adapt.

Communication loops

Keep relevant stakeholders informed of containment actions and their impact. Operations teams need to know what's being taken offline. Customer service needs to know what to tell clients experiencing problems. Leadership needs to understand the current state of containment and what decisions are pending.

Reassessment triggers

Initial containment is based on initial understanding, which is always incomplete. Build in explicit points to reassess: Have we discovered additional compromised systems? Is the attacker adapting to our containment measures? Are the business impacts of containment acceptable, or do we need to adjust?


The Human Element

Pressure and decision quality

Containment decisions happen in a high-pressure environment. Your team knows that every minute of delay potentially means more damage. There's natural pressure to "do something" even when the right action isn't clear.

Good incident managers recognize this pressure and build in safeguards:

Structured decision-making

Don't rely on gut instinct alone. Use a consistent framework for evaluating containment options: What does this action protect? What business impact does it cause? How confident are we it will work? What do we do if it doesn't?

Designated devil's advocate

In high-pressure situations, teams tend toward groupthink. Assign someone to explicitly challenge proposed containment actions. "What if the attacker has already moved beyond what we're containing? What are we missing?"

Permission to pause

Sometimes the right immediate action is to gather more information before acting. Create space for your team to say "We need five more minutes to understand this" without feeling they're failing. A brief pause that leads to better action beats rapid action that makes things worse.

Post-incident review

Knowing that decisions will be reviewed later, without blame but with honest assessment, helps teams make better decisions in the moment. If people fear punishment for imperfect containment decisions, they'll hesitate when speed matters.


What You Need Before Containment

Preparation that pays off

Effective containment depends on preparation done long before any incident occurs.

Technical capabilities

Can your IT team actually isolate systems quickly? Can they reset credentials across the organization on short notice? Can they block network traffic to specific destinations? These capabilities need to exist and be tested before you need them. Discovering during an incident that you lack basic containment capabilities is a governance failure.

Decision authority

As discussed above, who can authorize what containment actions? Is this documented? Does everyone involved know the chain of authority?

Communication channels

How will you coordinate containment actions? If your normal communication systems are compromised, do you have alternatives? Can you reach key decision-makers quickly at any hour?

Playbooks

For common incident types (ransomware, compromised credentials, data theft), pre-defined containment steps reduce decision time. These shouldn't be followed blindly, but having a starting point beats starting from scratch every time.

Relationships

If you may need external help for containment (specialized security firms, law enforcement, industry partners), establish those relationships beforehand. Negotiating contracts or building trust during an active incident wastes precious time.


Wrapping Up

Containment is where incident management becomes most visibly a leadership challenge. Technical teams can identify options, but the tradeoffs between security, operations, evidence, and visibility require executive judgment.

The goal is not to contain perfectly. In the fog of an active incident, perfect decisions are impossible. The goal is to make defensible decisions quickly, document them clearly, reassess as you learn more, and limit damage while preserving your ability to operate.

Immediate containment stops active bleeding. Sustained containment prevents the problem from spreading while you work toward a permanent solution. Both require preparation done long before the incident: technical capabilities, clear decision authority, communication channels, and practiced coordination.

In the next post of the Incident Management Roadmap, we'll move to Eradication: removing the attacker's presence from your environment entirely, so that containment measures can be lifted and you can begin true recovery.


Five Questions Every C-Level Executive Should Ask

1. If we discovered right now that an attacker was actively in our systems, could we disconnect them within the hour, and who would make that decision?

Speed matters in containment. Do we have the technical capability to isolate compromised systems quickly? Is the authority to act clearly assigned? Have we tested this capability outside of an actual emergency?

2. What's the most disruptive containment action we might need to take, and have we thought through its business impact in advance?

Some incidents require shutting down critical systems or resetting credentials for everyone. Have we estimated the cost of these actions? Do we know the threshold at which the incident justifies the disruption? Are we prepared to make that call quickly?

3. Do our incident response team members have pre-authorized containment actions they can take without waiting for executive approval? 

Waiting for authorization costs time. Low-impact containment actions should be pre-approved so the team can act immediately. Is this documented? Does the team know exactly what they can and cannot do on their own authority?

4. How would we contain a problem if our normal communication systems were compromised?

If an attacker is in our email, our messaging system, or our phones, how do we coordinate our response? Do we have backup communication channels? Does everyone know what they are and how to access them?

5. After an incident is contained, how do we decide when it's safe to return to normal operations?

→ Containment isn't the end. We need to remove the threat (Eradication) and return to business (Recovery). How do we know containment has been effective? What criteria do we use to move to the next phase? Who makes that call?

If these questions expose gaps in your preparation, that's valuable. Containment under pressure is not the time to discover that decision authority is unclear or technical capabilities are missing.


Let's Connect

Are you in need of assistance from our Incident Management Experts, or want to discuss how these technical foundations apply to your organization? Don't hesitate to fill out the contact form below!