Powered by

# 5.5 Eradication, Stabilization, and Safe Handoff to Recover

# Goals

Eradication is the work of removing the cause of the incident.

Stabilization is the work of making the environment safe enough to operate again.

Safe handoff to Recover is the decision that the active threat has been removed or controlled, critical protections are working, and recovery work can begin without immediately reintroducing the same problem.

Containment stops the damage from getting worse. Eradication removes the attacker’s access, malware, unsafe configuration, exposed data, vulnerable software, compromised credentials, malicious rules, or unauthorized tools that caused or supported the incident.

The company should not rush from containment straight into restoration. If systems are restored before the cause is removed, the same incident may return.

# Step 1: Confirm Scope Before Cleanup

Before removing or rebuilding anything, confirm the current known scope.

Review which users, devices, servers, mailboxes, SaaS tools, cloud platforms, websites, vendors, files, and business processes were affected or may have been affected.

Record what is confirmed, what is suspected, and what is still unknown.

Why this matters:

Eradication should not only clean the first system that showed symptoms. A compromised mailbox, infected endpoint, exposed website, stolen admin account, or abused vendor login may be only the visible part of a wider incident.

At minimum, confirm:

  • Affected users
  • Affected accounts
  • Affected devices
  • Affected systems
  • Affected data
  • Affected vendors
  • Affected business processes
  • Affected backups
  • Known entry point
  • Known persistence method, if identified
  • Known active risk
  • Open investigation gaps

# Step 2: Remove Attacker Access

Remove any access path that may allow the attacker to return.

This may include:

  • Disabling compromised accounts
  • Revoking sessions
  • Resetting passwords
  • Re-registering MFA
  • Removing unauthorized MFA methods
  • Removing unauthorized admin roles
  • Disabling suspicious vendor access
  • Revoking OAuth grants
  • Rotating API keys
  • Rotating SSH keys
  • Rotating service account credentials
  • Rotating application secrets
  • Removing unknown tokens
  • Disabling unused remote access.

Pay special attention to privileged accounts:

Include email administrators, cloud administrators, domain administrators, DNS administrators, domain registrar administrators, backup administrators, VPN administrators, SaaS administrators, website administrators, finance users, payroll users, HR users, developers, MSP users, and vendor users.

Why this matters:

If attacker access remains active, recovery will fail. The company may restore systems while the attacker still has credentials, tokens, sessions, or remote access.

Important checks include:

  • Active sessions revoked
  • Passwords reset
  • MFA methods reviewed
  • Suspicious MFA methods removed
  • Admin roles reviewed
  • Vendor accounts reviewed
  • Former employee accounts disabled
  • Service accounts reviewed
  • API keys rotated
  • OAuth apps reviewed
  • SSH keys reviewed
  • Recovery email and phone settings reviewed
  • Password reset rules reviewed
  • Shared accounts removed or restricted

# Step 3: Remove Malicious Artifacts and Persistence

Remove anything the attacker or malware used to stay in the environment.

Persistence may appear as malware files, web shells, scripts, scheduled tasks, startup items, malicious services, registry keys, cron jobs, new local users, unauthorized remote tools, browser extensions, malicious inbox rules, hidden mailbox forwarding, cloud automation, OAuth apps, API tokens, startup scripts, modified website files, or changed firewall rules.

Do not only remove the obvious malware alert. Look for the mechanism that allowed it to return.

Why this matters:

Many incidents appear fixed after the first malicious file is removed, but return later because persistence was missed.

Common places to check include:

  • Windows scheduled tasks
  • Windows services
  • Startup folders
  • Registry run keys
  • PowerShell profiles
  • Linux cron jobs
  • Systemd services
  • SSH authorized keys
  • New local users
  • Local admin groups
  • Remote access tools
  • RMM agents
  • Browser extensions
  • Mailbox rules
  • Mailbox forwarding
  • Delegated mailbox access
  • OAuth app approvals
  • Cloud IAM roles
  • Cloud automation
  • Website files
  • CMS admin users
  • CMS plugins
  • Web shells
  • Firewall rules
  • VPN users

# Step 4: Patch the Weakness or Misconfiguration That Allowed the Incident

Eradication is incomplete if the original weakness remains.

Patch exploited software, remove unsafe exposure, harden misconfigured systems, close unnecessary ports, update website plugins, fix cloud permissions, restrict public sharing, remove public admin access, correct firewall rules, enforce MFA, and apply safer configurations.

