Backup retention rules in regulated industries come from several directions at once. A financial regulator expects records to be available for a set number of years. A privacy law says personal data must not be kept longer than necessary. An operational resilience framework requires that systems can be restored within a stated time. Each is reasonable alone. Together they pull retention in different directions, and the backup policy is where the tension has to be resolved.
This post describes the kinds of rules that affect backup retention, how they interact and how to turn them into a policy that can be defended. It is an overview, not legal advice. Specific obligations depend on jurisdiction and sector and should be confirmed with compliance or legal counsel.
Records retention is not backup retention
The most common misunderstanding is that a rule requiring records to be kept for seven or ten years means backups must be kept that long. Most such rules are about the records themselves: ledgers, transaction histories, patient files, communications. They are satisfied by keeping those records accessible in the system of record or in an archive. Backups exist to restore systems after loss. They are a poor way to meet a records obligation, because finding one document in a seven-year-old backup means restoring an entire system that may no longer run.
The cleaner design keeps the two apart. An archive holds the records for the mandated period. Backups protect both production and the archive for a much shorter one.
Where retention requirements come from
| Source | What it typically requires | Effect on backups |
|---|---|---|
| Sector records rules (finance, health, pharma) | Specific records kept for a fixed number of years | Usually met by archive. Backups must protect that archive |
| Privacy law | Personal data kept no longer than necessary, erasure on request | Sets an upper limit and calls for a documented expiry process |
| Operational resilience rules | Tested ability to restore, defined recovery objectives | Sets a minimum for restore points and for testing |
| Security frameworks and cyber insurance | Offline or immutable copies, periodic restore tests | Sets a minimum immutability period |
| Contracts and customer requirements | Retention or deletion terms for customer data | May differ per customer or data set |
| Litigation and investigations | Preservation of specific data until released | Overrides normal expiry for the data in scope |
Minimums and maximums
Some rules set a floor and others a ceiling. Resilience and security requirements say backups must go back far enough to recover from an incident discovered late, which in practice means weeks to a few months of immutable restore points. Privacy rules say data should not linger. Under the GDPR, for example, personal data in backups remains personal data, and regulators generally accept that it cannot be removed from individual backup sets as long as the backups expire on a documented schedule and erased data is not restored into production.
The policy therefore needs both numbers for each class of data: the shortest retention that meets recovery needs and the longest that can be justified. Matching retention to recovery needs gives a method for the first.
Immutability periods
Immutability adds a constraint that cannot be undone. Data locked in compliance mode stays for the full period regardless of any later request to delete it. That is the point of the control, and it is also why the period should be chosen deliberately. A 30-day lock is easy to reconcile with privacy obligations. A seven-year compliance-mode lock on backups containing personal data is much harder to justify unless a specific rule requires it. What happens when retention locks expire explains how locked data ages out.
Tiers by data class
A single retention setting for everything is simple and almost always wrong for a regulated organization. Grouping systems by the rules that apply to them produces a small number of tiers. A typical outcome is a standard tier with around 30 days of daily points and a few monthly ones, a regulated tier with longer monthly and yearly points for systems whose records rules have no separate archive, and a short tier for systems holding data that should not be kept. Three or four tiers are usually enough. More than that becomes difficult to operate and to explain.
Writing the justification down
What auditors and regulators look for is a documented rationale more than a specific number. For each tier the policy should state the retention, the immutability period, the rules that were considered and why the figure was chosen. It should also describe how expiry works, how a legal hold suspends it and how often restores are tested. Legal hold on backups covers the hold mechanism. A two-page document reviewed annually serves better than a long one nobody maintains.
Cost follows retention
Every extension has a capacity cost that recurs for as long as the policy stands. Before agreeing to a longer period, it is worth pricing it and checking whether an archive would meet the underlying requirement more cheaply. The cost of another year of retention shows the calculation.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs, which keeps backup data in a location the organization controls. Immutability is provided by S3 Object Lock on each object, with the retention period set per bucket or per object by the backup software. In compliance mode no account, including ARTESCA administrators, can remove a lock before it expires.
Separate buckets can carry different lock periods for different retention tiers. ARTESCA grows within the same deployment from roughly 50 TB to 8.5 PB and is used as a target for Veeam and other backup software.
A policy that survives review
A retention policy holds up when it can answer three questions for any system: how far back can it be restored, why that far and no further, and what proves that expiry and restores actually happen. If the answers are written down and match what the backup system is configured to do, the policy will stand up to an audit, and it will also be cheaper to run than keeping everything just in case.