Most organisations have backups, endpoint protection and a firewall. Far fewer could say, with evidence, how long it would take to get the business running again if ransomware encrypted their servers on a Friday night. The gap between having protection and being able to recover is where the real damage of an attack happens: in days of stopped production, missed deliveries and staff working on paper.
Recovery is not only a technical question. It depends on decisions management has to make under pressure, often with incomplete information. The questions below are the ones we think every management team should put to its IT organisation, and be able to answer together, before an attack rather than during one.
Are our backups protected from the attacker?
Attackers know that backups are what stand between them and a payment. They look for backup servers, delete snapshots and try to take over the administrator accounts that manage them. A backup that can be changed or deleted with stolen credentials offers much less protection than it appears to.
- Is at least one copy immutable or isolated, so that it cannot be altered or deleted during its retention period, even by an administrator?
- Are backup systems managed with separate accounts and phishing-resistant authentication, rather than the same credentials used everywhere else?
- Do we keep enough history to go back to a point before the attacker got in, which may be well before anything was encrypted?
- Are the encryption keys for our backups stored where they would survive a compromise of the main environment?
- Would we be alerted if someone started deleting backups or shortening retention settings?
Many attacks also involve stealing data before encrypting it. Good backups get you running again, but they do nothing about the threat of leaked data. That is why recovery planning has to sit alongside detection and data protection, not replace them.
Have we actually tested a restore?
A backup job that reports success is not proof of recovery. Restores fail for ordinary reasons: missing dependencies, undocumented configuration, licence keys nobody can find, or a database that restores while the application on top of it refuses to start. The only way to know is to restore real systems and time it.
Ask when a full restore of a critical system was last tested, how long it took and whether that matches what the business expects. If the honest answer is a week and the business assumes a day, that is a decision for management, not a technical footnote. Test your identity services as well. If Active Directory or your identity platform is lost, very little else can be brought back until it is restored.
Do we know what to restore first?
In a major incident you cannot restore everything at once. Without agreed priorities, the order is decided by whoever shouts loudest, and teams spend precious hours on systems that could have waited.
Work out in advance which business processes matter most, which systems and data they depend on, and how long each can be unavailable before the damage becomes serious. That gives you recovery time and recovery point targets grounded in business reality rather than technical habit. The exercise also exposes dependencies that are easy to overlook, such as the identity platform, DNS, core network services and the integrations between systems. Keep the priority list somewhere it can be reached even when your own systems are down.
Who decides, and how do we communicate?
The technical response is rarely where organisations struggle most. The hard part is decision-making: when to disconnect the network, whether to stop production, who informs customers and authorities, when to involve the police and how to respond to a ransom demand. These decisions carry legal, financial and reputational consequences, and they should not be improvised at three in the morning.
- Decision rights: Who can authorise taking systems offline or stopping operations, and who stands in if that person cannot be reached?
- Incident response plan: Is there a current plan with named roles, contact details and a ransomware playbook, and does it cover regulatory reporting and personal data breach notification?
- Out-of-band communications: If email, Microsoft Teams and the intranet are compromised or offline, how will the crisis team talk? Agree an alternative channel in advance and keep key phone numbers on paper.
- External support: Are incident responders, legal advisers and communications support agreed in advance, or would we be searching for them mid-crisis?
- Cyber insurance: If we have a policy, do we know its conditions, such as which responders we may use and how quickly the insurer must be notified?
Have we practised?
Plans that have never been exercised tend to fail in predictable ways. Contact lists are out of date, roles overlap, and people discover that the plan relies on systems that would not be available. A tabletop exercise, where management and technical teams walk through a realistic ransomware scenario together, brings these problems to the surface at low cost.
Keep exercises short and specific, and add realistic complications: the backup server has also been encrypted, a key supplier is affected, a journalist calls asking for comment. Close each session with a short list of improvements, each with an owner, and repeat the exercise regularly with new scenarios. Over time, it becomes the most reliable measure of how prepared you really are.
How Altechy can help
If you want an honest picture of where you stand, our Incident Readiness Assessment, part of our Incident Response & Cyber Recovery service, reviews your plans, roles and reporting routines and includes a tabletop exercise with management and technical teams. You leave with an updated plan and key playbooks. Our Backup & Recovery Assessment, part of Backup & Disaster Recovery, checks backup coverage and ransomware resilience and includes a controlled restore of selected critical systems, so recovery times are measured rather than assumed.
Not sure which question to tackle first? Book a free 60-minute idea session and we will help you decide.