If the entry point is unknown, review the most likely entry paths: identity, email, endpoint, remote access, website/CMS, cloud/SaaS, vendor access, and exposed services.

Why this matters:

If the original weakness remains, the company may be compromised again after cleanup.

Examples include:

  • Patch exploited VPN or firewall appliance
  • Patch website CMS, plugins, themes, and hosting components
  • Remove public RDP, SSH, database, or admin panel exposure
  • Correct cloud storage permissions
  • Disable anonymous SaaS sharing
  • Restrict admin console access
  • Enforce MFA on high-risk systems
  • Remove weak legacy authentication
  • Update endpoint protection
  • Update server software
  • Fix vulnerable dependencies
  • Correct risky DNS or domain settings
  • Remove unused accounts
  • Remove broad firewall rules
  • Harden remote access

# Step 5: Clean Email, Cloud, SaaS, and Collaboration Platforms

Many incidents leave changes in email or SaaS platforms rather than on traditional devices.

Review and clean affected platforms carefully.

For email, check forwarding rules, inbox rules, delegated access, app passwords, mailbox permissions, suspicious sent mail, deleted mail, transport rules, connectors, auto-replies, and shared mailbox access.

For cloud storage and SaaS tools, check public links, guest users, external sharing, mass downloads, data exports, OAuth apps, API keys, integrations, admin users, new groups, audit log settings, and deleted or modified files.

Why this matters:

Email and SaaS compromise can persist through rules, tokens, integrations, and permissions even after a password reset.

Important checks include:

  • Suspicious forwarding removed
  • Suspicious inbox rules removed
  • Delegated access reviewed
  • Shared mailbox access reviewed
  • OAuth apps reviewed
  • App passwords disabled or reviewed
  • External sharing reviewed
  • Public links disabled where inappropriate
  • Guest users reviewed
  • Data exports reviewed
  • Admin roles reviewed
  • Audit logs enabled
  • API keys rotated
  • Suspicious integrations removed
  • Deleted files reviewed
  • Retention settings checked

# Step 6: Decide Whether to Clean, Rebuild, or Replace Systems

For affected devices and servers, decide whether they can be safely cleaned or should be rebuilt.

For low-risk issues, cleaning may be enough if the cause is clear and verification is strong.

For high-risk malware, ransomware, unauthorized admin access, root-level compromise, web shell activity, domain compromise, or unclear persistence, rebuilding from trusted media is often safer than trying to clean the system in place.

Do not rebuild before needed evidence is preserved.

Why this matters:

A system that appears clean may still contain hidden persistence, unauthorized tools, changed settings, or stolen credentials. Rebuilding reduces uncertainty when the compromise is serious.

Rebuild or replace should be strongly considered when:

  • Ransomware was present
  • Administrator access was compromised
  • Root or domain-level access may have occurred
  • A server was used for lateral movement
  • A web shell was found
  • Endpoint protection was disabled by the attacker
  • Persistence is unclear
  • The system is unsupported or end-of-life
  • The system cannot be trusted
  • The business impact of reinfection would be high

# Step 7: Validate Backups and Recovery Sources Before Use

Before moving into recovery, confirm backups are usable and safe.

Check whether backups exist, whether the needed restore point is available, whether backup jobs completed successfully, whether backups were deleted or modified, whether immutable or offline copies are intact, and whether the selected restore point is likely clean.

Do not restore a backup that contains the same malware, unsafe configuration, exposed credentials, or compromised account state unless there is a clear plan to fix it immediately after restoration.

Why this matters:

Backups can restore the business, but they can also restore the problem. A rushed restore can reintroduce malware, vulnerable software, malicious rules, or compromised configurations.

Important checks include:

  • Backup jobs succeeded
  • Restore points exist
  • Restore points predate known compromise where possible
  • Backup integrity verified
  • Backup storage not tampered with
  • Immutable or offline copies preserved
  • Backup admin access reviewed
  • Backup credentials rotated if needed
  • Sample restore tested where practical
  • Restored data scanned where appropriate
  • Restoration plan documented

# Step 8: Rotate Credentials, Secrets, and Keys

After attacker access is contained and evidence needs are considered, rotate credentials that may have been exposed.

