Your backups completed overnight. But could you restore a critical service before the disruption becomes unacceptable? Ransomware protection needs preventive controls and a tested recovery plan. A successful backup proves that a copy exists; it does not prove that the organisation can restore a usable business service within its recovery target.
Attackers may also target backups, administrative accounts and recovery infrastructure to obstruct restoration. The recovery route therefore needs protection as well as the backup itself.
Set recovery objectives around business services
A recovery time objective (RTO) defines how quickly a service needs to be restored.
A recovery point objective (RPO) defines how much recent data the organisation can afford to lose, measured in time.
More frequent backups can improve the RPO without reducing the time needed to rebuild infrastructure, restore data and validate the service.
Business owners should set both objectives according to the operational impact of disruption. For example:
- Order processing: four-hour RTO
- Standard internal applications: 24-hour RTO
- Archival access: 72-hour RTO
The target also needs a clear definition of “restored”. Minimum viable operations, reduced capacity and full service represent different recovery outcomes.
That definition determines which dependencies must also recover within the target, including identity, networking, infrastructure and security services.
Backup, business continuity software and disaster recovery
Once recovery objectives are clear, the technologies supporting them need distinct roles.
| Approach | Main role | What to check |
| Backup | Retains copies of data and, depending on scope, systems and configurations. | Where will those copies be restored, and what else must be rebuilt? |
| Business continuity software | Supports impact assessments, plans, communications and exercises. | Does it only coordinate recovery, or also provide technical recovery capabilities? |
| Disaster recovery (DR) | Restores applications, infrastructure and supporting IT services. | Which workloads, dependencies and recovery responsibilities are covered? |
A continuity platform can coordinate a recovery plan without providing the infrastructure needed to restore a service.
That makes the next question whether the backup copies and recovery environment will still be usable after an attack.
Protect the backups and the route to recovery
Immutable backups use controls designed to prevent protected copies from being altered or deleted during a defined retention period.
The protection should cover four areas:
- Retention control: Changes to retention periods should be restricted and auditable.
- Privileged access: Administrative users should not have an unrestricted route to alter or delete protected copies.
- Backup coverage: The organisation should know which copies are immutable and which remain modifiable.
- Encryption keys: Recovery should not depend on keys that an attacker with compromised administrative access can destroy or disable.
An offsite backup is not automatically offline or isolated from compromised administrators.
The NCSC recommends controls including separate backup administration credentials, network segregation and protection for encryption keys.
Historical recovery points also need enough retention to prevent newer corrupted copies from displacing every usable version.
The 3-2-1 backup model can help structure where copies are held, but backup placement does not prove that a business service can meet its RTO.
Only a complete restore test can provide that evidence.
What a ransomware restore test should prove
Test the complete recovery path for a critical business service.
- Define the service: Identify the workflows, dependencies and operating capacity that count as restored.
- Test emergency access: Assume normal corporate accounts or devices are unavailable. Demonstrate access to backups, recovery instructions, encryption keys and administrative tools.
- Restore in isolation: Recover into a controlled environment and check integrity, malware indicators and application behaviour before reconnecting.
- Measure the full interruption: Include mobilisation, investigation, infrastructure preparation, restoration, validation and business release.
- Record and retest: Capture elapsed time, recovered data age, unresolved issues and action owners. Repeat failed elements after corrective work.
The test should show whether the service can be restored safely within its target, not simply whether files can be recovered.
Worked example: a four-hour target missed
A hypothetical order-processing service has a four-hour RTO.
A recovery exercise takes:
- Two hours for mobilisation and infrastructure preparation
- Two hours for restoration
- 90 minutes for security and application checks
- One hour for business acceptance
Total recovery time is 6.5 hours – 2.5 hours beyond the target.
The useful finding is not that the backup failed. It is that preparation and validation are preventing the service from meeting its RTO.
Those delays can then be addressed and retested.
Compare disaster recovery approaches on time, cost and responsibility
Once the recovery process is understood, the DR model determines how much infrastructure is kept ready before an incident and how much rebuilding remains during recovery.
- Backup and restore: Carries lower ongoing infrastructure cost but leaves more systems and dependencies to rebuild during an incident.
- Pilot light: Keeps essential components available while additional services are started or scaled during recovery.
- Warm standby: Maintains a functioning environment at reduced capacity, reducing the work required after disruption.
- Full-capacity standby: Keeps more recovery capacity immediately available but requires greater ongoing investment.
Faster failover does not automatically provide safer ransomware recovery. Replication can also copy corrupted data or malicious changes into the recovery environment.
A DR service therefore needs to demonstrate recovery from a trusted historical point as well as failover between healthy systems.
For disaster recovery as a service (DRaaS), responsibilities should be explicit:
- Activation: The contract should define who can declare a recovery and start the service.
- Recovery-point validation: Responsibility for investigating suspicious or compromised restore points needs a named owner.
- Out-of-hours support: Support coverage and escalation routes should match the organisation’s recovery requirements.
- Reconnection: Authority to return recovered systems to production should be clear.
- Exercises: The service scope should state which recovery tests are included and how often they can be run.
- Commercial model: Recovery compute, storage, data transfer and return to production should be included in the cost assessment.
Evidence from exercises involving comparable workloads and dependencies provides a stronger basis for comparison than a generic platform demonstration.
Supplier response time and restoration time should also remain separate commitments. A provider can respond quickly without restoring the service within its RTO.
Bring a clearer requirement to the conversation
Ransomware resilience depends on whether critical services can be restored safely within their recovery targets, not simply whether backups exist.
A strong requirement should define the RTO, acceptable data loss, service dependencies and evidence expected from restore testing. That gives backup and disaster recovery providers a clear basis for demonstrating how their service would perform during a real recovery.
The Cyber Secure Forum brings security and IT decision-makers together with relevant providers through pre-arranged one-to-one meetings.
Organisations reviewing backup, DRaaS or wider recovery capabilities can meet providers against their recovery objectives and use those requirements to guide supplier conversations.
Frequently asked questions
What is a good RTO for ransomware recovery?
There is no universal figure. Set it from the business impact of disruption, then test whether your arrangements can meet it at the required operating capacity. An objective is not a guaranteed result.
Is immutable backup enough on its own?
No. Immutability protects retained copies against specified changes; it does not establish that the data was clean when captured or that applications will work after restoration. Verification and recovery testing remain necessary.
How often should we test our backups?
The NCSC recommends regular restore testing. An illustrative starting schedule is monthly sample restores, quarterly critical-service exercises and an annual cross-functional scenario. Adjust this to risk and system changes; it is not an NCSC-prescribed timetable.
Image credit: https://unsplash.com/photos/quick-scan-button-on-a-blue-background-Tol3g-7rmXc
