# 5.3 Containment and Immediate Risk Reduction

# Goals

Containment is the first set of actions taken to stop an incident from getting worse.

The goal is not to fully fix everything yet. The goal is to reduce immediate risk, prevent further damage, preserve evidence, and create enough stability for proper investigation and recovery.

Good containment is fast, but controlled.

Poor containment can make the situation worse. Wiping a device too early may destroy evidence. Resetting every password without understanding the affected accounts may alert an attacker and create confusion. Restoring from backup before the cause is contained may reintroduce the same compromise. Disconnecting systems without understanding business dependencies may cause avoidable disruption.

This section defines how the company takes immediate action without losing control of the response.

# Step 1: Confirm Who Is Authorizing Containment

Before taking major action, confirm who has authority to approve containment decisions.

This may be the incident response lead, executive sponsor, IT lead, MSP lead, or another assigned role.

Containment actions may affect business operations. Disabling accounts, isolating servers, suspending vendor access, blocking email, shutting down websites, or disconnecting systems may interrupt work. The company should know who is allowed to make those decisions.

Why this matters:

Containment often requires fast judgment. Clear authority prevents delay, confusion, and conflicting instructions.

# Step 2: Preserve the Current Facts Before Making Changes

Before making major changes, record what is known.

Capture affected users, devices, systems, alerts, timestamps, screenshots, suspicious emails, file names, URLs, IP addresses, login activity, mailbox rules, cloud sharing links, admin changes, and actions already taken.

If immediate containment is needed, act quickly, but record the action and time.

Why this matters:

Containment changes the environment. If the company does not record the starting point, it may lose the ability to understand how the incident happened, what was affected, and whether the attacker still has access.

# Step 3: Decide Whether the Incident Is Active

Determine whether suspicious activity is still happening.

Look for active login sessions, ongoing file changes, new mailbox rules, data downloads, VPN sessions, ransomware-like encryption, endpoint alerts, backup deletion activity, public sharing links, website changes, or active vendor access.

If the incident appears active, containment should move faster.

Why this matters:

An active incident requires immediate interruption. A past incident may allow more careful evidence collection before containment.

# Step 4: Contain Compromised Accounts First

If an account may be compromised, reduce account risk quickly.

Common actions include:

• Revoking active sessions
• Resetting passwords
• Requiring MFA re-registration
• Disabling the account temporarily
• Removing suspicious MFA methods
• Removing unauthorized forwarding rules
• Removing suspicious inbox rules
• Reviewing delegated access
• Removing unauthorized app approvals
• Checking recent privilege changes.

Apply this first to high-risk accounts such as executives, finance, HR, IT administrators, payroll users, cloud admins, domain registrar admins, DNS admins, backup admins, and vendor accounts.

Why this matters:

Stolen accounts are often used to move deeper into systems, read email, change rules, approve fraud, access files, create new accounts, or hide activity.

# Step 5: Contain Email and Business Email Compromise

If the incident involves email, contain the mailbox and related messages.

Common actions include:

• Disabling suspicious mailbox rules
• Removing forwarding
• Revoking sessions
• Resetting credentials
• Blocking malicious senders or domains
• Searching for similar messages across mailboxes
• Removing malicious emails from inboxes where possible
• Checking sent mail
• Checking deleted mail
• Reviewing mailbox delegation
• Checking whether finance or customer communications were affected

For invoice fraud or bank-detail changes, pause the payment process until the request is verified through a separate trusted channel.

Why this matters:

A compromised mailbox can be used to read private messages, monitor finance conversations, change payment details, impersonate staff, and spread attacks internally or externally.

# Step 6: Isolate Affected Devices and Servers

If a device or server may be infected, isolate it from the network where possible.

This may mean using an EDR isolation feature, disconnecting Wi-Fi, unplugging the network cable, moving the device to a quarantine network, blocking it at the firewall, disabling VPN access, or shutting down access to shared resources.

Do not wipe or rebuild the device until evidence needs are considered.

However:

• If ransomware is actively spreading, prioritize stopping spread over perfect evidence collection.

Why this matters:

Infected devices may continue communicating with an attacker, spreading malware, encrypting shared files, stealing credentials, or attacking other systems.

