Free Data Backup and Recovery Policy Template and Generator

This policy sets the rules for how [Company Name] (the "company") backs up its systems and data, protects those backups, proves they work, and uses them to recover. Its goal is to make sure the company never loses data it cannot recreate, and can restart critical operations within agreed times after hardware failure, human error, software defects, cyberattacks including ransomware, natural disasters, or the failure of a vendor.

Guiding principle. A backup is only as good as the last successful restore. Backups that are not monitored, protected from attackers, and regularly restored are not considered reliable under this policy.

The policy is designed to align with the NIST Cybersecurity Framework 2.0 and CISA ransomware guidance, and to support the company in meeting its legal, regulatory, insurance, and contractual obligations. It does not replace those obligations. Where a law, regulation, or contract sets a stricter requirement, the stricter requirement applies.

People. This policy applies to all employees, officers, temporary workers, contractors, and service providers who create, store, manage, or back up information for [Company Name] ("personnel").

Systems and data. It covers the following, wherever the company has them, whether they are on company premises, in a data center, or in the cloud:

• Company data in Microsoft 365, including Exchange Online mailboxes, OneDrive, SharePoint sites, and Teams.
• Physical servers and virtual machines, including their operating systems, applications, configuration, and data.
• Company files on laptops and desktops. User folders must be stored in, or synchronized to, company-managed storage that is itself backed up, or be backed up directly. Devices are otherwise rebuilt from a standard image rather than restored.
• Line-of-business applications and their databases, such as ERP, accounting, payroll, estimating, CRM, and inventory systems, backed up in a way the application vendor supports so the restored data is consistent.
• Configurations of firewalls, switches, routers, wireless controllers, and other network and security devices, saved after every change and at least weekly.
• Servers, databases, and storage that the company runs in public cloud platforms such as Microsoft Azure, Amazon Web Services, or Google Cloud.
• Other cloud (SaaS) applications that hold company records, such as CRM, accounting, HR, and project management platforms.
• The backup systems themselves, including their configuration, encryption keys, and recovery documentation.

Where files must be stored. Personnel must keep company files in approved, company-managed locations that are backed up. Files kept only on USB drives, personal cloud accounts, or personal devices are not protected by this policy and must not be the only copy of company information.

Out of scope. Personal information that personnel keep on personal devices for personal use, and copies of data the company is not permitted to keep. Backups are not a records archive: long-term record keeping is governed by the company record retention schedule.

Backup

A separate copy of data, configuration, or an entire system, kept so it can be restored after loss, corruption, or compromise. Synchronization, replication, mirroring, and RAID are not backups on their own, because they copy deletions and encrypted files along with good data.

Restore point

A backup of a system or data set as it existed at a specific date and time.

Recovery point objective (RPO)

The maximum amount of data, measured in time, that the company accepts losing. A 4-hour RPO means no more than the last 4 hours of changes may be lost.

Recovery time objective (RTO)

The target time to restore a system to working order after it becomes unavailable.

Immutable backup

A backup stored so that it cannot be changed, encrypted, or deleted by anyone, including administrators, until a set retention period has passed.

Offline (air-gapped) copy

A backup on media or storage that is disconnected from company networks and systems, so an attacker who controls the network cannot reach it.

Isolated copy

The immutable or offline backup copy that this policy requires to survive a ransomware attack or a compromised administrator account.

3-2-1-1-0 rule

Keep three copies of data, on two different types of storage, with one copy offsite, one copy immutable or offline, and zero errors, proven by monitoring and restore testing.

Data tier

The criticality level assigned to a system or data set, which sets its backup frequency, RPO, and RTO.

Restore test

A documented exercise in which data or a system is restored from backup and checked to confirm it is complete and usable.

Disaster recovery

The documented and tested process for restoring systems and operations after a major outage, in an agreed priority order.

SaaS (software as a service)

A cloud application the company uses but does not host, such as Microsoft 365, Google Workspace, CRM, or accounting platforms.

Shared responsibility model

The division of duties between a cloud provider and its customer. The provider runs the service and its infrastructure, while the customer remains responsible for its own data, accounts, and access.

Legal hold

A written instruction to preserve information, including backups, that may be relevant to litigation, an investigation, or an audit, overriding normal deletion.

Service provider oversight. Using a managed IT service provider does not transfer accountability. The contract must define the provider's backup, monitoring, testing, and reporting duties under this policy, and [Company Name] must keep its own administrator access to its backups, or a documented and tested way to obtain them, so it can recover even if the relationship ends or the provider is unavailable.

