A backup retention policy sets how long each backup is kept, how many restore points survive at each age, which copies are locked against deletion and how expired copies are destroyed. As of October 2026, none of the regulations or standards reviewed here sets a universal backup retention period: the length comes from recovery needs and how far back a clean restore point may sit, capped by privacy rules and extended by legal holds and records schedules, which are separate obligations. Where a rule names a period, it covers specific records, such as the six years HIPAA sets for Security Rule documentation in 45 CFR 164.316(b)(2)(i).
For related research, see Enterprise Techie’s topic index.
In this guide
Key facts
| Item | What the sources say |
|---|---|
| Policy contents | Frequency and retention per tier, locking, regulations, deletion and restore procedures (NIST SP 800-209) |
| Records and legal holds | Separate obligations with their own schedules and triggers |
| Time vs count | Keep backups for a fixed time period, not a fixed number (UK NCSC) |
| Immutability | Strict locks can’t be shortened; locked data is billed until it expires |
| Explicit periods | HIPAA documentation: 6 years; SEC 17a-4(a): not less than 6 years; SEC 17a-4(b): not less than three years |
| Universal backup period | None found in the sources reviewed |
Backup retention vs records retention
Backup retention answers an operational question: how far back can a system be restored? Records retention answers a legal one: how long must, or may, information exist? NIST SP 800-209 notes that data retention “is usually satisfied by keeping a copy of data on some backup medium,” which is why the two blur.
Records authorities keep them apart. For US federal agencies, NARA’s General Records Schedule 3.2 (January 2023) covers backups “maintained for potential system restoration” and lets full backups be destroyed “when second subsequent backup is verified as successful or when no longer needed for system restoration, whichever is later.” The schedule “does not apply to system data or content.”
Legal holds are a separate trigger. The 2015 committee note to Federal Rule of Civil Procedure 37(e) says many court decisions recognize “a duty to preserve relevant information when litigation is reasonably foreseeable,” and that “the prospect of litigation may call for reasonable steps to preserve information by intervening in that routine operation.” Automated pruning is routine operation, so the policy needs a documented way for legal to suspend expiry for specific data.
Privacy law pushes the other way. GDPR Article 5(1)(e) limits storage of identifiable personal data to “no longer than is necessary,” and Recital 39 says “time limits should be established by the controller for erasure or for a periodic review.” Under UK GDPR, the ICO’s erasure guidance says erased data may remain in backups “until it is overwritten,” provided the backup data is put “beyond use” and replaced “in line with an established schedule.”
This article is not legal advice.
Regulatory periods that are explicit
A few rules state periods outright, each for specific records, not backups.
| Rule | Primary text | Covers |
|---|---|---|
| HIPAA, 45 CFR 164.316(b)(2)(i) | “Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.” | Security Rule policies, procedures and required records |
| HIPAA, 45 CFR 164.308(a)(7)(ii)(A) | “create and maintain retrievable exact copies of electronic protected health information” | Data backup plan; no period stated |
| SEC Rule 17a-4(a) | “not less than 6 years, the first two years in an easily accessible place” | Specified broker-dealer records |
| SEC Rule 17a-4(b) | “not less than three years, the first two years in an easily accessible place” | Other listed broker-dealer records |
HHS says the HIPAA Privacy Rule “does not include medical record retention requirements”; state laws generally govern those. SEC 17a-4(f) sets conditions for electronic recordkeeping, including a time-stamped audit trail or a “non-rewriteable, non-erasable format,” so backups that are the only copy of regulated records need assessing as a records system. And GDPR Article 32(1)(c) still expects “the ability to restore the availability and access to personal data in a timely manner.”
Retention schemes: GFS, time-based and count-based
| Scheme | What it keeps | Documented example | Watch for |
|---|---|---|---|
| Count-based | A fixed number of restore points | Proxmox keep-last | Extra or corrupted backups push good points out |
| Time-based | Points newer than a set age | Veeam short-term retention, in days | How the product counts days |
| Period buckets | The latest backup per hour, day, week, month or year | Proxmox keep-daily, keep-weekly, keep-monthly | Periods without backups don’t count |
| Grandfather-father-son (GFS) | Weekly, monthly and yearly flags on full backups | Veeam long-term retention | Needs a full backup in each period |
Veeam’s Grandfather-Father-Son (GFS) policy doesn’t create special backup files: it flags full backups as weekly (W), monthly (M) or yearly (Y) points, and a flagged file can’t be deleted or modified until its flags expire. Monthly GFS therefore needs at least one full backup a month.
The UK NCSC’s ransomware-resistant backup principles prefer time: “Store backup data according to a fixed time period, rather than a fixed number of backups,” which “prevents an attacker overwriting the backup store with a series of corrupted backups in quick succession.” Veeam Backup & Replication 13 sets short-term retention in days and deprecates the restore-point option for new jobs.
Counting differs by product. Veeam counts days with no backups, keeps points for N + 1 days and by default retains at least 3 restore points. In Proxmox Backup Server‘s keep-daily option, “days without backups do not count.” A policy that says “[N] days” should state which behavior it means. Proxmox’s documentation recommends keeping more than the minimum, because “you cannot recreate backup snapshots from the past,” and provides a prune simulator for checking settings.
How retention interacts with immutability
A lock turns a retention setting into a commitment:
- Amazon S3 Object Lock: in compliance mode, retention “can’t be shortened” and no user, including the root user, can overwrite or delete a locked version. A legal hold “has no expiration date” but can be placed and removed by anyone holding the s3:PutObjectLegalHold permission, so restrict it.
- AWS Backup Vault Lock: minimum and maximum retention between 1 and 36,500 days; jobs outside the range fail. Compliance mode becomes immutable after a grace time of at least 72 hours.
- Azure Backup immutable vault: by default, reductions in policy retention are blocked; with a specific immutability duration, retention can’t go below that duration. Locking is irreversible.
- Google Cloud Backup and DR: minimum enforced retention of 1 day to 99 years; after a lock’s effective date, “not even a Project Owner” can decrease it.
Lock the floor the policy needs, not the longest period anyone might want; the floor can’t come down later. Then size the window against detection. The NCSC links time-based retention to restoring “a backup in time before the attack took place,” and NIST SP 800-209 observes, about logs, that “it often takes a while to notice that a compromise has occurred.” No primary source reviewed here gives a dwell-time figure, so use the organization’s own threat-hunting lookback, as the 3-2-1-1-0 guide suggests, and pair it with the clean-backup checks in the ransomware recovery plan. Storage options are compared in immutable backup storage and air gapped backup.
The cost side
Retention drives capacity directly; what each extra restore point adds depends on change rate, deduplication and compression. Locks remove the option to clean up mistakes: AWS warns that locked backups “cannot be deleted until their lifecycle completes, resulting in persistent costs,” and Google says enforced-retention backups incur “standard storage charges for the full duration.”
Archive tiers bill minimum durations. AWS lists minimum storage duration charges of 30 days for S3 Standard-IA, 90 days for S3 Glacier Flexible Retrieval and 180 days for S3 Glacier Deep Archive; an S3 Standard-IA object deleted sooner is “charged for 30 days.” In Proxmox Backup Server, pruning removes metadata and a later garbage collection frees the data, so reclaimed space lags behind expiry. List prices and egress are in the backup storage cost per TB analysis; SaaS retention limits are in the Microsoft 365 backup comparison.
Backup retention policy template
Copy this outline and replace each bracketed placeholder. It tracks NIST SP 800-209’s list for a data protection policy, including lifecycle tracking with “affirmative deletion of no longer needed ones.”
- 1. Scope: [systems, SaaS tenants, endpoints]. Does not replace the [records schedule] or [legal hold procedure].
- 2. Owners: policy owner [role]; approvers [IT, security, legal, records, privacy]; operators [team].
- 3. Tiers: assigned from [business impact analysis]; recorded in [inventory].
- 4. Schedule per tier: frequency [interval]; short-term [N days, calendar or backup days]; long-term [N weekly, N monthly, N yearly].
- 5. Copies: [primary], [offsite], [immutable or isolated], per [3-2-1-1-0 standard].
- 6. Immutability: [compliance or governance] mode, [N days] per tier; changes approved by [roles].
- 7. Keys: retained for [life of the backups]; stored apart from backup data.
- 8. Legal hold: issued by [legal role]; expiry suspended for [scope] within [time]; reviewed every [period]; released by [role].
- 9. Regulatory overrides: [rule], [record type], [period], [system], owned by [records management].
- 10. Erasure: live data within [time]; backups beyond use until expiry; [how erasures are re-applied after a restore].
- 11. Deletion and verification: expired points removed by [job]; space reclaimed by [job]; confirmed by [report] every [period].
- 12. Testing and review: restores from [oldest and newest points] every [period]; policy reviewed every [period] and after [trigger].
Example tiers, as an illustrative structure only, not recommended values:
| Tier | Frequency | Short-term | Long-term | Lock | Isolated copy |
|---|---|---|---|---|---|
| Tier 1: [systems] | [interval] | [N days] | [N weekly, N monthly, N yearly] | [mode, N days] | [location] |
| Tier 2: [systems] | [interval] | [N days] | [N weekly, N monthly] | [mode, N days] | [location] |
| Tier 3: [systems] | [interval] | [N days] | [N monthly] | [mode, N days] | [location] |
How to decide your retention periods
- Collect minimum and maximum periods per data class from legal, records and privacy.
- Set frequency from each tier’s recovery point objective, and the retention floor from how far back a clean restore point may sit.
- Use time-based short-term retention, with GFS or period buckets for long-term points.
- Price retention, including minimum durations, before locking anything.
- Test locks in governance mode or a grace period, then lock the floor.
- Test restores from the oldest points, per the backup restore testing guide, and record each system’s retention in the disaster recovery plan template.
Frequently asked questions
How long should backups be kept?
No single period applies. Keep each tier long enough to restore to a point before an incident was detected, and no longer than privacy rules such as GDPR’s storage limitation principle allow. Periods set for specific records, such as SEC Rule 17a-4’s, belong in the records schedule.
What is GFS backup retention?
Grandfather-father-son keeps recent restore points under short-term retention and retains selected full backups as weekly, monthly or yearly points. In Veeam’s implementation, each flagged period needs at least one full backup.
Is a backup retention policy the same as a data retention policy?
No. A records retention policy sets how long information must or may exist; a backup retention policy sets how long restore copies are kept. NARA’s federal schedule ties backup disposal to restoration needs and excludes system data or content.
Can you shorten retention on an immutable backup?
Not under a strict lock. S3 Object Lock compliance mode and a locked Google Cloud vault block reductions, and Azure’s immutable vault blocks them below its immutability period. Governance-mode locks can be changed by users with the right permissions.
Do GDPR erasure requests apply to backups?
Under UK GDPR, the ICO says erasure covers backups as well as live systems, but data may stay in backups until overwritten if it is put beyond use and replaced on an established schedule.
Sources
- NIST SP 800-209: Security Guidelines for Storage Infrastructure
- NARA General Records Schedule 3.2 (PDF)
- Federal Rules of Civil Procedure, Rule 37 and committee notes
- Regulation (EU) 2016/679 (GDPR)
- ICO: Right to erasure
- eCFR: 45 CFR 164.316
- 45 CFR 164.308 (Cornell LII)
- HHS FAQ: medical record retention under HIPAA
- eCFR: 17 CFR 240.17a-4 (SEC Rule 17a-4)
- NCSC: Principles for ransomware-resistant on-premises backups
- Veeam: Long-term retention policy (GFS)
- Veeam: Short-term retention policy
- Proxmox Backup Server: Maintenance tasks (pruning)
- AWS: Locking objects with S3 Object Lock
- AWS Backup Vault Lock
- Microsoft Learn: Immutable vault for Azure Backup
- Google Cloud: Backup vaults
- AWS: Amazon S3 storage classes
- AWS: Understanding and managing S3 storage classes
Last checked: October 2026. Guidance changes; check each source before you rely on it.
Buying? Start from RFPhub’s free Backup Software RFP template.