Prove that critical work can be restored
A backup is valuable only if it contains the right information, survives the incident and can be restored by the people available. File synchronisation, undeclared provider retention and an untested copy are not a complete recovery strategy.
Maintain more than one protected copy of critical data, separate backup administration from everyday production access, prevent easy deletion or alteration and run realistic restore tests. Define how much data can be lost and how quickly each critical service must return.
Define the recovery need first
Recovery time objective
The target time for restoring a service to an agreed usable level. Include access, configuration, integrations, people and verification—not only copying files.
Recovery point objective
The amount of recent data the organisation can tolerate losing. This determines backup frequency and whether another record of transactions is required.
Minimum viable service
The smaller set of functions, records and users that must return first while full recovery continues.
Recovery authority
The people, credentials, supplier contacts and financial authority needed to declare, fund and complete recovery.
Create a recovery inventory
| Service or data | Primary location | Protected copy | Target | Last successful restore | Owner |
|---|---|---|---|---|---|
| Customer or operational records | Application and database | Separate account, region, platform or offline media as risk requires | Agreed recovery point and time | Date, sample and result | Named service owner |
| Email and collaboration | Cloud provider | Provider retention and independent copy assessed separately | Priority users and minimum mailbox history | Export or restore test | Identity and service owner |
| Devices and servers | Managed endpoints or infrastructure | Clean build configuration, protected data and required installers or code | Minimum viable devices and systems | Rebuild exercise | Technical owner |
| Cloud configuration and integrations | Provider control plane | Exported configuration, infrastructure code or documented rebuild steps | Identity, network, permissions and critical connectors | Configuration recovery test | Platform owner |
Make backups resistant to the incident
- Backup credentials and administration are separate from ordinary user and production accounts.
- Deletion protection, immutability, offline storage or another appropriate separation limits destructive access.
- Backup systems, alerts and failed jobs are monitored.
- Copies are encrypted and recovery keys are available through protected continuity arrangements.
- Retention covers delayed discovery without keeping unnecessary personal data indefinitely.
- Restores are checked for completeness, malware, corruption, permissions and business accuracy.
- Clean systems can be rebuilt before restored data is trusted.
- Supplier failure and loss of the main identity platform are included in recovery tests.
Run a useful restore exercise
- Select a real dependency. Choose a critical database, mailbox, shared area, cloud configuration or complete service.
- Assume production access is unavailable. Test protected credentials, contacts and documentation rather than relying on the compromised environment.
- Restore to an isolated location. Check the process without overwriting useful evidence or current production data.
- Validate the result. Confirm record count, dates, attachments, permissions, integrations and whether users can complete the intended task.
- Measure and improve. Record recovery time, data loss, missing dependencies, manual work and decisions that delayed the result.
Ransomware and backup sources
The joint CISA StopRansomware Guide recommends offline or protected cloud backups and regular availability and integrity tests. The NCSC small-organisations guide also prioritises regular backups and restore testing. Obtain specialist incident advice before reconnecting or restoring into a potentially compromised environment.
Backup and ransomware recovery FAQs
Is cloud file synchronisation the same as a backup?
Not necessarily. Synchronisation may copy deletion, corruption or ransomware changes. Check version history, retention, independent recovery, administrator separation and whether the service can restore the required data at the required scale.
How often should backups be tested?
Set a schedule based on how critical the service is and how frequently it changes, then test again after material system, provider, identity or configuration changes. A small sample test does not replace an occasional full-service recovery exercise.
Should backups contain personal data forever?
No. Retention should balance recovery and delayed-discovery needs with applicable data-protection, legal and contractual requirements. Document how expired data leaves live systems and ages out of protected backup cycles.
Continue your cybersecurity decision
Use the next guide that matches the exposure, control or recovery question you still need to resolve.
