Breach Recovery Checklist Security Teams Skip

A breach doesn't end when systems come back online. Your organization might have restored services, re-enabled user access, and briefed the board that operations have resumed. But if you're measuring recovery by uptime instead of evidence, you're probably still compromised.

The issue isn't that teams don't work hard during incidents. It's that they confuse operational recovery with security recovery. You rebuild servers, restore applications, and resume business processes while deeper questions remain unanswered: Was the threat actor fully removed? Were persistence mechanisms eradicated? Was the governance failure that enabled the breach addressed?

This playbook guides you through true breach recovery, the kind that actually removes the adversary and fixes what broke in the first place.

The Problem: Why This Matters

Organizations often complete operational recovery but defer adversary and governance recovery. You bring systems back online under pressure from business leaders, customers, and regulators. Every hour of downtime carries operational, financial, and reputational consequences, so the visible outage becomes the priority.

This creates a dangerous measurement problem. By the time an incident becomes visible, particularly in ransomware, data theft, or identity compromise cases, the adversary has already established multiple ways to return. Dormant accounts, compromised service credentials, unmanaged remote access, cloud tokens, API keys, privileged groups, scheduled tasks, persistence in identity systems, and tampered monitoring controls all survive a rushed restoration.

These mechanisms don't create immediate disruption. They wait until you've relaxed, reopened access, and moved the incident into post-incident review. "Back to normal" becomes the most fragile phase of response.

What You Need Before Starting

Before you can execute security recovery, gather these artifacts and establish these conditions:

Evidence Baseline:

• Forensic timeline of initial access vector
• Complete list of compromised credentials (service accounts, privileged accounts, API tokens)
• Inventory of systems the adversary touched (from EDR telemetry, network flow logs, cloud audit trails)
• Documentation of persistence mechanisms found during containment
• Known-good backup images with verified creation dates before initial compromise

Authority and Resources:

• Executive sponsor who can override business pressure to reopen prematurely
• Defined risk acceptance process for residual uncertainty
• Access to external forensic support if internal visibility is incomplete
• Budget for rebuilding from trusted sources instead of patching in place

Technical Access:

• Administrative access to identity systems (Active Directory, Entra ID, Okta, etc.)
• Cloud platform admin consoles (AWS, Azure, GCP)
• EDR console with historical telemetry
• SIEM or log aggregation with at least 90 days retention
• Network segmentation controls to isolate rebuilt systems during validation

Don't start recovery without clear answers to: How did the attackers first gain access? What access did they obtain? Which governance or control failure enabled the compromise?

Step-by-Step Implementation

Phase 1: Adversary Eviction

1. Credential Reset, All of Them

Don't just reset the accounts you know were compromised. Assume credential exposure is broader than forensics revealed.

• Reset all privileged account passwords
• Rotate all service account credentials
• Revoke and reissue API keys, OAuth tokens, and application secrets
• Force password reset for any user account that authenticated from a compromised system
• Invalidate all active sessions (SAML assertions, Kerberos tickets, OAuth refresh tokens)

If you're using Azure, run:

Revoke-AzureADUserAllRefreshToken -ObjectId <user-id>

For AWS, delete and recreate IAM access keys:

aws iam delete-access-key --user-name <service-account> --access-key-id <key-id>
aws iam create-access-key --user-name <service-account>

2. Hunt for Persistence Mechanisms

Check these locations systematically:

• Scheduled tasks and cron jobs on all servers the adversary accessed
• Startup folders and registry run keys (HKLM\Software\Microsoft\Windows\CurrentVersion\Run)
• WMI event subscriptions
• Unauthorized service accounts in privileged groups
• Cloud IAM roles with overly permissive policies or unusual trust relationships
• SSH authorized_keys files
• Web shells in application directories (search for recently modified .aspx, .php, .jsp files)
• Golden ticket indicators (check for unusual Kerberos TGT lifetimes or encryption downgrades)

For Linux systems, audit cron:

find /etc/cron* /var/spool/cron -type f -mtime -90 -ls

