A data-protection plan should answer a practical question: if this device, account or service becomes unavailable, what work can we restore, how old will it be, and who can recover it? Start with the data and the business task. Choose storage and software after identifying the versions, dependencies and recovery time you need.
Map the work before choosing the backup
List essential files, databases, mail, cloud services and configuration records. Name an owner for each and identify dependencies such as application versions, licenses and encryption keys. A folder of database files may need an application-supported backup method to produce a consistent restore. Check the service’s documentation rather than assuming a file copy captures everything.
Agree on two targets in plain language: the maximum period of work the team can afford to lose, and the time it can afford to wait for usable service. These are often called recovery point and recovery time objectives. They are targets to test, not guarantees supplied by a backup schedule.
| Copy or process | Useful role | Question to test |
|---|---|---|
| Synchronization | Keeps working locations aligned. | Could deletion or unwanted changes propagate to the other location? |
| Backup | Provides recoverable versions under a defined policy. | Which versions survive an incident, and can we restore them? |
| Archive | Retains selected information for longer-term access. | Will formats, indexes and reading tools remain usable? |
| Forensic preservation | Protects relevant evidence with documented handling. | Who authorized collection, and how are integrity and custody recorded? |
Protect the copies and the recovery path
Keep recovery material outside the same failure boundary as the working copy. A drive left connected to a compromised computer, or a backup account controlled by the same stolen administrator credentials, may fail with the source. Decide which copies are offline, separately administered or protected by retention controls, and document how those protections are checked.
CISA’s ransomware guide recommends offline, encrypted backups of critical data and regular tests of their availability and integrity. For cloud backups, verify the actual retention, deletion privileges and recovery procedure of the selected service. A label such as “immutable” needs a defined retention period, scope and administrator model.
Protect recovery credentials and encryption keys through an approved process that remains accessible if the primary account or device is lost. Assign a second authorized recovery contact where appropriate. Keep secrets out of the worksheet; record the approved storage location or process reference instead.
Choose retention around discovery and obligations
A corrupted file can be copied successfully for weeks before anyone notices. Choose version retention that allows for delayed discovery as well as recent mistakes. Consider monthly or project milestones when the work warrants them, and record which copies are automatically aged out.
Retention has a cost and a privacy consequence. Identify contractual, organizational and legal obligations with the responsible owner before setting deletion rules. When a preservation requirement applies, coordinate it with the authorized investigation process; an ordinary backup rotation should not silently dispose of needed evidence. At retirement, use the media-disposal decision guide for optical discs and an appropriate method for other storage.
Run a restore test with an observable result
- Choose a representative task and a safe, separate test destination; get approval before restoring shared or production data.
- Record the backup version and the point in time it represents. Identify required applications and access.
- Restore the material without overwriting the working source. Record elapsed time, errors and manual steps.
- Open the result in the application that uses it. Check selected records, attachments, links and permissions against an expected result.
- Have the data owner confirm usability. Assign each gap to an owner and repeat the failed part after correction.
A successful backup job establishes that the job completed according to its checks. The restore test asks whether the team can use the result. Record both, including the age of the restored data and time needed to regain useful access. NIST SP 800-61 Revision 3 places recovery within a wider incident-response and risk-management process.
Keep the plan usable
Repeat checks after a major application change, backup-policy change, account migration or staff handover, as well as on a schedule appropriate to the data. Record the next review date and contact route. Keep recovery instructions accessible outside the system they are meant to recover.
If a real incident occurs, coordinate restoration with the response lead. A usable backup does not by itself establish that the restored system is safe to reconnect. Separate evidence preservation, incident containment and service restoration decisions.