The best backup retention period is not a universal number. It is a documented decision based on how far back your team may need to recover, how quickly each system must return to service, and which records must remain available for operational, contractual, or legal reasons. Build retention by workload—not by one global setting.
At 4:17 p.m. on a Tuesday in Modesto, a clinic’s practice manager opens the electronic health record system and notices that several patient schedules and clinical notes have been altered. The change is not obvious in every record, and the team does not yet know whether it is a synchronization error, an account compromise, or malicious activity.
The IT lead has a choice to make before restoring anything: recover from the latest copy, or go back to a point before the suspicious changes began. If the clinic keeps only seven daily restore points, the clean version may already be gone. If it keeps months of point-in-time copies without a recovery plan, finding the right version may take too long while front-desk staff move to downtime procedures.
That is the real backup retention decision. It is not simply “How many days of backups do we keep?” It is “How far back must we be able to investigate, recover, and prove what happened for this specific system?”
Retention is a recovery decision, not a storage setting
Backup frequency and retention period solve different problems:
- Backup frequency determines how much recent work could be lost. A backup every 15 minutes creates a smaller potential gap than a nightly backup.
- Retention period determines how far back the organization can recover or investigate.
- Recovery point objective (RPO) describes the maximum acceptable amount of data loss.
- Recovery time objective (RTO) describes how quickly a service must be usable again.
- Restore validation determines whether the retained copy is actually usable.
A business may have an excellent RPO for yesterday’s files and still be unable to recover from a compromise that began three weeks ago. Conversely, it may retain five years of archives but be unable to restore its line-of-business application within the time the operation can tolerate.
NIST guidance for managed service providers emphasizes that backups should be planned, maintained, and tested, with the approach tied to the organization’s business value and operational needs.1 That is why Datapath starts with applications and workflows—not with a vendor’s default retention menu.
How long should you retain backups?
There is no responsible single answer for every organization. A practical starting point is to create retention tiers and then adjust them after reviewing recovery scenarios, record obligations, and system dependencies.
| Workload or data class | Example starting policy | Why it may be appropriate | Decision that must be validated |
|---|---|---|---|
| Frequently changing operational data | 30–35 days of daily or more frequent restore points | Provides a reasonable window for accidental deletion, user error, and recently discovered corruption | Can the team identify the last known-good copy and restore it within the RTO? |
| Core business systems | 60–90 days, plus monthly points | Extends the investigation window for delayed discovery and application-level corruption | Are application databases, credentials, integrations, and configuration files included? |
| Finance, audit, and approval records | Monthly points for 12 months or longer where policy requires | Supports reconciliation and investigation of older discrepancies | Does the retention policy align with the organization’s records schedule and contracts? |
| Clinical, student, public-safety, or evidence-related systems | Workload-specific schedule; do not use a generic default | These systems may support care, dispatch, instruction, or evidence workflows with different recovery priorities | Has the owner documented what must be restored first and how integrity will be demonstrated? |
| Long-term archive | Separate archive policy, not merely “more backups” | Archives may require different access controls, formats, and retrieval procedures | Can the organization retrieve and interpret the data years later? |
The numbers in this table are planning examples, not regulatory mandates. The important point is that each tier has an owner and a reason. If a department cannot explain why it needs 35 days, 90 days, or 12 months, the number is probably just a software default.
What should determine the retention period?
1. The time between an event and its discovery
Many failures are noticed quickly. Others are not. A deleted folder may be reported the same day; a compromised account may quietly modify files for weeks. Retention should cover the plausible gap between the first harmful action and the date someone detects it.
Ask:
- How long could unauthorized activity remain unnoticed?
- How often are financial, clinical, student, dispatch, or operational records reviewed?
- Could a monthly close, billing cycle, grading period, or case review expose the issue later?
- Does the backup platform preserve immutable or offline copies outside the reach of compromised administrator credentials?
CISA recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster-recovery scenario.2 That guidance changes the design conversation: retention is not useful if an attacker can encrypt or delete every accessible copy.
2. The workflow’s tolerance for interruption
The restore order should follow the organization’s actual work. In a Modesto clinic, the first recovery priority may be identity services, network connectivity, the EHR database, medication or diagnostic integrations, and secure communications—not necessarily the file server with the largest data volume.
For a Central Valley school district, the priority could instead be identity, student information systems, learning platforms, transportation data, and the systems needed to publish an altered bell schedule or communicate with families. For a public-safety environment, dispatch and the systems supporting active incidents may take priority over departmental file shares.
Retention and recovery planning should therefore document:
- The first three applications to restore.
- The dependencies each application requires.
- The oldest acceptable recovery point for each workload.
- The manual process used while the system is unavailable.
- The person authorized to approve a restore.
- The evidence captured before and after restoration.
NIST’s contingency guidance describes recovery objectives, restoration priorities, roles, and metrics as elements of a useful contingency plan.1 A retention schedule without those operational details is an inventory of dates, not a recovery strategy.
3. Data integrity and investigation needs
A backup can be complete and still be the wrong recovery source. If an application is corrupted, a database is partially encrypted, or an attacker has changed records, the team needs enough historical points to compare versions and establish a clean recovery point.
This is particularly important when restoring more than files. Database consistency, application logs, permissions, encryption keys, configuration, and integration settings may all affect whether a restored system is trustworthy.
For a healthcare organization, the HIPAA Security Rule’s contingency-plan requirements include creating and maintaining retrievable exact copies of electronic protected health information, as well as procedures to restore lost data.3 The practical lesson is not simply “keep more EHR backups.” It is to define what must be recoverable, how the copy will be validated, and how the clinic will continue critical operations during downtime.
4. Records obligations and business policy
Retention for operational recovery is not automatically the same as retention for records management. A backup platform should not become an ungoverned archive of every version of every file forever.
Work with the data owner, legal counsel, compliance leadership, and records-management function to distinguish:
- Backups intended for short-term recovery.
- Archives intended for long-term preservation.
- Logs needed for security investigation.
- Evidence requiring chain-of-custody controls.
- Data subject to contracts, litigation holds, or sector-specific policies.
The policy should also address deletion. If backup copies expire automatically, who approves the schedule? If a record must be preserved, how is it removed from the normal rotation and placed into the correct archive or hold process? These questions matter as much as the retention number.
Should backups be immutable or offline?
For critical systems, Datapath generally recommends evaluating a layered design rather than relying on one backup destination. That may include a fast operational copy, a separate recovery copy, and a protected copy that is isolated from routine administrative access.
The exact architecture depends on the environment, but the controls should answer four questions:
- Can a compromised administrator delete every copy?
- Is at least one recovery copy separated from the primary environment?
- Are backups encrypted in storage and during transfer?
- Can the organization recover encryption keys, credentials, and configuration needed to use the backup?
CJIS guidance is especially direct about protecting backup confidentiality, integrity, and availability; testing backup information for reliability and integrity; and using cryptographic mechanisms to protect criminal justice information. A county or public-safety team should not assume that a successful “backup completed” status proves that a dispatch-related or law-enforcement system can be safely restored.
What does a defensible backup retention policy include?
A useful policy is short enough for an operations team to use and specific enough for an auditor, executive, or incident responder to understand. For every protected workload, document:
- System owner: The person accountable for the data and recovery priority.
- Data classification: What the system contains and how sensitive it is.
- Backup frequency: How often copies are created.
- Retention tiers: Daily, weekly, monthly, and any long-term schedule.
- RPO and RTO: The acceptable data-loss window and restoration deadline.
- Protection method: Encryption, immutability, offline storage, access controls, and key management.
- Restore sequence: Dependencies and order of operations.
- Testing schedule: What is restored, how often, and what evidence is retained.
- Exception process: Who approves a deviation and when it expires.
- Review trigger: A new application, acquisition, ransomware event, major workflow change, or material change in risk.
Avoid writing “all systems are backed up for 30 days” and calling the policy complete. That sentence conceals the decisions that matter: whether Microsoft 365 data is included, whether application-consistent backups exist, whether a database can be recovered separately, and whether a long-running compromise would be detectable.
How often should you test retention and restoration?
Testing should be proportional to the importance of the workload and should include more than checking a dashboard. A useful test may involve restoring a sample file, recovering a database to an isolated environment, validating application dependencies, or rehearsing a system outage with the department that owns the workflow.
Record:
- The restore point selected and why.
- Time to retrieve the backup.
- Time to make the system usable.
- Data and permissions verified after restoration.
- Gaps in credentials, licenses, integrations, or documentation.
- Whether the result met the stated RPO and RTO.
- Corrective actions and their owner.
For CJIS environments, the policy specifically discusses testing backup information to verify media reliability and information integrity, including retrieving and comparing a sample from an alternate location. For healthcare, HHS guidance likewise describes testing and revision procedures as part of contingency planning, with frequency and comprehensiveness varying by the organization’s complexity and circumstances.
Common retention mistakes we see
One global retention period
A 30-day policy may be excessive for some temporary data and inadequate for a core system with delayed error discovery. Tier the policy by workload.
Confusing snapshots with independent backups
A snapshot stored in the same compromised environment may not provide meaningful recovery isolation. Confirm where copies live and who can delete them.
Retaining data without retaining recovery capability
Old backup files are not enough if the organization cannot obtain the required software version, credentials, encryption keys, licenses, or application dependencies.
Testing only files
A file restore does not prove that an EHR, finance platform, student information system, or dispatch-support application can resume operations.
Allowing the backup vendor to choose the policy
A vendor can explain what its platform supports. The organization must decide what it needs to recover and why.
Build a retention policy that matches the work
At Datapath, we help organizations in Modesto, Fresno, Merced, Manteca, and across the Central Valley—and teams in Modesto and California markets—turn backup settings into an accountable recovery plan. That may involve managed IT services, managed cybersecurity, or a focused disaster recovery plan, depending on the gaps we find.
For a clinic, school district, financial institution, local government department, or mid-market business, the conversation should begin with the systems that must work, the records that must be recoverable, and the decisions people must make during an outage. We can map those workflows, define retention tiers, test restoration, and assign the named team responsible for keeping the plan current.
If your current policy is simply “daily backups retained for 30 days,” that is a useful starting point—but not a finished answer. Talk with Datapath about whether your retention period would still protect the organization if the problem began weeks before anyone noticed it.