For Windows, export scheduled tasks:

schtasks /query /fo CSV /v > scheduled_tasks.csv

Review every entry created or modified during the incident window.

3. Rebuild from Known-Good Sources

Don't patch compromised systems in place. Rebuild critical infrastructure from verified backups or fresh images.

• Restore domain controllers from backups created before initial access (verify with forensic timeline)
• Reimage jump hosts, bastion servers, and administrative workstations
• Rebuild VPN appliances and remote access infrastructure
• Redeploy containerized applications from trusted registries (verify image digests)

For each restored system, document the source image, restoration timestamp, and validation method.

4. Validate Monitoring Coverage

Attackers often disable or tamper with security tools. Before declaring eviction complete:

• Verify EDR agents are reporting on all endpoints
• Confirm SIEM is receiving logs from critical systems
• Check that cloud audit logging (CloudTrail, Azure Activity Log, GCP Cloud Audit Logs) wasn't disabled
• Test alerting rules with known-bad indicators to confirm detection works

Phase 2: Governance Recovery

Operational and adversary recovery address the immediate threat. Governance recovery fixes what broke in the first place.

1. Identify the Enabling Condition

Breaches don't occur only because an attacker was capable. They occur because something in your organization made the attack possible. Review:

• Known control gaps documented in previous risk assessments
• Unmanaged exceptions that expired or were never revisited
• Delayed patching or end-of-life systems
• Insufficient logging or monitoring coverage
• Unclear asset ownership
• Immature supplier oversight
• Accepted risks that were never re-evaluated

2. Assign Ownership and Deadlines

Every governance failure needs an owner, a remediation deadline, and executive oversight. Don't let this become a post-incident report that sits in SharePoint.

If the breach occurred because of weak identity governance, assign the identity team a specific control improvement (e.g., "Implement privileged access management for all Tier 0 accounts by Q2") and add it to the board's risk register.

If it occurred because of delayed patching, assign IT operations a revised patch SLA and tie executive compensation to compliance metrics.

3. Update the Risk Treatment Plan

For ISO/IEC 27001 environments, this is a formal requirement. Document:

• The risk that materialized
• The control that failed or was absent
• The corrective action (with reference to specific Annex A controls)
• Residual risk after treatment
• Acceptance authority if residual risk remains

This isn't paperwork. It's how you prevent the same failure from recurring.

Validation: How to Verify It Works

Before declaring recovery complete, validate these conditions:

Adversary Removal:

• No alerts triggered by known indicators of compromise for 30 days
• No authentication attempts from previously compromised credentials
• No outbound connections to known C2 infrastructure
• EDR telemetry shows no suspicious process execution or lateral movement patterns

Governance Closure:

• Every control failure identified during the incident has an assigned owner
• Risk treatment plan updated and approved by leadership
• Compensating controls in place for any residual uncertainty

Evidence Standard: Don't declare recovery based on operational milestones. Require documented evidence for each claim. If you can't prove the adversary was removed, you haven't removed them.

Maintenance: Ongoing Tasks

Security recovery isn't a one-time event. It requires sustained attention:

Monthly:

• Review privileged account activity for anomalies
• Audit scheduled tasks and service accounts for unauthorized changes
• Validate EDR and SIEM coverage hasn't degraded

Quarterly:

• Re-test detection rules against incident tactics
• Review risk treatment plan progress with executives
• Conduct tabletop exercises that specifically test governance recovery (not just operational recovery)

Annually:

• Update incident response playbooks based on lessons learned
• Reassess accepted risks that enabled previous incidents
• Verify backup restoration procedures with actual restores (not just backup success logs)

Organizations that recover well from breaches aren't the ones that restore fastest. They're the ones that understand the difference between availability, trust, and resilience. Restoring availability is necessary. Rebuilding trust takes longer. Improving resilience requires changing the conditions that made the breach possible.

Until you treat those three activities as part of the same recovery cycle, you'll keep declaring victory too early. And you'll discover the mistake when the same adversary, or another one using the same path, returns.