System register. The IT Manager keeps a register of every in-scope system, recording its data tier, system owner, backup method, storage locations, retention, and the date and result of its last restore test.

Every in-scope system must be protected according to the 3-2-1-1-0 rule. [Company Name] meets each element as follows:

Local copies. The local backup copy must be stored on a system dedicated to backups, not on a file share or a server that users can reach, and must not be the only copy of any data.

Consistent backups. Databases and applications must be backed up using methods that produce a consistent, restorable copy, following the application vendor guidance. Copying open database files is not an acceptable backup method.

Each system owner assigns every in-scope system to a data tier, with the agreement of the policy owner. The tier sets the minimum backup frequency and the recovery targets. The examples below are typical; the system register is the authoritative record.

Backup frequency. Backups must run at least as often as the RPO for the tier, and at least daily for any system that holds business records. For example, a 4-hour RPO requires a successful backup at least every 4 hours.

How targets apply. Recovery time targets apply to the loss of a single system or site. When a ransomware attack or other incident affects many systems at once, restoration begins only after the environment is confirmed clean, systems are restored in the priority order in this policy, and the targets are measured from the time a clean recovery environment is ready. When recovery has to use the isolated copy, data loss can exceed the RPO, up to the age of that copy.

Targets that cannot be met. If a restore test shows that a system cannot meet its RPO or RTO, the IT Manager records the gap and a remediation plan in the system register, and the Chief Executive Officer either approves the resources to close it or accepts the risk in writing.

Shared responsibility. Cloud providers are responsible for running their services and infrastructure. [Company Name] remains responsible for its own data, accounts, and access in every cloud service it uses. A provider keeping a service available is not the same as the provider keeping a recoverable copy of the company data.

Microsoft 365. Company data in Exchange Online mailboxes, OneDrive, SharePoint sites, and Teams must be backed up by a dedicated backup service. Recycle bins, version history, retention policies, and litigation hold features are useful for recent mistakes but are not a substitute, because they have limited time windows and sit in the same tenant, under the same administrator accounts an attacker may compromise. At least one copy of this data must be stored outside the production tenant or protected so that a compromised tenant administrator cannot delete it.

Identity and configuration. Where tools allow, the configuration of the company cloud identity and email platform, such as users, groups, security policies, and sharing settings, must be backed up or exported and documented so it can be rebuilt.

Cloud servers and databases. Snapshots kept in the same cloud account as production are not backups under this policy. Cloud backups must be copied to a separate account, subscription, or region with its own credentials, and at least one copy must be immutable. Templates and scripts used to build cloud resources must be version controlled and backed up so the environment can be redeployed.

Other SaaS applications. For each other SaaS application that holds company records, the system owner must confirm what the vendor backs up, how long it keeps it, whether the company can request a restore, and how data can be exported. Where the vendor does not provide restores the company needs, data must be exported or backed up at a frequency that matches its tier.

Backup vendor requirements. Any vendor that stores company backups must, in its contract: encrypt data in transit and at rest; state where data is stored; notify the company promptly of security incidents affecting its data; provide independent security assurance such as a SOC 2 Type II report or ISO/IEC 27001 certification; and return or delete company data, with written confirmation, when the service ends.

Backups contain the same information as production systems and are a primary target for attackers. They must be protected at least as strongly as the systems they copy, including the following controls:

• Encryption: all backups must be encrypted in transit and at rest using current industry-standard encryption, such as AES-256 at rest.
• Encryption keys: keys and passphrases must be managed by the company, stored separately from the backups they protect, and kept in a secure, documented escrow location that remains accessible when company systems are down. A lost key means a lost backup.
• Multi-factor authentication: every backup console, backup storage account, and cloud backup service must require multi-factor authentication, using phishing-resistant methods where the service supports them.
• Separate credentials: administrator access to backup systems must use dedicated accounts that are not used for any other purpose and are not members of the production Windows domain. Backup servers and storage should not be joined to the production domain. A stolen domain or email administrator account must not be enough to delete or change backups.
• Least privilege: only named, authorized people may administer backups or perform restores. Shared accounts are not permitted, and access is reviewed at least quarterly and removed promptly when someone changes role or leaves.
• Deletion protection: deleting backups, shortening retention, or disabling immutability must require a second authorized person or a built-in delay where the service supports it, and must generate an alert to the policy owner.
• Network isolation: backup storage must sit on a restricted network segment and must not be reachable as a file share from user devices or general-purpose servers.
• Patching: backup software, appliances, and agents must be kept on supported versions and patched promptly, because attackers actively exploit backup software vulnerabilities.
• Physical media: removable backup media must be encrypted, labeled without revealing its contents, logged when it moves, and stored and transported securely.

