Can You Actually Restore? A Cyber Recovery Testing Playbook for Security Leaders

Introduction

Every organisation has backups. Most have a disaster recovery plan, a business continuity policy and an incident response retainer. Far fewer have proved that they can restore critical services when domain controllers are encrypted, administrator accounts are compromised, the backup console has been tampered with and a key supplier is offline, all at the same time.

That is the situation modern ransomware creates, and it is the situation most recovery plans have never been tested against.

Gartner's June 2026 guidance for CISOs puts the strategic shift plainly: "Resilience, not prevention, is the strategy organizations can actually win." Gartner argues that organisations should focus on "limiting impact, maintaining critical operations, and recovering quickly," and adds a point that matters for every security leader: "unlike absolute security, resilience can be tested, practiced, measured, and improved over time" (Gartner).

The regulatory context is tightening too. The UK government has confirmed plans to ban ransomware payments by public sector bodies and critical national infrastructure operators, to require other organisations to notify the authorities before paying, and to introduce mandatory incident reporting (Goodwin). For organisations that may not be able to pay, recovery capability is no longer one option among several. It is the plan.

That makes cyber recovery testing one of the most valuable investments a security leader can make this year. This playbook explains how to do it properly, what to measure, and how to turn the results into evidence the board can trust.

Why Traditional Recovery Plans Fall Short

Most disaster recovery plans were written for accidents: a failed data centre, a flood, a power outage, a corrupted database. In those scenarios, the infrastructure you use to recover is assumed to be trustworthy. Ransomware breaks that assumption.

Ransomware operators typically spend days or weeks inside a network before they encrypt anything. During that time they steal credentials, map backups, disable security tools and exfiltrate data for extortion. By the time the encryption starts, the attacker may control:

• Identity. Active Directory, Entra ID or other identity platforms, along with privileged accounts.
• Backups. Backup consoles, storage targets and the credentials used to manage them.
• Management tooling. Endpoint management, remote access and deployment tools that would normally be used to rebuild systems.
• Communications. Email, collaboration platforms and phone systems that depend on the compromised environment.

A recovery plan that assumes any of these are available will fail on day one. A plan that has only been tested by restoring a single file from backup provides very little assurance about restoring an entire business.

Start with Impact Thresholds, Not Systems

Gartner recommends establishing clear impact thresholds tied to mission-critical value chains, defining acceptable disruption levels and recovery timeframes. This creates shared accountability between security and business leadership.

Before any test, agree with business leaders:

• Which services must come back first, such as payments, customer portals, production lines, logistics or clinical systems.
• How long each service can be unavailable before harm becomes unacceptable, whether financial, regulatory, safety or reputational.
• How much data loss each service can tolerate.
• Which manual workarounds exist, and how long they can be sustained.

These become your recovery time objectives (RTOs) and recovery point objectives (RPOs), owned jointly by security, IT and the business. Without them, a test has nothing to be measured against, and recovery priorities will be argued about during the incident rather than decided in advance.

It also helps to map the dependencies behind each critical service. A customer portal may depend on identity, DNS, a database cluster, a payment gateway and a third-party content delivery network. If any of those cannot be restored, the portal cannot either. Dependency mapping often reveals that the true minimum viable business is larger and more interconnected than expected.

Test the Scenario Attackers Actually Create

Design your exercise around realistic attacker behaviour rather than convenient assumptions. Four conditions should be built into every serious recovery test.

1. Identity is compromised. Assume Active Directory and privileged accounts cannot be trusted. Can you rebuild identity from a clean, known-good source? Do you have offline copies of identity backups? Who holds the break-glass credentials, and do they work?

2. Backups are targeted. Confirm that you hold immutable or offline copies of critical data, and that backup administration credentials are separate from production identity. Test whether your backups are free of malware and persistence mechanisms before you restore them, otherwise you risk reinfecting the environment.

3. Tooling is unavailable. Assume your EDR console, RMM tools, email and collaboration platforms are down or untrusted. How will the response team communicate? Where are the runbooks stored? Can you rebuild without the tools you use every day?

4. A supplier is affected. Assume your managed service provider, cloud provider or a critical SaaS platform is also impacted, or is the route the attacker used to get in. How does that change your recovery sequence?

Add a data extortion element too. Most ransomware attacks now involve data theft as well as encryption, which means legal, regulatory and communications decisions run in parallel with technical recovery.

Run It in Two Layers

Effective recovery testing works on two levels: the decisions and the capability. Both are essential, and they reveal different weaknesses.

The tabletop exercise tests decisions. Bring together executives, legal, communications, HR, operations and IT to work through a timed scenario with injects that escalate over hours and days. Key decisions to rehearse include:



• When to isolate networks and shut down revenue-generating systems, and who has the authority to do it.
• How and when to engage insurers, legal counsel and incident response providers.
• What to tell staff, customers, regulators and the media, and when.
• How to respond to an extortion demand, including how the organisation would make that decision under the UK's proposed payment ban and pre-payment notification regime.
• How to prioritise competing recovery demands from different parts of the business.

The technical recovery test tests capability. In an isolated environment, restore a critical service end to end from backup, including identity, data and dependent applications. Time every step. Record where documentation was missing, where credentials did not work and where dependencies were overlooked.

Running both layers matters because each exposes problems the other cannot. A tabletop can reveal that nobody has authority to shut down the e-commerce platform at 2am. A technical test can reveal that restoring the database takes four days, not the four hours everyone assumed.

Build a Recovery Environment You Can Trust

Many organisations discover during testing that they have nowhere clean to recover to. If the production environment is compromised, you need an isolated recovery environment, sometimes called a clean room, where systems can be rebuilt, scanned and validated before they are reconnected.

A practical recovery environment includes:

