Recover into a clean room, not back into the breach.
Recovery designed for a compromise rather than a hardware failure — identifying a known-good point, scanning before restoring, and rebuilding into an isolated environment so you do not reinstate the intruder.
Recovering from an attack is not recovering from a failure
Standard disaster recovery assumes the infrastructure failed and the data is trustworthy. After a compromise both assumptions are wrong. Restoring the most recent backup into the same environment frequently reinstates the attacker’s access along with the data, and organisations discover this by being encrypted a second time.
- The recovery plan assumes hardware failure and says nothing about compromise.
- There is no way to identify which backup predates the intrusion.
- Restoring would go back into the same environment that was breached.
- Nobody has agreed who decides that recovery can begin.
What we build
A recovery path for the compromise scenario: a clean environment to recover into, a method for finding a trustworthy restore point, scanning before anything is reconnected, and a sequence that preserves the evidence investigators will need.
- An isolated clean-room environment, built independently of the production estate
- A method for identifying the last known-good restore point against the intrusion timeline
- Malware scanning of backup data before it is restored, not after
- Infrastructure rebuilt from code rather than restored from potentially tainted images
- Forensic preservation, so recovery does not destroy the evidence of what happened
- A cyber-specific runbook with named decision authority for reconnection
How it runs
Sequenced so that evidence is preserved and nothing reconnects before it has been proven clean.
- 01Preserve before you touch
Forensic images captured first. Recovery that destroys evidence leaves you unable to answer what happened or prove it to a regulator.
- 02Find the known-good point
The intrusion timeline is used to identify a restore point that predates it — which is only possible if retention is long enough.
- 03Scan before restoring
Backup data is examined in isolation before anything is brought up, rather than discovering the payload afterwards.
- 04Rebuild rather than restore
Operating systems and infrastructure rebuilt from code to a known state, with only data restored from backup.
- 05Reconnect in stages
Services returned to the network progressively, each cleared by a named authority, with monitoring for reinfection.
What changes once it is running
What planning for compromise specifically changes.
Recovery does not reinfect
Scanning and clean rebuild break the cycle where restoring reinstates the attacker.
A trustworthy point can be found
Retention and timeline method together make a known-good restore point identifiable rather than hoped for.
Evidence survives
Forensic preservation means you can still answer the regulator, the insurer and your own board.
Decisions are pre-assigned
Who authorises reconnection is settled in advance rather than argued about during the worst week of the year.
How an engagement is shaped
Designed alongside your incident response arrangements, not separately from them.
Scenario design
Two to three weeks designing the compromise recovery path with your security, infrastructure and legal stakeholders, including decision authority.
Build the capability
Clean-room environment, scanning, rebuild automation and the cyber runbook implemented.
Rehearse
A tabletop or technical exercise against the compromise scenario specifically, which tests very different assumptions from a standard failover drill.
Common questions
The things buyers ask before they commit. If yours is not here, it is a good first question for the assessment.
- How do we know which backup is clean?
- You narrow it using the intrusion timeline from forensic analysis, then scan the candidate before restoring. This only works if retention extends past the dwell time, which is why protection retention and cyber recovery are designed together.
- Does this replace disaster recovery?
- No — it is a different scenario with different assumptions. Disaster recovery gets you running after a failure. Cyber recovery gets you running after a compromise, without bringing the compromise with you. Organisations need both paths.
- Who decides when we can reconnect?
- That is agreed during scenario design and named in the runbook — typically a decision requiring both security and business sign-off. Leaving it undefined is how systems get reconnected too early.
Does your recovery plan assume the data is trustworthy?
Most do. After a compromise that assumption is exactly the one that fails.