This may include:

  • User passwords
  • Administrator passwords
  • Service account passwords
  • API keys
  • SSH keys
  • Cloud access keys
  • Database credentials
  • Application secrets
  • OAuth tokens
  • Webhook secrets
  • CI/CD secrets
  • Backup credentials
  • Domain registrar credentials
  • DNS credentials
  • Vendor portal credentials.

Prioritize credentials with broad access or access to sensitive data.

Why this matters:

Attackers may keep credentials for later use. If credentials, tokens, or keys are not rotated, the company may appear clean while the attacker still has a way back in.

Rotate carefully. Some keys and service accounts are tied to production systems, integrations, backups, applications, and automated jobs. Record each change and confirm affected services still work.

# Step 9: Verify Eradication Through Hunting and Rescanning

After cleanup, verify that the known signs of compromise are gone.

Search for the same indicators across endpoints, servers, logs, cloud accounts, SaaS platforms, email systems, websites, VPN logs, and backup systems.

Run endpoint scans, log searches, vulnerability scans, external exposure checks, website checks, cloud posture checks, mailbox rule reviews, SaaS sharing reviews, and account reviews.

Why this matters:

Eradication must be proven, not assumed. One cleaned device does not mean the environment is clean.

Verification should check:

  • Known malware indicators
  • Known suspicious IPs and domains
  • Known malicious file hashes
  • Known suspicious processes
  • Known persistence locations
  • Suspicious login activity
  • Suspicious admin changes
  • Suspicious mailbox rules
  • Suspicious OAuth apps
  • Suspicious API keys
  • Suspicious VPN activity
  • Public exposure
  • Vulnerable internet-facing systems
  • Backup tampering
  • Disabled logging
  • Disabled endpoint protection
  • Devices that stopped reporting

# Step 10: Stabilize Core Security Controls

Before recovery begins, confirm that the main security controls are working.

Check identity controls, MFA, endpoint protection, logging, alerting, backups, firewall rules, VPN controls, email security, SaaS sharing controls, cloud audit logs, website protection, patch status, and admin access restrictions.

Why this matters:

Recovery should not begin in an unstable environment. If logging, endpoint protection, MFA, or backups are still broken, the company may not notice reinfection or renewed attacker activity.

Stabilization should confirm:

  • MFA active on critical accounts
  • Admin access restricted
  • Endpoint protection reporting
  • EDR or antivirus healthy
  • Logging enabled
  • Critical alerts working
  • Backup jobs running
  • Backup storage protected
  • Firewall rules reviewed
  • VPN access reviewed
  • Email protections active
  • SaaS sharing controlled
  • Cloud logs active
  • Website protection active
  • Critical patches applied or mitigated

# Step 11: Stabilize Critical Business Processes

Technical cleanup is not enough. The business process affected by the incident must also be stabilized.

# For finance incidents:

  • Verify payment holds, bank-detail changes, invoice approvals, and vendor payment processes.

# For HR incidents:

  • Verify employee data access, payroll changes, and employee records.

# For customer data incidents:

  • Verify access, sharing, export history, and customer communication needs.

# For operational incidents:

  • Verify that the affected department has safe workarounds or restored access.

# For vendor-related incidents:

  • Confirm whether vendor access should remain suspended, limited, or restored under new controls.

Why this matters:

An incident may continue through business process abuse even after the technical issue is contained. Fraud, data exposure, incorrect payments, customer confusion, and vendor misuse need business-level controls.

# Step 12: Monitor Closely After Eradication

After eradication actions are complete, increase monitoring for a defined period.

Watch the affected accounts, systems, devices, SaaS platforms, cloud environments, remote access tools, websites, and backup systems for recurring signs of compromise.

The monitoring window may be several days or longer depending on severity.

Why this matters:

Some attacker activity returns after cleanup. Close monitoring helps confirm whether eradication worked and whether recovery can continue safely.

Watch for:

  • Repeated suspicious logins
  • New admin changes
  • New mailbox rules
  • New OAuth apps
  • New public links
  • New malware alerts
  • Devices that stop reporting
  • Unexpected outbound traffic
  • VPN anomalies
  • Website file changes
  • Backup job failures
  • DNS or domain changes
  • New exposed services
  • Unusual data downloads

# Step 13: Decide Whether the Environment Is Safe Enough for Recovery

Before handoff to Recover, make a clear decision.

The response lead should confirm that the active threat has been contained, the likely cause has been removed or mitigated, critical access paths are controlled, backups are protected, logging is working, and business leadership understands any remaining risk.