• Isolated infrastructure, either on-premises or in a separate cloud tenant, with no trust relationships to production.
• A clean identity source and separate administrative credentials.
• Forensic and scanning tools to check restored systems for malware and persistence.
• Copies of runbooks, network diagrams and contact lists stored outside the main environment.
• A tested process for moving validated systems back into production.

Building this capability takes time and investment, so test it early. Even a limited clean room for identity and one critical application provides a valuable foundation.

Do Not Forget Cloud and SaaS Recovery

Many recovery plans still focus on on-premises servers, while a growing share of critical data now lives in cloud platforms and SaaS applications. Attackers know this. Compromised cloud administrator accounts can be used to delete storage, snapshots and virtual machines just as effectively as on-premises backups.

Include cloud and SaaS services in your testing. Confirm which data your SaaS providers back up and for how long, and which recovery is your responsibility under the shared responsibility model. Check that cloud backups are protected by separate credentials, deletion locks or a separate account.

Test whether you can restore a mailbox, a SharePoint site or a critical SaaS dataset within your agreed objectives. Many organisations discover that native retention settings fall well short of what the business assumed.

Clarify Roles Before the Crisis

Recovery fails as often through confusion as through technology. When a major incident hits, dozens of people need to act quickly, and many of them have never worked together under pressure. Use your exercises to confirm who does what:

• Incident commander. One person who owns the overall response, sets priorities and resolves conflicts between teams.
• Executive decision group. A small group with authority over shutdowns, disclosure, legal strategy and any extortion response.
• Technical recovery lead. The person who sequences restoration work and decides when a system is clean enough to reconnect.
• Communications lead. Responsible for staff, customer, regulator and media messaging, working closely with legal counsel.
• Business liaison. Represents service owners, confirms recovery priorities and manages manual workarounds.
• Supplier coordinator. Manages incident response providers, insurers, managed service providers and critical vendors.

Name deputies for every role. Major incidents run for days or weeks, and nobody can work around the clock. Store contact details, including personal phone numbers, somewhere that will remain available when corporate systems are down.

Ten Questions to Assess Your Readiness Today

Before planning a full exercise, ask your team these questions. Any answer of "we don't know" is a priority for testing.

1. When did we last restore a complete critical service from backup, rather than individual files?
2. Do we hold immutable or offline copies of all critical data and identity systems?
3. Are backup administration credentials separate from our production directory?
4. How long would it take to rebuild Active Directory or our primary identity platform from scratch?
5. Do we have an isolated environment where we could rebuild and validate systems?
6. Where are our runbooks stored, and can we reach them if our network is down?
7. Who has authority to shut down revenue-generating systems, and do they know it?
8. How would the response team communicate if email and collaboration tools were unavailable?
9. Which suppliers would we need during recovery, and have they been part of our planning?
10. Have our executives rehearsed a ransomware decision in the last 12 months?
    

Making the Business Case for Recovery Investment

Recovery capability competes for budget with every other priority, so frame it in business terms. Start with the impact thresholds agreed with business leaders and compare them with the recovery times your tests actually achieved. The gap between the two is the business risk, expressed in hours of downtime and lost revenue rather than in technical language.



Present investment options against that gap. Immutable backup storage, a clean recovery environment, identity recovery tooling and additional exercises each close part of it. Show how much each option reduces the expected downtime for your most critical services. This approach turns recovery from an abstract insurance policy into a measurable reduction in business exposure, which is the language finance directors and boards respond to.

Common Gaps Recovery Tests Uncover

Across industries, recovery tests tend to uncover the same weaknesses:

• Backup credentials stored in the same directory the attacker controls.
• Recovery runbooks that assume email and Teams are available.
• Restore times measured in days or weeks for systems with a target of hours.
• No pre-agreed authority to make shutdown, disclosure or payment decisions.
• Incident response retainers that have never been tested or that cover fewer hours than a major incident needs.
• Cyber insurance requirements that conflict with the response plan, such as approval steps nobody knew about.
• Critical dependencies on suppliers that have not been included in recovery planning.

Finding these in an exercise costs very little. Finding them during a live attack can cost the business.

A 90-Day Recovery Testing Roadmap

A 90-Day Recovery Testing Roadmap

For organisations starting from a low base, a phased approach makes progress manageable.

Days 1 to 30: Define and prepare. Agree critical services, impact thresholds and recovery objectives with business leaders. Map dependencies for the top three services. Review backup architecture for immutability and credential separation.

Days 31 to 60: Rehearse decisions. Run an executive tabletop exercise based on a realistic ransomware and data extortion scenario. Capture decisions, delays and gaps. Update the incident response plan, communications templates and decision authorities.

Days 61 to 90: Prove capability. Run a technical recovery test for one critical service, including identity, in an isolated environment. Measure actual recovery times against objectives. Present results and a remediation plan to the board.

FAQs

What is cyber recovery testing?

Cyber recovery testing is the practice of rehearsing how an organisation would restore critical services after a cyber attack, under realistic conditions where identity, backups and tooling may be compromised.

How is a ransomware tabletop exercise different from a recovery test?

A tabletop exercise tests decision-making and coordination among leaders. A technical recovery test proves that systems and data can actually be restored within target timeframes. Both are needed.

How often should we test our cyber recovery plan?

At least annually, and after significant changes to infrastructure, suppliers or the organisation.

Summary

Cybergen designs and runs ransomware tabletop exercises and technical recovery tests for organisations worldwide. Our incident response, disaster recovery and business continuity specialists help you set realistic recovery objectives, test them under real attack conditions, and turn the results into a prioritised resilience roadmap that the board can understand and fund.



Book a recovery readiness conversation with our team.

Ready to strengthen your security posture? Contact us today for more information on protecting your business.