Recovery sequencing: the restore order that gets you back safely

Key takeaways

• Restore onto known-clean infrastructure — rebuilding into a still-compromised environment invites immediate re-encryption.
• Sequence matters: identity and core services first, then the applications that depend on them, then the rest by business priority.
• Recovery is a project with a documented runbook and a defined 'done,' not an ad-hoc scramble to bring machines back.

Don't rebuild into a compromised house

The most dangerous recovery mistake is restoring clean backups into an environment the attacker still controls. If the intrusion isn't fully evicted — persistence removed, credentials rotated, the initial access closed — the attacker simply re-encrypts your freshly restored systems, sometimes within hours, and now you've burned a recovery attempt and confirmed for them that you're recovering. Recovery starts with confidence that the environment is clean, which is why containment and eviction precede restoration, not the other way around.

Sequence by dependency, then by priority

Systems have to come back in dependency order. Identity and core infrastructure — domain controllers, DNS, certificate services — come first, because almost everything else depends on them; restore an application before the authentication it needs and it simply won't work. After the foundation, sequence by business priority: the revenue-critical and safety-critical systems ahead of the convenient ones. A restore order chosen in the moment tends to produce half-working systems and rework; a pre-planned sequence produces steady, verifiable progress.

Rotate credentials as you go

Assume every credential that could have been exposed during the intrusion is compromised, because you rarely know exactly what the attacker took. Recovery is the moment to rotate them systematically — service accounts, admin credentials, and the secrets applications use to talk to each other — ideally as part of the rebuild rather than as a scramble afterward. Restoring a system while leaving the credentials the attacker already harvested still valid is how a 'recovered' environment gets re-compromised.

Treat recovery as a managed project

Recovery is a project with a plan, an owner, a documented runbook, and a clear definition of done — not an all-hands scramble to bring machines back as fast as possible. Track what's restored, what's verified clean, and what's still pending; validate each tier before moving to the next; and resist the pressure to declare victory before the environment is genuinely stable. Rushing the finish is how organizations end up recovering twice.