Choose recovery targets, protect backup administration and test the complete path from a recovery copy to a usable service.
Agree what must be recovered
A backup plan begins with a business question: what information and services would be difficult to replace? Include databases, documents, cloud applications, configurations and the information required to rebuild access. Ask business owners to identify dependencies and seasonal pressures. A payroll service shortly before processing day may have a different recovery priority from a rarely used archive.
Define a recovery point objective, which expresses the acceptable amount of data loss in time, and a recovery time objective, which expresses the target time to restore a service. These are planning targets, not guarantees. The backup design, restoration method and available people must be able to support them. If the targets are unrealistic, resolve that gap before an incident tests the assumptions.
Distinguish synchronisation from recovery
File synchronisation is useful for collaboration, but it may also replicate deletions or unwanted changes. Version history and recycle bins can help, yet their coverage and retention vary by service. Check the provider's documented recovery capabilities and decide whether additional protection is needed. Do not assume that a cloud subscription automatically includes every recovery scenario the business expects.
For each important dataset, record what is copied, how often, where copies are retained and who can restore them. Include application consistency requirements and the encryption keys needed to read the data. Keep recovery copies protected from both ordinary operational mistakes and compromised administrator accounts. A backup that is reachable with the same stolen credentials may be vulnerable during the same incident.
Protect access and retention
Microsoft's ransomware preparation guidance discusses offline or immutable backup protection and a clear backup-and-restore plan. Choose controls that fit the environment, then verify their actual configuration. Immutability depends on retention and access settings; the word on a product page is not evidence that every backup is protected from alteration or deletion.
Use separate administrative roles where practical, strong authentication and alerts for important changes to backup policies. Review access when staff or service providers change. Document how authorised responders obtain emergency access without exposing credentials in ordinary shared folders. Retention should reflect business needs and applicable obligations, with controlled disposal when information is no longer required.
Test a complete restoration
Restore a sample from each important type of backup into an approved environment. Check that files open, databases are consistent and an authorised user can complete a meaningful business task. Record the time taken and any missing dependencies. Test more than the newest copy: an unnoticed problem may require recovery from an earlier point than the team first expects.
Keep tests separated from production transactions and external communications. A restored application should not accidentally submit orders or send duplicate messages. NIST's work on recovery from destructive events emphasises confidence in the restored information. Ask a business owner to validate representative records rather than allowing technical startup alone to define success.
Monitor failures and repeat the exercise
Assign someone to investigate failed jobs, capacity warnings and missed recovery tests. Review backup coverage whenever an important application or data location changes. Retain the results of restoration exercises and follow up on gaps. A useful report shows recoverability against business targets, not simply the total amount of data stored or the number of completed backup jobs.