If these conditions are not met, do not hand off fully to Recover yet.

Why this matters:

Recovery depends on trust. If the environment is not stable, recovery can waste time, restore compromised systems, or create repeat incidents.

The environment may be ready for recovery when:

  • Attacker access appears removed
  • Known persistence is removed
  • Exploited weakness is patched or mitigated
  • Affected accounts are secured
  • Affected devices are isolated, cleaned, rebuilt, or replaced
  • Public exposure is removed
  • Backups are verified
  • Critical logs are available
  • Critical alerts are working
  • Business process controls are active
  • No active suspicious activity is observed
  • Residual risks are documented
  • Leadership approves the move to recovery

# Step 14: Prepare the Handoff Package for Recover

Create a short handoff package before moving into the Recover section.

Include what happened, affected systems, affected users, evidence location, containment actions, eradication actions, systems cleaned or rebuilt, credentials rotated, backups verified, remaining risks, restoration priorities, business dependencies, required monitoring, and approval to proceed.

Why this matters:

Recovery teams need clear facts. Without a handoff package, they may restore the wrong systems first, use unsafe backups, miss dependencies, or reintroduce the same issue.

The handoff package should include:

  • Incident summary
  • Current severity
  • Affected systems
  • Affected accounts
  • Affected data
  • Affected vendors
  • Evidence location
  • Containment actions completed
  • Eradication actions completed
  • Systems safe to recover
  • Systems not safe to recover
  • Approved restore points
  • Credentials rotated
  • Controls verified
  • Known gaps
  • Residual risks
  • Required monitoring during recovery
  • Recovery priorities
  • Decision owner
  • Date and time of handoff

# Step 15: Record Remaining Risks and Exceptions

If the company moves to recovery while some risk remains, record it clearly.

Examples include a system not yet fully patched, a vendor still under review, incomplete logs, a device awaiting rebuild, a backup restore point that needs extra scanning, a SaaS integration temporarily disabled, or a business process operating under manual controls.

Why this matters:

Unrecorded residual risk becomes forgotten risk. Recovery may proceed, but leadership must understand what is still not fully resolved.

Record:

  • Risk or exception
  • Owner
  • Reason it remains open
  • Temporary control
  • Business impact
  • Due date
  • Approval
  • Review date

# Eradication Examples by Incident Type

Check this quick review of actions per incident type, noting that an incident may include multiple types:

Incident Type Eradication Actions
Compromised email account Remove forwarding and inbox rules, revoke sessions, reset password, reset MFA, remove suspicious OAuth apps, review delegated access, check sent/deleted mail, search related mailboxes
Business email compromise Secure affected mailboxes, remove hidden rules, verify bank-detail changes, review payment approvals, block malicious senders, search for similar messages, require out-of-band payment verification
Stolen credentials Reset password, revoke sessions, reset MFA methods, review recovery settings, check related systems, remove unauthorized app access, rotate reused credentials
Malware on endpoint Preserve evidence, isolate device, remove malware if low-risk, rebuild if high-risk, scan for persistence, check lateral movement, verify endpoint protection health
Ransomware Remove attacker access, isolate affected systems, protect backups, rebuild affected systems from trusted sources, restore from clean backups only after cause is controlled
Website or CMS compromise Remove web shells, remove malicious users, update CMS and plugins, rotate admin and hosting credentials, check file integrity, review logs, restore clean files where needed
Cloud or SaaS compromise Revoke sessions, rotate keys, remove suspicious OAuth apps, review IAM roles, remove public storage, review data exports, restore safe permissions, verify audit logging
Vendor or MSP account abuse Suspend vendor access, rotate tokens, require named accounts and MFA, review recent vendor activity, remove unnecessary access, approve limited restoration only after review
Public data exposure Remove public access, identify exposed data, check access logs, rotate exposed secrets, preserve evidence, review notification obligations, confirm permissions are corrected
Backup tampering Secure backup admin access, verify immutable/offline copies, check deletion logs, rotate backup credentials, validate restore points, prevent restore from compromised sources

# Safe Handoff to Recover Checklist

