Pressure makes recovery look simple: bring the service back. A team restores yesterday’s backup, reconnects accounts and declares success. The backup contains the attacker’s persistence. The administrator credential remains compromised. The restored system overwrites logs. A service account immediately reconnects to the hostile environment. Availability returns. Control does not.
Recovery has three objectives
- Preserve evidence sufficient to understand material scope and support legal, insurance or regulatory obligations.
- Restore trustworthy authority over identities, systems, data and providers.
- Return the critical business outcome within an acceptable time.
These objectives can conflict. Evidence collection consumes time. Rapid rebuild changes the scene. The answer is not to privilege one blindly; it is to decide the minimum evidence and trust conditions before restoration.
Establish the trusted point
A backup date is not automatically a trusted date. The compromise may predate it. Configuration, identity and vendor access may have been hostile long before symptoms appeared. Use multiple evidence sources to determine the earliest credible point of compromise. Where uncertainty remains, rebuild critical components from known-good sources rather than restoring the entire environment.
Value object — The Trust Restoration Gate
Before a recovered service reconnects, require evidence for:
- Identity: privileged credentials, recovery paths and service accounts are newly controlled.
- System: build source, configuration and updates are known and validated.
- Data: restored records are complete, consistent and checked against authoritative sources.
- Connectivity: external links and integrations are limited to those understood and required.
- Observation: logging and alert routes work before normal traffic resumes.
- Authority: a named incident decision-maker accepts the residual uncertainty.
- Rollback: the team can isolate the service again if trust fails.
The gate can be lighter for low-consequence systems. For critical authority or private data, it should be explicit.
Preserve before cleaning
Capture volatile and high-value evidence early where the response team has the skill and authority. Retain relevant logs, alerts, access records, suspicious messages and system images under a documented chain. Do not let well-intentioned staff delete phishing emails, reset everything independently or wipe devices before the incident lead decides what evidence is needed.
Recover in rings
Bring back the minimum control plane first: secure communications, identity administration, logging and critical records. Then restore essential outcomes. Expand only after each ring is observed and reconciled. A staged recovery reduces the chance that one unknown dependency recontaminates the entire environment.
Reconcile the business record
Technical restoration may recover databases while losing the actions that occurred during the outage. Manual payments, customer commitments, access changes and temporary files must be reconciled into the authoritative record. Otherwise the institution creates a second integrity incident after the security event is contained.
Do not measure only uptime
Record time to trustworthy operation, not merely time to service response. Track reinfection, unexplained identity changes, evidence gaps and unreconciled business actions. A service that responds while the institution cannot trust its administrators or data is not recovered. It is available to the next actor.