A Backup Policy defines what data must be backed up, how frequently, where backup copies are stored, how long they are retained, and how they are protected. It also establishes testing requirements — because a backup that has never been tested is not a backup. It is a file that may or may not restore when you need it most. Organizations discover the inadequacy of their backup practices almost exclusively in the worst possible circumstances: during a ransomware attack, a hardware failure, or a natural disaster. By then, it is too late to fix the policy.
Data loss is one of the most operationally and financially damaging events a business can experience. The 2023 IBM Cost of a Data Breach report estimated average breach costs in the millions, but even non-security data loss events — accidental deletion, database corruption, storage hardware failure — can shut down operations for days or permanently destroy records. Regulatory frameworks that require data availability and integrity make backup not merely a good operational practice but a compliance obligation.
The threat environment has also shifted the stakes of backup policy in fundamental ways. Ransomware attacks specifically target backup systems: modern ransomware variants will seek out and encrypt or delete connected backup drives before encrypting primary data, knowing that destroying backups eliminates the victim’s ability to recover without paying. A backup policy that does not address this threat is not adequate for today’s environment.
What Is a Backup Policy?
A Backup Policy is a formal document that governs the creation, storage, protection, testing, and retention of copies of organizational data. It applies to all systems and data that are classified as business-critical or that contain information subject to regulatory retention requirements. This includes production databases, file servers, application data, configuration files, source code repositories, email archives, and any other data whose loss would materially impair business operations or create compliance exposure.
The policy defines backup requirements based on data classification and criticality. Not all data needs to be backed up with equal frequency or retained for equally long periods. Customer records and financial data may need daily or continuous backup with multi-year retention. Internal drafts or temporary files may need less frequent backup or no backup at all. The policy establishes these distinctions so that backup resources are allocated appropriately and so everyone responsible for backups understands what is in scope.
Core Concepts: RPO and RTO
Two concepts are foundational to any backup policy discussion, and they are frequently confused or ignored: Recovery Point Objective (RPO) and Recovery Time Objective (RTO). These are not technical terms to be left to IT — they are business decisions that leadership must make, because they define how much data loss and operational downtime the organization can tolerate.
Recovery Point Objective (RPO)
RPO is the maximum amount of data, measured in time, that the organization can afford to lose. If your database is backed up once a day at midnight and a failure occurs at 11:45 PM, you will lose up to 23 hours and 45 minutes of transactions. If your RPO is 24 hours, that is acceptable. If your RPO is 4 hours — because you process a significant volume of transactions every day that cannot be recreated — then nightly backups are insufficient and you need more frequent backup intervals or continuous data replication. RPO drives backup frequency.
Recovery Time Objective (RTO)
RTO is the maximum amount of time the organization can tolerate being without a system or data set after a failure. If your RTO for your order management system is 4 hours, you need to be able to restore from backup and resume operations within 4 hours. If it takes 12 hours to restore a large database from tape backup, your RTO cannot be 4 hours — and you need a different backup architecture (faster storage, standby systems, or cloud-based recovery). RTO drives backup architecture and restoration procedures.
Business leaders need to set RPO and RTO values for each critical system as part of the backup policy definition process. These decisions should reflect real business impact — how much does an hour of downtime cost? How much transaction data is generated per hour? Can manually re-entered data substitute for automated backups? Once RPO and RTO are defined, the technical team can design backup procedures to meet those objectives, and the policy documents the requirements and the approach.
What the Policy Must Cover
Backup Methods
Three primary backup methods are in common use, and most backup strategies combine them. A full backup captures a complete copy of all designated data. It is the most comprehensive approach but also the most time-consuming and storage-intensive. An incremental backup captures only the data that has changed since the last backup — whether full or incremental. It is faster and more storage-efficient but requires restoring the last full backup plus all subsequent incrementals, which increases restoration time and complexity. A differential backup captures all data that has changed since the last full backup. It requires more storage than incremental but less than full, and restoration requires only the last full backup plus the last differential — simpler than chaining multiple incrementals. The policy should specify which method or combination of methods is used for each system or data category and why.
Backup Destinations and the 3-2-1 Rule
Where backup copies are stored is at least as important as the backup frequency. The 3-2-1 rule is the industry-standard baseline: maintain at least three copies of data, on at least two different media types, with at least one copy stored off-site. In practice, this means having a local backup for fast recovery, an off-site backup (cloud or physical media at a separate location) for disaster recovery, and a third copy that provides additional redundancy. A backup stored only on a drive connected to the same server being backed up is not a backup — it is a duplicate that will be destroyed in the same fire, flood, or ransomware event that takes down the primary.
Immutable and Air-Gapped Backups
The rise of ransomware has made immutable and air-gapped backups essential for organizations with meaningful data assets. An immutable backup is one that cannot be modified or deleted for a defined period after creation — it is written once and locked. Cloud storage services like AWS S3 with Object Lock and Azure Blob Storage with immutability policies support this. An air-gapped backup is physically or logically isolated from the network — a tape or drive that is disconnected after the backup job completes, for example. Ransomware can only encrypt what it can reach. If your most recent backup is neither connected to your network nor modifiable by your systems, it survives a ransomware attack. The policy should specify that at least one copy of critical data backups must be either immutable or air-gapped at all times.
Encryption of Backup Data
Backup copies contain the same sensitive data as production systems — sometimes more, because older backups may contain data that has been deleted from production. All backup data should be encrypted, both in transit during the backup process and at rest in backup storage. Encryption keys must be stored separately from backup data — a common mistake is to encrypt backups and then store the decryption key on the same system or in the same backup set, effectively rendering the encryption useless in a scenario where the backup system itself is compromised.
Retention Periods
Backup retention defines how long backup copies are kept before they are purged. Retention periods should reflect both business recovery needs and regulatory requirements. Some regulations mandate minimum retention periods for specific data categories — HIPAA requires covered entities to retain documentation of their security policies for at least six years, and some state laws require records to be retained for specific periods. Backup retention should be long enough to support recovery from scenarios where damage is not immediately detected — ransomware can lie dormant for weeks before activating, and a backup from three days ago may already contain encrypted files. Many organizations maintain daily backups for 30 days, weekly backups for 90 days, and monthly backups for one year as a baseline.
Testing and Restoration Verification
A backup is not a backup until it has been successfully restored. This is not a philosophical statement — it is a practical one. Backup failures happen silently. A job that has been ‘succeeding’ for months may be producing corrupted data, backing up the wrong directories, or completing only partially. Storage media degrades. Configuration changes in production systems can break backup jobs without triggering alerts. The only way to know that your backups are functional is to periodically restore from them and verify that the restored data is complete and usable. The policy should require at least quarterly restoration testing for critical systems, with documented results. For organizations with high RPO/RTO requirements, monthly or more frequent testing may be appropriate.
Roles and Responsibilities
The policy should clearly assign ownership. Typically, the IT team or a specific IT role owns the technical execution of backup procedures. A manager or director owns the policy itself and is accountable for ensuring it is followed. Business unit leaders are responsible for identifying which data in their area is business-critical and communicating classification decisions to IT. The policy should also specify who is authorized to initiate restoration requests and what the process is for recovery in an emergency.
Regulatory and Compliance Drivers
HIPAA Contingency Plan Requirements
HIPAA’s Security Rule requires covered entities and business associates to implement a contingency plan that includes a data backup plan, a disaster recovery plan, and procedures for emergency mode operation. The data backup plan specifically requires creating and maintaining retrievable exact copies of electronic protected health information. HIPAA does not prescribe specific backup frequencies or methods, but it requires covered entities to conduct a risk analysis and implement contingency measures that are reasonable and appropriate for their size and risk profile. A documented backup policy, regular testing, and evidence of restoration capability are essential to demonstrating HIPAA compliance.
SOC 2 Availability Criteria
SOC 2’s Availability Trust Services Criterion requires service organizations to demonstrate that their systems are available for operation and use as committed. Backup and recovery capabilities are a core component of availability controls. SOC 2 auditors will look for a documented backup policy, evidence that backups are performed according to the policy, documentation of backup monitoring and alerts, and evidence of restoration testing. Organizations pursuing or maintaining SOC 2 Type II certification need to demonstrate operating effectiveness over time, which means backup logs and test results need to be retained.
ISO 27001 Annex A.12.3
ISO 27001 Annex A.12.3 addresses information backup, requiring organizations to make backup copies of information, software, and system images and to test them regularly in accordance with an agreed backup policy. The standard requires that backup copies be stored in a separate location at sufficient distance to avoid damage from a disaster at the main site. Organizations seeking ISO 27001 certification must demonstrate that a backup policy exists, that it reflects the organization’s RPO and RTO requirements, and that testing is performed.
State Breach Notification and Recovery Capabilities
State data breach notification laws increasingly consider an organization’s ability to recover data as a factor in notification obligations and regulatory scrutiny. Organizations that suffer a breach and are unable to determine what data was compromised — because their systems are destroyed and their backups are either nonexistent or untested — face far greater regulatory exposure than those that can recover quickly and accurately scope the affected data. A robust backup capability directly supports the post-breach response.
Common Implementation Mistakes
Backups Never Tested
This is the most dangerous and most common mistake. Organizations set up backup jobs, confirm they run without errors, and then never test whether they can actually restore from them. Testing is uncomfortable because it takes time, requires a test environment, and sometimes reveals problems. But it is the only way to know whether your backups are usable. The policy must require testing and the organization must actually do it. Document the tests. Document any failures. Fix the failures before they matter.
Backup Media Stored Alongside Primary Data
A backup drive sitting next to the server it backs up will be destroyed in the same fire, stolen in the same burglary, or encrypted by the same ransomware. Off-site storage is not optional for critical data. Cloud backup, tape rotation to an offsite location, or synchronization to a geographically separate data center are all viable approaches. The policy must specify off-site storage as a requirement, not a nice-to-have.
Encryption Keys Stored with Backup Data
Encrypting backup data is necessary but insufficient if the decryption key is stored in the same location or backup set as the data it protects. Keys must be stored separately — in a key management service, a password manager, a separate secure vault, or some combination — with access restricted to authorized personnel. Key management procedures should be documented in the policy or a separate key management procedure.
Ransomware Encrypting Connected Backup Drives
If a backup drive or network share is mounted and accessible from systems on the network, ransomware will find it and encrypt it. This is not an edge case — it is standard behavior for most ransomware variants. The policy must require that at least one backup copy be stored in a location that is logically or physically isolated from the network — either immutable cloud storage or air-gapped physical media that is disconnected between backup operations.
Building and Maintaining the Policy
The backup policy should be owned by the IT team or CISO, with business unit input to define RPO and RTO requirements for critical systems. It should be reviewed annually and updated whenever new critical systems are deployed, major infrastructure changes occur, or a backup-related incident or near-miss reveals gaps. The policy should be integrated into the onboarding process for IT staff and included in the scope of any security assessment or audit.
Backup jobs should generate logs that are retained and reviewed. Backup failures should generate alerts that are routed to the responsible party and resolved promptly. Testing results should be documented in a format that can be presented to auditors. If your organization is small and has a limited IT team, cloud backup services with built-in testing and reporting capabilities can reduce the operational burden while maintaining the necessary rigor.
How It Connects to the Broader Policy Library
The Backup Policy operates in close relationship with several other policies. The Data Retention Policy defines how long different categories of data must be kept, which directly informs backup retention schedules — you cannot satisfy a retention requirement if your backups are purged before the required retention period expires. The Asset Management Policy governs what systems and data assets exist, which is the foundation for determining what must be backed up.
The Change Management Policy intersects with backup at a critical point: before any significant change to a production system, a current backup should be verified as a precondition of the change. This is a common requirement in change management workflows that is often honored in theory but skipped in practice. The Disaster Recovery Policy, where one exists, builds on the backup policy by defining the full recovery process for catastrophic scenarios, including the people, tools, and procedures needed to restore operations, not just the data.