Before moving to Recover, confirm:

  • Active attacker access has been interrupted.
  • Known persistence has been removed or neutralized.
  • Compromised accounts are secured.
  • Suspicious sessions are revoked.
  • High-risk credentials, tokens, and keys are rotated.
  • Affected devices are isolated, cleaned, rebuilt, or replaced.
  • Exploited vulnerabilities are patched or mitigated.
  • Unsafe public exposure has been removed.
  • Email rules, forwarding, delegation, and OAuth apps are reviewed.
  • Cloud and SaaS sharing is reviewed.
  • Backups are protected.
  • Restore points are reviewed for likely cleanliness.
  • Critical logs remain available.
  • Critical alerts are working.
  • Endpoint protection is reporting.
  • Admin access is restricted.
  • Business process controls are active.
  • Residual risks are documented.
  • Leadership has approved recovery to begin.

# Recommended Open Source and Affordable Tools

These open source and good value tools can help perform the eradication and stabilization tasks:

Tool or Solution Link Type Best Use
Wazuh Wazuh Open-source Endpoint visibility, file integrity monitoring, log review, vulnerability visibility, active response support
Velociraptor Velociraptor Open-source Endpoint triage, forensic collection, hunting, incident response investigation
Security Onion Security Onion Open-source with paid support Network security monitoring, host visibility, log review, threat hunting, case management
osquery osquery Open-source Query endpoint state, users, services, software, processes, and persistence points
Fleet Fleet Open-source and commercial Manage osquery, endpoint posture, policy checks, and device visibility
Sysmon Sysmon Free Detailed Windows and Linux activity logging
YARA YARA Open-source Malware pattern matching and suspicious file classification
Hayabusa Hayabusa Open-source Windows event log timeline review and threat hunting
Chainsaw Chainsaw Open-source Windows event log hunting using Sigma-style rules
Sigma Sigma Open-source Portable detection rules for logs and SIEM platforms
Timesketch Timesketch Open-source Collaborative forensic timeline analysis
Plaso Plaso Open-source Timeline generation from logs and forensic artifacts
Autopsy Autopsy Open-source Disk and file-system forensic review
Volatility 3 Volatility 3 Open-source Memory forensics and volatile artifact review
CyberChef CyberChef Open-source Decode, parse, hash, and inspect technical indicators
VirusTotal VirusTotal Free and commercial Check suspicious files, URLs, domains, and hashes
urlscan.io urlscan.io Free and commercial Review suspicious URLs and webpages
MISP MISP Open-source Track indicators, observables, and threat intelligence
TheHive TheHive Commercial with community/project history Case management, task tracking, investigation records, handoff documentation
Zammad Zammad Open-source Ticketing, task assignment, incident tracking, handoff notes
GLPI GLPI Open-source IT service management, assets, incident records, task tracking
Jira Service Management Jira Service Management Free tier and commercial Incident workflow, approvals, recovery tasks, escalation tracking
Microsoft Defender for Business Microsoft Defender for Business Affordable commercial Endpoint protection, isolation, investigation, and response for Microsoft-based SMEs
Microsoft Defender XDR Microsoft Defender XDR Commercial Microsoft identity, email, endpoint, cloud, and SaaS investigation and response
Microsoft Entra ID Microsoft Entra ID Included or commercial by plan Identity containment, session revocation, MFA review, access review
Microsoft Purview Audit Microsoft Purview Audit Included or paid by plan Microsoft 365 audit review and evidence support
Google Admin Console Google Admin Console Included depending on Google Workspace plan Account suspension, password reset, session review, audit log review
Google Workspace Alert Center Google Workspace Alert Center Included depending on edition Review Google Workspace alerts and suspicious activity
Nmap Nmap Open-source Confirm exposed ports and services are closed
Greenbone Community Edition Greenbone Community Edition Open-source Vulnerability scanning after patching or hardening
Nuclei Nuclei Open-source Template-based exposure and vulnerability verification
WPScan WPScan Free and paid options WordPress vulnerability and plugin review
Trivy Trivy Open-source Container, filesystem, repository, IaC, dependency, and cloud scanning
Prowler Prowler Open-source and commercial Cloud security posture checks
ScoutSuite ScoutSuite Open-source Multi-cloud security auditing
Steampipe Steampipe Open-source Query cloud, SaaS, DNS, and infrastructure configuration
Checkov Checkov Open-source and commercial Infrastructure-as-code and cloud misconfiguration checks
Gitleaks Gitleaks Open-source Secret scanning in files, repositories, and pipelines
TruffleHog TruffleHog Open-source and commercial Secret discovery and verification
PingCastle PingCastle Free and commercial Active Directory security assessment
Purple Knight Purple Knight Free Active Directory and identity security assessment
BloodHound Community Edition BloodHound Community Edition Free/community edition Defender review of identity attack paths
OPNsense OPNsense Open-source Firewall control, network segmentation, VPN, IDS/IPS options
pfSense Community Edition pfSense Community Edition Free/community edition Firewall, VPN, emergency rule changes, segmentation
Cloudflare Zero Trust Cloudflare Zero Trust Free tier and commercial Remote access control, DNS filtering, web filtering, access policies
Tailscale Tailscale Free tier and commercial Safer remote access and device-level access control
NetBird NetBird Open-source and commercial WireGuard-based zero-trust network access
CrowdSec CrowdSec Open-source and commercial Behavior-based blocking and threat intelligence
Fail2ban Fail2ban Open-source Temporary blocking of brute-force activity on Linux services
Uptime Kuma Uptime Kuma Open-source Confirm restored services and websites remain reachable
Healthchecks.io Healthchecks.io Open-source and hosted plans Monitor backups, scheduled jobs, and recurring recovery tasks
Zabbix Zabbix Open-source Infrastructure monitoring during stabilization
LibreNMS LibreNMS Open-source Network device monitoring and alerting
restic restic Open-source Encrypted backup and restore support
BorgBackup BorgBackup Open-source Deduplicated encrypted backups
Kopia Kopia Open-source Encrypted backup and snapshot management
Proxmox Backup Server Proxmox Backup Server Open-source and commercial support VM, container, and host backup management
Veeam Community Edition Veeam Community Edition Free/community edition Backup and recovery for smaller environments

