Most teams have a backup retention policy on paper, but it falls out of sync the moment new accounts, databases, and buckets appear faster than anyone updates the rules.
What is a backup retention policy?
A backup retention policy is an organizational rule that defines which backup data to keep, how long to keep it, where to store it, and when to delete it. It determines the number of backup versions retained, the storage tier for each version, and the conditions under which backups are purged or promoted to long-term archive.
The policy connects three concerns that teams often manage separately: recovery readiness (can we restore what we need?), compliance (can we prove what we kept and when?), and cost control (are we paying for backups we no longer need?).
Why do backup retention policies break at cloud scale?
On-prem, a retention policy covered a known set of servers and storage arrays. The environment changed slowly. A quarterly review could catch most drift.
In the cloud, the environment changes daily. Teams add accounts, provision managed databases, launch containers, and create storage buckets across regions.
Eon's State of Cloud Backup 2025 report found that 51% of organizations still rely on manual or semi-automated backup processes, and one in five organizations use multiple backup tools, leading to policy drift and operational inefficiency.
Here are the failure patterns we see most often:
- Retention drift across accounts and teams: A fix applied in one region does not propagate to the others, so the audit clears where it was patched while the rest stays exposed.
- Over-retention inflating costs: Snapshots set to “forever” pile up untouched. One Eon customer found a non-critical workload on over 10,000 unknown snapshots; right-sizing saved tens of thousands of dollars.
- Under-retention creating recovery gaps: A 7-14 day default is fine for dev, but when the window is shorter than your threat-detection window, the clean recovery points are gone before you reach for them.
- No visibility into what retention rules actually apply: Even with policies on paper, teams often cannot say which rules are actually enforced or which workloads have drifted, so retention runs on guesswork.
What should a backup retention policy include?
A complete backup retention policy covers six elements. Miss one and the gap surfaces during an incident or audit.
- Data scope and classification: which data types, workloads, and environments the policy covers, since you can't set retention without knowing what you're retaining and why.
- Retention periods by tier: how long each data class is kept, so cost tracks risk instead of paying to keep everything for the same length of time.
- Storage location and separation: where backup copies live and how they're isolated, because retention means nothing if the backup is reachable through the same credentials as production.
- Immutability windows: how long a copy can't be changed or deleted, even by an administrator, which is what protects backups against ransomware, insider threats, and accidental deletion.
- Access controls and audit trail: who can view, restore, modify, or delete backups and how those actions are logged, since compliance frameworks require proof of who touched backup data and when.
- Review and enforcement cadence: how often the policy is reviewed, who owns it, and how enforcement is automated, because unreviewed policies drift and unautomated ones fail.
How do you set the right retention periods?
Retention periods should be driven by three inputs. These include recovery requirements, compliance mandates, and cost constraints. Starting from any one input alone produces a policy that fails the other two.
Recovery requirements come first
Define your recovery point objective (RPO) and recovery time objective (RTO) for each workload. Then work backward:
- If your RPO is 1 hour, you need hourly backups.
- If corruption can go undetected for 30 days, your retention window must be longer than 30 days.
- If ransomware dwell time averages 10–21 days in your environment, your immutability window must cover that period. CISA's LockBit advisory recommends that backup data be encrypted, immutable, and cover the organization's entire data infrastructure.
Compliance sets the floor
Different regulatory frameworks impose different minimum retention periods, and most organizations fall under more than one:
- HIPAA: 6 years for required compliance documentation. Patient records follow state law, often 7 to 10 years.
- SOX (Sarbanes-Oxley): 7 years for financial records and audit documentation.
- GDPR: no fixed period, but data can't be kept longer than necessary for its stated purpose.
- PCI-DSS: 1 year minimum for audit logs, and card data retention varies by use case.
- SOC 2: periods are set by the organization, but they must be documented and enforced.
GDPR creates a specific tension with backup retention. The regulation's "right to erasure" conflicts with backup copies that may contain the same personal data. Your policy needs to address how deletion requests are handled when the data exists in immutable backup copies with active retention windows.
Cost sets the ceiling
Every retained backup has a storage cost. EBS snapshots run approximately $0.05/GB per month. S3 Standard costs roughly $0.023/GB per month. S3 Glacier Deep Archive drops below $0.001/GB per month. But the tier pricing is only part of the cost.
The bigger issue is redundancy and over-retention. If 100 EC2 instances share 80% of the same underlying data and each is backed up independently with long retention windows, you are storing near-identical copies at full price for the entire retention period.
Eon cuts this cost by storing backup data in deduplicated, compressed Parquet format rather than block-level snapshots. One copy serves all regions. Database maintenance like vacuum operations does not inflate backup size.
The result is 30–50% lower backup storage costs compared to native cloud snapshots. NETGEAR reduced backup storage costs by 35%, and Innago saved 40% after switching to Eon.
What does a practical retention matrix look like?
A retention matrix maps data classes to backup frequency, retention duration, immutability window, and storage tier. This starting framework has worked well across cloud-first teams:
Your matrix should be customized based on workload behavior, data change rate, regulatory scope, and recovery testing results.
In Eon, policies use conditions and rules. Conditions decide which resources the policy applies to (based on data class, environment, resource metadata, and policy conditions). Rules define backup frequency, retention period, and vault destination.
When a new resource appears that matches the conditions, the policy applies automatically without anyone needing to tag it or write a new rule.
How do you implement a backup retention policy in 7 steps?
We've broken this into the sequence that works for cloud teams managing multiple accounts, regions, and data classes. Each step builds on the one before it, so the order is deliberate.
1. Inventory data sources, accounts, and regions
Map every database, file system, object store, VM, container workload, and managed service across all accounts and regions, and flag what already has coverage. Catalog secondary copies too (snapshots, replicas, cross-region copies, exports), since one regulated record often lives in several.
2. Classify data by business value and risk
Group workloads into the retention tiers from the matrix above; that classification drives every downstream choice. Manual tagging breaks at scale, which is where Eon’s Cloud Backup Posture Management (CBPM) classifies resources by content (PII, PHI, financial) and applies the matching policy automatically.
3. Define retention periods and immutability windows
As outlined in the six-element framework and matrix above, map each data class to a retention period, immutability window, and storage location. Set the immutability window against real threat dwell time: 30 days for fast-caught attacks, 90 for slower compromises.
4. Automate policy enforcement
Manual retention management does not work at cloud scale. Set org-wide guardrails; "Any production resource must have a minimum 90-day retention and cross-region copy." When resources drift from policy, auto-trigger alerts or tickets.
5. Set access controls and audit logging
Define who can view backups, search backup data, export results, change retention policies, and start restores. Separate these permissions:
- Data access (who can read backup contents) from key access (who can decrypt).
- Policy administration (who can change retention rules) from restore execution (who can trigger a restore).
- Routine access from break-glass access (emergency restore paths).
Log every action. Compliance frameworks require proof of who accessed backup data, when, and what they did.
6. Test restore paths tied to retention windows
A retention policy is only trustworthy if the retained backups are actually restorable. Test more than one path: full instance, file-level, record-level, cross-region, and restores from the oldest retained backup.
Key questions the test should answer:
- Can you restore from the oldest backup in each retention tier?
- Does the restore work after key rotation or access policy changes?
- Can you restore the specific file, object, table, or record you need without recovering the full environment?
SoFi cut recovery time from a full day to minutes across five AWS regions, while StructuredWeb cut backup retrieval time by 98%.
These results depend on granular restore capability paired with retained backups. Eon's Granular Restoration supports file, object, table, and record-level recovery without rebuilding the full environment.
7. Review, document, and assign ownership
Schedule quarterly reviews of retention policies. Assign clear owners for policy reviews, restore tests, alert handling, and compliance evidence. Document everything.
The policy you write today will not fit your environment a year from now. Accounts change, compliance requirements evolve, workloads get added and retired. Someone needs to own the review cycle and the ongoing enforcement, from day one through every quarterly check.
What are the most common retention policy mistakes?
These are the most common retention policy mistakes, and how to fix them.
Where does retention policy fit alongside other controls?
A retention policy is one layer of backup posture and only holds up when the controls around it do.
- Backup coverage: Retention rules do nothing for a resource that was never backed up, so coverage is the precondition for everything else; 61% of teams report finding protection gaps only after an incident, audit, or failed restore.
- Immutability: retention sets how long you keep a copy; immutability sets whether anyone (including an admin or an attacker with valid credentials) can alter or delete it inside that window. A retention window without logically air-gapped immutable copies is only as durable as the weakest credential that can reach it.
- Backup data access: Retained backups that sit cold are paid-for data doing nothing the other 364 days; open formats let that data also serve analytics and compliance.
- Cost visibility: Without per-resource cost attribution, over-retention hides inside the aggregate bill, so tie retention spend to team, account, workload, and region before deciding what to trim.
Make retention rules stick at cloud scale
Most teams can't say which of their retention rules are actually enforced without a manual, account-by-account review. That's the gap a backup retention policy alone doesn't close. You need automated discovery, classification, and enforcement to make retention rules stick at cloud scale.
Book a demo to see how Eon's CBPM discovers resources, classifies data, enforces retention policies automatically, and surfaces drift before it becomes a compliance finding or a recovery failure.
Frequently asked questions
What is a backup retention policy?
A backup retention policy is an organizational rule that defines which backup data to keep, how long to retain it, where to store it, and when to delete it. It governs the full lifecycle of backup copies from creation through purge.
How long should you retain backups?
Backup retention depends on data class, compliance requirements, and recovery needs. Dev/test data typically needs 7–14 days. Production data ranges from 90 days to 1 year. Regulated and financial data may require 5–7 years. Start from compliance minimums and recovery requirements, then optimize for cost.
What is the difference between retention and immutability?
Retention defines how long a backup copy is kept before deletion. Immutability defines whether a backup copy can be modified or deleted during its retention window. A backup can have a 1-year retention period with a 90-day immutability window, meaning it is protected from changes for the first 90 days and kept for a full year.
Does GDPR conflict with backup retention?
Yes, GDPR's "right to erasure" can conflict with backup retention windows. If a data subject requests deletion, the data may still exist in immutable backup copies. Your retention policy should document how deletion requests are handled when backup copies are subject to active retention or immutability rules.
How often should you review a backup retention policy?
Review backup retention policies at least quarterly. Review immediately when compliance requirements change, new workloads are added, or the organization's cloud footprint expands to new accounts, regions, or providers. Automated drift detection reduces the manual effort required for each review.
How does Eon help with backup retention policy enforcement?
Eon enforces backup retention policies through Cloud Backup Posture Management(CBPM), which discovers resources, classifies data, applies retention policies without manual tagging, and surfaces drift across AWS, Azure, and Google Cloud. Teams can set org-wide retention guardrails with Backup Posture Controls while allowing team-level flexibility.
