A backup retention policy answers one question that three different departments ask in three different ways. Operations asks how far back we can restore. Legal asks what must we keep, and what must we be able to stop deleting. Finance asks why the backup bill keeps growing. A policy written by only one of them fails the other two, usually at the worst moment: during an eDiscovery request, an audit, or a storage renewal.
This article is about design, not legal advice. Retention obligations depend on jurisdiction, industry, and the facts of your organization, and your counsel makes the final call on what applies. The job of the backup team is to build a system that can implement whatever counsel decides, cheaply and provably.
Separate three things that get conflated
The most common design error is treating backup retention, records retention, and legal hold as one setting.
Backups exist for recovery. Their retention should be set by how far back you may need to roll a system to reach a known-good state, which includes how long a corruption or intrusion can go undetected. That is an operational question tied to recovery point objectives and dwell time.
Records retention exists for obligation. A regulation or contract may require you to keep certain records for a stated period. That duty attaches to the records, not to the backup tape or snapshot that happens to contain them. Whenever possible, satisfy it with an archive or records system built for the purpose, with its own access controls and deletion process, rather than by hoarding backups.
Legal hold exists to suspend deletion. When litigation or an investigation is reasonably anticipated, relevant information must be preserved. Under the U.S. Federal Rules of Civil Procedure, Rule 37(e) addresses electronically stored information that should have been preserved and was lost because a party failed to take reasonable steps, so preservation failures carry sanctions risk. Counsel issues the hold. Your system must be able to apply it to specific data without freezing everything.
Keeping these separate lets you shorten routine backup retention without putting compliance at risk, and tells you exactly which data needs the expensive long-term tier.
What the actual regulations say, and what they do not
Teams often cite a retention rule that does not say what they think it says. A few precise reference points:
- HIPAA. 45 CFR 164.316(b)(2)(i) requires covered entities and business associates to retain required Security Rule documentation, such as policies, procedures, and records of actions or assessments, for six years from the date of creation or the date it was last in effect, whichever is later. That is a documentation requirement. It is not a rule that sets backup retention for patient data, and medical record retention is generally governed by state law. The Security Rule does separately require a data backup plan as part of contingency planning under 164.308(a)(7).
- SEC Rule 17a-4. Broker-dealers must preserve specified records for set periods, generally three or six years depending on the record type, with the first two years in an easily accessible location. Amendments effective January 3, 2023 removed the requirement that electronic records be kept in write-once, read-many (WORM) format, and added an optional audit-trail alternative that allows the original record to be recreated if it is altered or erased. Firms may continue to use WORM.
- PCI DSS. Under version 4.0 requirement 10.5.1, audit log history is retained for at least 12 months, with at least the most recent three months immediately available for analysis.
- NIST SP 800-53. Control AU-11 requires organizations to define their own audit record retention period consistent with their records retention policy, which makes it a requirement to decide and document rather than a fixed number. FedRAMP baselines set concrete minimums on top of this.
- GDPR. Article 5(1)(e) is the storage limitation principle: personal data kept in identifiable form no longer than necessary for the purposes of processing. It sets no number, which means you must justify one.
Notice what is missing from this list: a single universal number. Any policy that says “seven years for everything” is borrowing a figure from some other context and applying it everywhere, usually at considerable storage cost.
The deletion side of retention
Retention policy is also a deletion policy, and regulators care about both directions. The UK Information Commissioner’s Office guidance on erasure says that where a valid erasure request applies, you must take steps to address backups as well as live systems. Where data cannot be overwritten immediately in a backup, the ICO accepts putting the data “beyond use”: you must not use it for any other purpose, and it is overwritten on an established schedule. You must also be clear with individuals about what happens to their data in backups.
The design implication is that retention periods on backups are a compliance control. Short, fixed, documented periods make an erasure answer simple: the data ages out of backups within a known time. An open-ended pile of ten-year-old full backups makes the same request an operational problem. Immutable storage, discussed elsewhere on this site, complicates this further because you cannot delete before the lock expires, so set lock durations deliberately rather than at a maximum.
A tiered structure that controls cost
A practical retention design uses tiers rather than a single schedule.
- Operational tier. Frequent restore points kept for a short window, such as daily for several weeks, on fast storage. This serves the common case of accidental deletion and rollback.
- Medium-term tier. Weekly and monthly restore points kept for months, under a grandfather-father-son rotation, covering slow-burn corruption and intrusion that went unnoticed.
- Long-term tier. A small set of yearly or event-driven copies on cheaper, offline or object-storage media, retained only where an obligation or business need is documented.
- Hold tier. A mechanism, ideally separate, to preserve specific data sets, accounts, or time ranges under legal hold until counsel releases them.
Each longer tier should hold less data than the one before it. Incremental-forever designs and deduplication reduce the cost of the operational tier, but they make long-term copies harder to pull out as a standalone set, so decide early how a single data set is exported to the hold or long-term tier.
Operating the policy
Document the policy with an owner for each tier and a written source for each retention number: the regulation, contract, or recovery objective behind it. When a number has no source, challenge it. Review the policy at least annually and after any change in regulation, business line, or tooling.
Test the hold process before you need it. Ask legal to simulate a hold on one mailbox and one file share, and confirm backup data covering those items stops expiring, who can release it, and how that is logged. Confirm also that when the hold is released the data returns to normal expiry instead of lingering forever.
Finally, report retained backup volume by tier to finance each quarter. The conversation about storage cost goes better when the long-term tier has a stated reason for every terabyte in it, and the first time you cannot name the reason is the first thing to fix.