Do not test whether a file restores. Test whether the service recovers under attack.
A destructive incident affects identity, consoles, networks, configuration and trust in data. A relevant exercise begins with lost production control and measures the path to a safe, usable service.
What the exercise must prove
- Backup copies and control plane remain accessible after production compromise
- A separate, controlled recovery identity exists
- The team can select a trusted recovery point
- Services return in dependency- and impact-led order
- Measured time, blockers and residual risk become an owned backlog
1. Define a scenario that breaks comfortable assumptions
A scheduled restore with every administrator and console available verifies only part of the capability. A ransomware scenario should assume privileged access, production disruption and attempts to affect backup and management tooling.
Set detection time, suspected assets, compromised identities and missing information. Do not inject every difficulty at once. Choose conditions exposing a dominant dependency while allowing safe learning.
- Privileged identity compromise
- Production unavailable or untrusted
- Latest backup potentially contaminated
- Limited access to normal tooling
- Time pressure and executive decision
2. Choose an exercise level matching maturity
A tabletop validates roles and decisions but not restore speed. A component test verifies a copy or platform. A service test connects identity, data, application, network and functional validation. An enterprise exercise adds crisis, communications and suppliers.
Start at a safe level but state what remains unproven. Maturity grows as exercises become more integrated and realistic without creating uncontrolled production risk.
- Tabletop: decisions and communications
- Component: isolated technical restore
- Service: end-to-end dependencies
- Enterprise: crisis, suppliers and business
- Documented progression and limitations
3. Demonstrate a clean recovery path
Recovery starts with identity and administrative control. The team must access copies without compromised mechanisms, protect keys and operate in an isolated environment. It then selects a recovery point using integrity and timeline—not only the newest timestamp.
Validation includes artifact analysis plus configuration, accounts, persistence and business data. Criteria for declaring an environment clean must be agreed in advance with people authorized to accept residual risk.
- Recovery and break-glass accounts tested
- Separate console and repository access
- Isolated restoration environment
- Clean recovery-point selection criteria
- Return approval and residual risk
4. Recover the service in dependency order
A restored database is not an available service. Identity, DNS, network, certificates, secrets, application, integration and monitoring return in an explicit order. Business owners confirm transactions and data are usable—not merely that a process starts.
Runbooks should be executable by roles rather than indispensable individuals. Record every step, decision, wait and rollback. Knowledge existing only in an administrator’s memory becomes an explicit dependency and action.
- Service-led restore sequence
- Configuration, keys, certificates and DNS
- Technical and functional validation
- Monitoring before reconnection
- Explicit production-return criteria
5. Measure time and turn blockers into investment
Measure time to backup access, copy selection, each dependency restore, functional validation and return decision. Compare results with RTO/RPO without hiding analysis, approvals, data transfer or supplier waits.
Separate architecture defects, missing data, manual steps, skill gaps, contractual dependencies and unclear decisions. Give every blocker an owner, priority, deadline and test proving closure.
- Technical and decision time separated
- Actual data loss compared with RPO
- Manual steps and single points of knowledge
- Supplier and contract dependencies
- Critical blocker retest scheduled
Recovery exercise questions
Is a backup restore test enough?
No. Restoration checks data or systems. Cyber recovery includes identity, a clean environment, service dependencies, validation and a safe return decision.
Must the exercise run in production?
Not necessarily. An isolated environment can validate much of the path safely. Document differences and assumptions that remain untested.
How often should it be repeated?
Frequency follows criticality and change. Repeat after major changes and often enough that roles and runbooks remain executable.
Does immutability guarantee recovery?
No. It protects certain copies from change, while recovery still depends on identity, keys, configuration, integrity, capacity, dependencies and people.
Official technical sources
NIST updates ransomware resources periodically; verify current versions before a major program.
Turn backup into a demonstrated recovery capability.
We assess architecture, build the scenario and measure recovery with technical and business teams.