Restarting when your own infrastructure is out of the question
Cyber recovery begins where the familiar assumption ends: the environment you have is not available for rebuilding. The ITN Recovery Lab rehearses exactly that case — on infrastructure that has nothing to do with your production systems.
Why the restore has to happen elsewhere
Most recovery plans tacitly assume that your own environment will still be usable when it matters. The hypervisor is running, the storage responds, the network is up, the directory service can be reached. On that assumption, a restore is a manageable affair.
After a cyberattack that assumption no longer holds. A compromised virtualisation environment must not be used as the foundation for rebuilding. Systems whose integrity is unclear cannot be put back into service with a clear conscience. And restoring systems in the same place the incident happened risks carrying the cause along with them.
So a test worth relying on has to happen outside. Not because that is more convenient, but because only there is the real requirement examined: building a running IT environment from the backups alone — with no recourse to the environment that grew up over the years.
Situations in which your own environment drops out
Not every one of these is an attack. What they have in common is that the existing infrastructure is no use for rebuilding.
Ransomware
Systems are encrypted and the state of the environment is unclear. Rebuilding has to start from clean ground.
Compromised virtualisation
If the virtualisation layer itself is affected, every system running on it is in question — including the ones that still work.
Storage failure
When central storage fails, it is not one system that is missing but the foundation of every system at once.
Loss of hardware
After fire, water or theft there is no target hardware standing ready. The restart needs somebody else's infrastructure.
Misconfiguration
A serious misconfiguration can render an environment as unusable as an attack would — only without an attacker.
Loss of a data centre
When a site is lost entirely, the only thing that counts is what is available outside that site.
Isolation is a property of the environment, not a security promise
The recovery environment is built separately from the customer's production network. That means the test does not change your live infrastructure and does not reach into it. Access is given only to the people you name.
That separation is a structural property of how the environment is built. It is not a promise that your backups are free of malware, and not a commitment that a restart will succeed when it matters. What the test delivers is a checked statement about the state of your restorability today.
Prevention remains the job of information security — our own firewall appliances, segmentation, mail filtering and a team that knows the environment. Cyber resilience only exists once prevention is joined by evidence that a restart is possible.
No access to your production environment during the test.
The rebuild is rehearsed on somebody else's infrastructure — precisely the situation of a real emergency.
Only named people are given access to the test environment.
The restore runs on infrastructure in Germany.
Frequently asked questions about cyber recovery
What separates cyber recovery from classic disaster recovery?
Classic disaster recovery assumes your own infrastructure is still usable in principle — after a hardware failure, say. Cyber recovery sets that assumption aside: the environment is regarded as no longer trustworthy. The restart therefore has to happen somewhere else.
Why can't I simply test in my own environment?
Because a test in the production environment presupposes exactly what is missing when it matters. Testing only there means testing the comfortable case: familiar hardware, an existing network configuration, directory services already running. Testing outside forces you to rebuild all of those preconditions from the backups alone.
Is the recovery environment safe if potentially infected data is restored into it?
The environment is built separately from the customer's production network so that the restore does not touch your live infrastructure. That is a statement about the separation, not about the contents of your backups: whether backup data contains compromised components is a question of analysis — and analysis is not part of a recovery test.
Does a cyber recovery test replace security measures?
No. Prevention and recovery are two different things. Firewalls, network segmentation, mail filtering and awareness reduce the likelihood of an incident. A recovery test tells you what happens when those measures were not enough. Cyber resilience needs both.
Can we repeat the test when our environment changes?
Yes, and there is much to be said for it. New systems, altered dependencies and adjusted backup configurations all change the result. A test always describes the position as at the date it was carried out.
More on this: ransomware recovery test for that specific scenario and disaster recovery test for how a planned test is set up. Overview in the Recovery Lab.