# Practical Tool Stack by Company Type

# Very small company:

Use Microsoft 365 or Google Workspace admin tools, endpoint protection console, backup console, Uptime Kuma, Healthchecks.io, Nmap, Security Headers, SSL Labs, a ticketing system, and a protected evidence folder.

# Microsoft-based SME:

Use Microsoft Defender for Business, Microsoft Defender XDR where available, Microsoft Entra ID, Microsoft Purview Audit, Defender for Office 365, Intune, PingCastle or Purple Knight for identity review, Jira Service Management or Zammad, and backup platform reporting.

# Google Workspace SME:

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

# Cost-conscious technical company:

Use Wazuh, Velociraptor, osquery or Fleet, Sysmon, YARA, Hayabusa, Nmap, Greenbone, Nuclei, Zammad, Uptime Kuma, and Healthchecks.io.

# Network-heavy company:

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

# Website-heavy company:

Use Cloudflare, WPScan, Nuclei, Security Headers, SSL Labs, hosting logs, Git-based deployment records, Uptime Kuma, Wazuh, and clean website backups.

# Cloud-heavy company:

Use cloud-native IAM and audit logs, Prowler, ScoutSuite, Steampipe, Checkov, 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, Timesketch for timelines, MISP for indicators, and controlled playbooks for repeatable eradication and recovery handoff.

# Eradication and Stabilization Record Template

Use a simple record with these fields:

Incident ID Date and time System, account, device, or platform Eradication action Reason for action Approved by Performed by Evidence preserved before action Credential or key rotation required Patch or configuration change required Verification performed Result Residual risk Recovery readiness status Follow-up owner Due date Notes

# Expected Outputs from This Section

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

  • Confirmed affected scope.
  • Attacker access removed
  • Compromised credentials, tokens, and keys rotated.
  • Malicious artifacts removed.
  • Persistence mechanisms removed.
  • Exploited vulnerabilities patched or mitigated.
  • Unsafe configurations corrected.
  • Email, cloud, SaaS, and collaboration changes reviewed.
  • Affected systems cleaned, rebuilt, replaced, or isolated.
  • Backups verified and protected.
  • Security controls stabilized.
  • Business process controls stabilized.
  • Post-eradication monitoring started.
  • Residual risks documented.
  • Recovery readiness decision made.
  • Recover handoff package completed.
  • Leadership approval recorded.

# Objective

Do not recover into an unsafe environment.

A company should leave this section able to say:

“We removed the cause, reduced the chance of reinfection, confirmed key controls are working, verified backups, documented remaining risks, and gave Recovery clear instructions on what can safely be restored.”

That is eradication, stabilization, and safe handoff to Recover.

© Copyright 2026. All rights reserved.