Restores are controlled. Restores of data to anyone other than its original owner, and any restore of a full mailbox, drive, or system, must be requested through the IT Manager and approved by the system owner, so backups cannot be used to get around normal access controls.

• Every backup job must be monitored automatically, with alerts for failed, missed, or partially completed jobs sent to the backup operator.
• A failed or missed backup must be investigated and either fixed or successfully rerun within 24 hours of the alert.
• Any system without a successful backup for twice its scheduled interval must be escalated to the IT Manager.
• Alerts must also be raised for unusual backup activity, such as sudden spikes in changed data, which can signal ransomware, and for changes to backup retention or deletion settings.
• At least monthly, the backup operator must compare backup coverage with the system register and the list of company systems, users, and SaaS applications, so new servers, mailboxes, and sites are not silently left out.

Reporting. The backup operator reports job success rates, open failures, coverage gaps, storage capacity, and restore test results to the IT Manager at least monthly. The IT Manager summarizes backup status, risks, and gaps against recovery targets for the Chief Executive Officer every quarter.

Restore tests. The backup operator must perform documented restore tests at least once a quarter. Each round of testing must include:

• A full restore of at least one Tier 1 system into an isolated test environment, confirmed by its system owner to start and hold complete, usable data. Every Tier 1 system must be fully restored at least once a year.
• Restores of individual files, a database, and data from Microsoft 365, such as a mailbox item and a shared file.
• A record of the date, system, restore point used, its age compared with the RPO, the time the restore took compared with the RTO, the result, and any problems found.

Automated checks that a backup can be mounted or started are valuable and count toward the "zero errors" requirement, but they do not replace hands-on restore tests. A failed restore test must be reported to the policy owner, corrected, and retested within 30 days.

Disaster recovery exercise. The IT Manager must run a disaster recovery exercise at least once a year, with the Chief Executive Officer and system owners taking part. Each exercise must include:

• A tabletop walk-through of realistic scenarios, such as a ransomware attack, the loss of the main site, a cloud tenant compromise, and a key person being unavailable.
• A technical recovery of Tier 1 systems from the isolated copy, not only from the local copy.
• A check that recovery runbooks, contact lists, and encryption key escrow are current and can be reached without company systems.
• A written summary of lessons learned, with owners and dates for each corrective action.

After major changes. A restore test is also required before relying on a new backup platform, a new Tier 1 system, or a major upgrade to a Tier 1 system.

Declaring a disaster. The Chief Executive Officer, or the IT Manager when the Chief Executive Officer cannot be reached, decides when an outage is a disaster and invokes these procedures. The decision and its time are recorded.

Recovery runbooks. The backup operator must maintain a written runbook for each Tier 1 system, covering its dependencies, restore steps, checks to confirm it works, vendor support contacts, and license information. Runbooks, the system register, an emergency contact list, and encryption key escrow instructions must be kept where they can be reached when company systems are down, such as a secured printed copy and a copy in storage that does not depend on company accounts.

Recovery priority. Unless the circumstances require otherwise, systems are restored in this order:

1. Out-of-band communication for the recovery team and leadership, which may be a temporary tool that does not depend on company systems.
2. The backup system itself and administrator access to it.
3. Core network and security controls, such as internet connectivity, firewalls, and endpoint protection.
4. Identity services, such as directory, authentication, and multi-factor authentication.
5. Tier 1 applications, in the order recorded in the system register.
6. Email and collaboration in Microsoft 365, if they are not already available.
7. Tier 2 systems, then Tier 3 systems.

The Chief Executive Officer may change the order for business reasons during an event, and the change is recorded.

Working during an outage. Each owner of a Tier 1 system must document how the business will keep working while that system is down, such as manual order taking, paper time records, or printed pick lists, and how that work will be entered once the system is restored.

Everyday restores. Personnel request the restore of a deleted or damaged file, message, or folder through the IT Manager. Report accidental deletion promptly, because restore points age out under this policy.

When data loss is caused, or may have been caused, by ransomware or another cyberattack, recovery follows the company incident response procedures and these additional rules:

