Rehearsing the restart for an assumed ransomware scenario
The assumption: your production environment must not be used for rebuilding. The test: we restore the agreed systems from your backups on separate infrastructure, start them, and you check whether your business would get running again from them.
The unpleasant part comes after the attack
In the public imagination a ransomware incident ends with the question of whether to pay. In practice the real work starts after that: an environment whose integrity is unclear is no foundation for rebuilding. So you need different ground — and the only ground left at that point is the backups.
That is exactly where it becomes clear what the backups are really worth. Not whether they exist, but whether a working business can be built from them without the environment that grew up around them: with a directory service, name resolution, databases and line-of-business applications, in an order that works.
A ransomware recovery test brings that situation forward — planned, without time pressure and without damage. That is the whole point: to make the unpleasant discoveries at a moment when there is still time to deal with them.
What this test does — and what it does not
A great deal gets promised in this area. So the limits come first.
Not protection against attacks
The test prevents no incident. Prevention is the job of information security — firewall, segmentation, mail filtering, trained staff.
Not forensics, not emergency response
We do not analyse attacks and do not work through a live incident. A test is a planned exercise.
A checked statement
Afterwards you know whether your backups will carry a rebuild outside your own environment — and where improvement is needed.
We do not use terms such as „ransomware-proof“. There is no test and no product that can make that promise honestly.
What tests like this turn up again and again
The results are rarely spectacular and almost always useful. Usually it is not about damaged backups but about knowledge that existed only in one person's head, or that would have disappeared along with the environment.
Which is exactly why a partial result of „that did not work“ is not a poor outcome. It is the reason for doing the test at all.
Servers added since the last review that were never included.
Services that will not start without another system, without that being written down anywhere.
The question of what has to run first is, in an emergency, precisely the one nobody can answer.
Addresses, names and certificates tied to the old environment.
Frequently asked questions about ransomware recovery testing
Is this emergency response for an attack that is under way?
No. A ransomware recovery test is a planned exercise for an assumed scenario, carried out before anything happens. If you are dealing with a live incident, contact us directly; that is a different situation with different priorities from a planned test.
Does ITN carry out forensic analysis as part of it?
No. We do not investigate attack paths, do not analyse traces and do not establish whether or when an environment was compromised. The test answers one question only: whether the backups you hold can produce a running environment again.
Can the test prove my backups are free of malware?
No, and we would not make that claim. The test shows whether the systems can be restored and started and whether your processes run in them. Whether backup data contains unwanted components is a question of analysis and not the subject of a recovery test.
So what exactly is the benefit?
You find out, before it matters, whether your backups will carry a rebuild when your own environment must not be used. And you find out where it sticks: systems missing from the backup plan, unknown dependencies, unclear start orders. Those findings can be worked through calmly — in a real emergency you would have no time for them.
How realistic is a scenario like this in a test?
The decisive condition is realistic: the rebuild takes place outside your infrastructure, with no recourse to the environment that grew up over the years. What is not simulated is time pressure, crisis communication and the decisions a management team has to take when it counts — those belong in an emergency exercise, not in a technical recovery test.
More on this: cyber recovery for the wider picture and information security for prevention. Overview in the Recovery Lab.