# Step 7: Contain Ransomware or Mass File Change Activity

If there are signs of ransomware, act immediately.

Common actions include:

• Isolating affected devices
• Disabling compromised accounts
• Disconnecting affected file shares
• Pausing synchronization to cloud drives where appropriate
• Protecting backups
• Blocking known malicious indicators
• Disabling suspicious remote access sessions
• Stopping unauthorized encryption or deletion activity

Do not begin broad restoration until the active cause is contained.

Why this matters:

Ransomware can spread quickly and may target backups, file shares, identity systems, virtualization platforms, and management tools. Early containment can determine whether the company loses one device, one file share, or the wider environment.

# Step 8: Stop Public Data Exposure

If data is exposed publicly, remove or restrict the exposure.

Common actions include:

• Disabling public links
• Changing file permissions
• Removing guest access
• Disabling anonymous sharing
• Restricting cloud storage
• Removing exposed files from websites
• Disabling exposed buckets
• Taking down exposed repositories
• Rotating exposed secrets
• Checking whether data was downloaded

Do not only remove the link. Record what was exposed, when it was exposed, who could access it, and whether access logs are available.

Why this matters:

Public exposure can quickly become a legal, contractual, insurance, customer, or regulatory matter. The company needs to stop exposure and understand the possible impact.

# Step 9: Contain Remote Access and Network Exposure

If the incident involves VPN, RDP, SSH, firewall rules, remote support tools, or public exposure, close the unsafe access path.

Common actions include:

• Disabling suspicious VPN sessions
• Disabling old vendor accounts
• Closing public RDP or SSH
• Removing unnecessary port forwards
• Restricting access to trusted IPs
• Disabling exposed admin panels
• Removing broad firewall rules
• Suspending remote support tools
• Requiring MFA before access is restored.

If a firewall, VPN, or remote access appliance may be compromised, involve qualified technical support before making broad changes.

Why this matters:

Remote access paths are often used for entry, persistence, and lateral movement. Leaving the access path open allows the incident to continue.

# Step 10: Protect Backups and Recovery Systems

During containment, check backup systems immediately.

Common actions include:

• Confirming backup jobs are still running
• Checking whether backups were deleted or encrypted
• Restricting backup admin access
• Disabling suspicious backup accounts
• Preserving immutable or offline backup copies
• Pausing risky backup synchronization where needed
• Protecting backup credentials

Do not connect clean backup storage to an infected environment.

Do not restore into the same compromised path without understanding the cause.

Why this matters:

Backups are the recovery safety net. Attackers often try to delete, encrypt, or corrupt backups before causing larger disruption.

# Step 11: Block Known Malicious Indicators Carefully

Block known malicious indicators when doing so helps reduce risk.

Indicators may include malicious domains, URLs, IP addresses, sender addresses, file hashes, command-and-control destinations, suspicious OAuth apps, known malware filenames, and malicious browser extensions.

Use email filtering, DNS filtering, firewall rules, endpoint tools, web filtering, cloud controls, and SaaS admin settings.

Do not treat indicator blocking as the full response. Indicators help reduce exposure, but the root cause still needs to be found.

Why this matters:

Blocking known indicators can stop repeat activity, reduce spread, and buy time. But attackers may change infrastructure, so blocking alone is not enough.

# Step 12: Stabilize Critical Business Processes

Containment should include business process controls, not only technical controls.

# For finance incidents, at a minimum:

• Pause suspicious payments
• Require out-of-band verification
• Review recent bank-detail changes

# For HR incidents:

• Restrict access to employee data and review recent exports

# For customer data incidents:

• Restrict sharing and preserve access logs

# For website or e-commerce incidents

• Consider temporary maintenance mode, payment processor checks, and form submission review

# For vendor incidents:

• Suspend access until the vendor’s account, token, or integration is verified

Why this matters:

Many incidents cause damage through business processes, not only systems. Fraud, data exposure, customer communication, payroll changes, and vendor access may need immediate controls.

# Step 13: Coordinate with MSPs, Vendors, and External Support