• Do not restore into an infected environment. Restoration into production begins only after IT and security, and any outside incident response firm, confirm the attacker has been contained and removed. Restoring too early can reinfect clean systems or re-encrypt restored data.
• Protect the backups first. At the first sign of an attack, confirm the isolated copy is intact, and, where the backup platform allows, suspend automatic deletion of restore points that may be needed for recovery or as evidence.
• Restore to a clean, isolated environment first. Scan restore points for malware and signs of attacker persistence, and select the most recent restore point from before the compromise, which may be earlier than the most recent backup.
• Rebuild compromised systems from trusted installation media or known-good images, then restore data, rather than restoring a possibly compromised operating system.
• Reset credentials before reconnecting systems, including administrator, service, and backup accounts.
• Preserve evidence. Do not wipe, reimage, or overwrite affected systems or backups until counsel and the incident response lead confirm what must be kept.
• Notify the company cyber insurance carrier promptly as the policy requires, since many policies set notice deadlines and require the use of approved response firms.
• Any decision about paying a ransom is made only by the Chief Executive Officer with legal counsel, and must consider sanctions laws and guidance from law enforcement. A tested, isolated backup is what makes refusing to pay possible.

Backups of regulated data are subject to the same legal requirements as the original data. The following additional rules apply:

Personal information. Unauthorized access to a backup, or the loss or theft of backup media, that contains personal information may be a security breach under the data breach notification laws of North Carolina and of every state where affected individuals live. Many of these laws treat properly encrypted data differently when the key is not also compromised, which is one reason every backup must be encrypted. Where a privacy law gives individuals a right to have personal information deleted, that information is removed from backups as they age out, and deleted data is not put back into production from a backup unless the deletion is applied again, except where the law allows otherwise.

Backups are not archives. Restore points are deleted automatically when their retention period ends. Records that must be kept for years, such as financial, tax, personnel, quality, or contract records, must be kept under the company record retention schedule in an archive or the system of record, not by keeping backups longer. Where a law, regulation, or contract requires a longer or shorter retention for backups, that requirement applies.

Legal hold. When legal counsel or the Chief Executive Officer issues a legal hold, the IT Manager must promptly suspend deletion of the restore points and media that may contain the information covered by the hold, record what was preserved, and keep it until the hold is released in writing. A legal hold overrides every retention period in this policy.

Secure disposal. Backup media, drives, tapes, and appliances that are retired, fail, or leave company control must be sanitized or destroyed following NIST SP 800-88 Rev. 2, using cryptographic erase or physical destruction appropriate to the media and the sensitivity of the data. Destruction by a vendor must be supported by a certificate of destruction, and every disposal must be logged. When a cloud backup service ends, the vendor must confirm in writing that company data has been deleted.

Exceptions. Requests for an exception must be made in writing to the IT Manager, explaining the business need, the risk, and the compensating controls. The IT Manager may approve exceptions for Tier 2 and Tier 3 systems. Exceptions affecting Tier 1 systems, the isolated copy, encryption, or regulated data also require approval by the Chief Executive Officer. Every exception is recorded in the system register, limited to no more than 12 months, and reviewed before renewal. No exception can permit a practice that breaks the law or a contract.

Enforcement. Disabling or interfering with backups, deleting or altering backups without authorization, using backups to access information without approval, or keeping the only copy of company information outside approved locations may result in loss of access and disciplinary action, up to and including termination of employment or of a contractor agreement, consistent with applicable law. Service providers that fail to meet this policy are subject to the remedies in their contracts.

Policy review. The IT Manager reviews this policy no later than September 27, 2027, and sooner after a disaster recovery exercise or significant incident that reveals a gap, the addition of a new Tier 1 system, a change of backup platform or provider, or a new legal or contractual requirement.

• NIST Cybersecurity Framework (CSF) 2.0, subcategory PR.DS-11 (backups of data are created, protected, maintained, and tested) and the Recover function.
• CISA #StopRansomware Guide.
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems.
• NIST SP 800-88 Rev. 2, Guidelines for Media Sanitization.
• CIS Critical Security Controls v8.1, Control 11: Data Recovery.

Related company policies. This policy works together with the [Company Name] information security, incident response, acceptable use, and record retention policies, where adopted. If they conflict, the stricter requirement applies.

Revision history. Record every change to this policy below. Increase the document version and obtain approval again each time the policy is revised.

This document was generated from a starter template provided by Preferred Data Corporation. It is general information only. It is not legal advice and it is not a substitute for advice from a licensed attorney.

Preferred Data Corporation is not a law firm. It makes no representation that this document is complete, current, or suitable for any particular organization, industry, jurisdiction, or regulatory requirement, and it is not responsible or liable for any use of this template or of any policy created from it. You are solely responsible for how you adapt, adopt, and enforce it.

Laws, regulations, insurance requirements, and contracts that apply to your organization may require different or additional terms. Before you adopt, publish, or rely on this policy, and in every case where you have a legal, regulatory, or contractual obligation, have it reviewed by qualified legal counsel.