After containment, recover in order: find how the attacker got in and any persistence, rebuild systems by service priority from clean images, restore data from offline backups, then reset passwords and close the gaps. CISA's guide places declaring the incident over at the very end, based on set criteria.
1. Close the way in
Identify the systems and accounts involved in the initial breach, including email accounts. CISA says to contain anything that could enable continued access, such as VPNs, remote access servers, single sign-on, and cloud or public-facing assets.
2. Hunt for persistence
The guide recommends extended analysis for persistence from outside in and inside out: rogue accounts, perimeter backdoors, implants, and living-off-the-land tools such as PsExec or PowerShell scripts. If you skip this step you may restore into a network the attacker still has.
3. Rebuild by priority
Rebuild systems in order of critical-service priority. CISA suggests pre-configured standard images, and infrastructure-as-code templates for cloud resources. This is why golden images and templates are worth keeping before an incident.
4. Restore from offline backups
Reconnect systems and restore data from offline, encrypted backups, again prioritised by critical services. Before restoring, identify any dropper malware. CISA warns that attackers often drop ransomware to hide earlier activity.
5. Keep clean systems clean
CISA's example: when creating a recovery VLAN, add only clean systems to it.
6. Reset and close gaps
After the environment is fully cleaned and rebuilt, reset passwords for affected systems and accounts, close vulnerabilities and visibility gaps, and update customer-managed encryption keys as needed.
7. Declare the end, then learn
The designated IT or security authority declares the incident over against established criteria. Document lessons learned, update policies and plans, and consider sharing indicators of compromise with CISA or your sector ISAC.
A planning note
NIST SP 800-184, the guide for cybersecurity event recovery, argues for building recovery planning into risk management, prioritising resources, writing playbooks and testing plans with realistic scenarios. The recovery order above is the kind of thing a playbook should contain before you need it.
Common mistakes
- Restoring the most visible system first instead of the one other systems depend on, such as identity.
- Reusing passwords or keys that the attacker may have seen.
- Declaring victory when the ransom note disappears, rather than when exit criteria are met.
- Skipping the written record, which makes the lessons learned step guesswork.
Write your own order down in advance, with dependencies, so the choice during an incident is a lookup rather than an argument.
Quick check
Can we restore first and investigate later?
CISA advises identifying dropper malware before restoring. Restoring blind risks bringing the attacker back with the data.
When is the incident over?
When your designated IT or security authority declares it over against criteria you set in advance, per CISA's guide.
Sources
Last reviewed: 19 October 2026.