If the affected system is managed by an MSP, SaaS provider, hosting provider, cloud provider, domain registrar, DNS provider, email provider, payment processor, or cyber insurance panel provider, contact the right support path quickly.

Ask for logs, session records, admin activity, access history, account lockout support, restoration options, and containment guidance.

Record all vendor instructions and actions taken.

Why this matters:

Many SMEs depend on vendors for systems they cannot fully control. Fast vendor coordination may be required to revoke access, recover logs, disable exposure, or stop misuse.

# Step 14: Verify That Containment Worked

Do not assume containment worked.

# Check whether:

• Suspicious logins stopped
• Malicious emails stopped
• Affected devices are isolated
• Exposed links are closed
• Firewall rules are corrected
• Malware alerts stopped
• Backup deletion stopped
• Public access was removed
• Suspicious sessions were revoked
• Vendor access was suspended.

Use logs, alerts, dashboards, tickets, and manual checks to confirm.

After the first containment actions are completed, the response lead should confirm that the immediate risk has actually been reduced. This means checking logs, alerts, systems, accounts, devices, backups, and business processes to make sure suspicious activity has stopped or is no longer able to continue.

Verification should answer four questions:

• Has the attacker’s access been interrupted?

• Has the affected system, account, device, file, or service been contained?

• Has the same activity appeared anywhere else?

• Have the containment actions created new business or recovery risks?

Start by confirming the specific containment action worked:

• If an account was disabled, confirm the account is actually disabled, active sessions were revoked, MFA methods were reviewed, and no new suspicious sign-ins are occurring.

• If a password was reset, confirm old sessions were revoked, recovery methods were reviewed, and the account is not still active from an unusual location.

• If a mailbox was contained, confirm forwarding rules, inbox rules, delegated access, suspicious sent mail, and unauthorized OAuth apps were removed or restricted.

• If a device was isolated, confirm it is no longer communicating with the network, cloud storage, file shares, remote access tools, or suspicious external destinations.

• If public file sharing was removed, confirm the link no longer works, permissions were corrected, and access logs were reviewed where available.

• If a firewall rule or exposed service was closed, confirm from outside the network that the port, admin panel, database, RDP, SSH, or exposed application is no longer reachable.

• If backup access was restricted, confirm backup jobs, retention, immutability, storage access, and backup admin permissions are still intact.

• If vendor access was suspended, confirm the vendor account, API token, remote support session, VPN access, or SaaS integration can no longer be used until it is reviewed.

Next, look for related activity:

Containment should not only check the first affected item. The company should search for the same pattern across similar systems, accounts, devices, and logs.

Check for similar suspicious logins, similar phishing emails, similar mailbox rules, similar file-sharing links, similar malware alerts, similar VPN activity, similar admin changes, similar remote access activity, similar exposed services, and similar backup changes.

This helps confirm whether the incident is isolated or part of a wider compromise.

# Then confirm that monitoring is still working:

Check that logs are still being collected, alerts are still being received, endpoint tools are still reporting, backup monitoring is still active, firewall and VPN logs are still available, and the incident record is still being updated.

Containment should not blind the company. If a containment action disables logging or breaks alerting, the response team may lose visibility during the most important stage of the incident.

# Also confirm business impact:

Some containment actions can disrupt operations. The response lead should confirm whether critical employees can still work, urgent customer service can continue, finance controls are safe, backups are protected, recovery options remain available, and no essential system was disconnected without a plan.

If containment creates a business outage, record it and coordinate with leadership before moving into recovery or restoration.

# Finally, document the verification result;

Record:

• Date and time verification was performed
• Who performed the verification
• What was checked
• What evidence confirms containment worked
• What suspicious activity stopped
• What suspicious activity continues
• What related systems were reviewed
• What business impact was caused
• What gaps remain
• What action is needed next
• Containment is not complete until it has been verified

If suspicious activity continues, escalate the severity, expand containment, involve outside support if needed, and keep the incident in active response.

If suspicious activity has stopped, move to eradication, stabilization, and safe recovery planning.

# Step 15: Record Every Major Action

Maintain a clear containment log.

Record:

• Date and time
• Action taken
• Person who approved it
• Person who performed it
• System, account, or device affected
• Reason for the action
• Evidence preserved before the action
• Result of the action
• Follow-up needed
• This log should be part of the incident record

Why this matters:

During an incident, decisions happen quickly. A written action log helps leadership, IT, legal, insurance, customers, auditors, and recovery teams understand what was done and why.

# Common Containment Actions by Incident Type

# Containment Priorities

Containment should generally prioritize:

1. Protecting life and safety, if relevant.
2. Stopping active attacker access.
3. Preventing ransomware spread.
4. Protecting backups.
5. Stopping data exposure.
6. Protecting admin and identity systems.
7. Protecting finance, payroll, HR, customer, and operational systems.
8. Preserving evidence.
9. Maintaining critical business operations where safe.
10. Preparing for eradication and recovery.

The exact order may change depending on the incident. The response lead should decide based on risk, evidence, and business impact.

# Recommended Open Source and Affordable Tools

These open source and good value tools can help perform the critical containment process:

# Practical Tool Stack by Company Type

# Very small company:

Use Microsoft 365 or Google Workspace admin controls, endpoint protection console, backup platform alerts, firewall admin console, Uptime Kuma, Healthchecks.io, Quad9 or NextDNS, a monitored security mailbox, and a simple incident action log.

# Microsoft-based SME:

Use Microsoft Defender for Business, Microsoft Defender XDR if available, Microsoft Entra, Microsoft Purview Audit, Defender for Office 365, Intune, Jira Service Management or Zammad, and a protected evidence folder.

# Google Workspace SME:

Use Google Admin Console, Google Workspace Alert Center, Gmail logs, Drive sharing activity, endpoint protection console, ticketing system, Healthchecks.io, and protected evidence storage.

# Cost-conscious technical company:

Use Wazuh, Velociraptor, osquery or Fleet, Sysmon, OPNsense or pfSense, Pi-hole or AdGuard Home, Nmap, Nuclei, Zammad, and Healthchecks.io.

# Network-heavy company:

Use OPNsense or pfSense, Security Onion, Suricata, Zeek, Wazuh, Zabbix, LibreNMS, Nmap, Greenbone, firewall logs, VPN logs, and DNS filtering.

# Website-heavy company:

Use Cloudflare, Nuclei, WPScan, Security Headers, SSL Labs, hosting logs, Uptime Kuma, Wazuh, and version-controlled website backups.

# Cloud-heavy company:

Use cloud-native IAM controls, cloud audit logs, Prowler, ScoutSuite, Steampipe, Trivy, Gitleaks, TruffleHog, Cloudflare Zero Trust, SIEM forwarding, and strict key rotation procedures.

# More mature security team:

Use TheHive for case management, Velociraptor for endpoint response, Security Onion for network visibility, Wazuh or OpenSearch for logs, Cortex or MISP for enrichment, and controlled SOAR workflows for repeatable containment actions.

# Containment Action Log Template

Use a simple action log with these fields:

• Incident ID
• Date and time
• Action taken
• Reason for action
• Approved by
• Performed by
• System, account, device, or vendor affected
• Evidence preserved before action
• Expected result
• Actual result
• Verification method
• Follow-up needed
• Notes

# Expected Outputs from This Section

At the end of this section, the company should have:

• Containment authority confirmed.
• Current facts preserved.
• Active risk assessed.
• Compromised accounts contained.
• Affected devices or servers isolated where needed.
• Email and business email compromise risks contained.
• Ransomware or mass file-change activity interrupted.
• Public data exposure stopped.
• Remote access and network exposure restricted.
• Backups protected.
• Known malicious indicators blocked where useful.
• Critical business processes stabilized.
• Vendors or MSPs contacted where needed.
• Containment verified.
• All major actions recorded.

A clear decision on whether the incident moves to eradication, recovery, external support, legal review, insurance notification, or continued monitoring.

# Objective

Containment is not the same as cleanup.

Containment means stopping the damage from getting worse while preserving the ability to investigate and recover safely.

A company should leave this section able to say:

“We reduced immediate risk, protected evidence, protected backups, stopped active misuse, and verified that the most urgent danger was contained.”

That is containment and immediate risk reduction.

---