Backup Strategy

Backup Retention Policy Standards for HIPAA and SOC 2 Clients

HIPAA and SOC 2 demand separate retention schedules for different data categories.

Cover illustration for “Backup Retention Policy Standards for HIPAA and SOC 2 Clients”
Cover illustration for “Backup Retention Policy Standards for HIPAA and SOC 2 Clients”

Backup retention for HIPAA and SOC 2 clients requires one policy, but not one retention period. HIPAA’s six-year rule governs compliance documentation, while SOC 2 sets no fixed duration. A defensible policy separates those obligations from the rules governing clinical records, then connects each category to an enforceable schedule, recovery evidence, and controlled disposal.

Why HIPAA and SOC 2 create genuinely different retention obligations

A policy that conflates two different compliance models cannot defend its choices under either one. HIPAA establishes specific regulatory duties for defined document categories. SOC 2 is a risk-based attestation framework in which auditors test the controls an organization has described and selected.

The distinction creates two common policy errors. An organization may apply HIPAA’s six-year documentation rule to every backup and miss rules that require it to keep the records inside for longer. It may also assume that because SOC 2 sets no retention periods, it can leave retention undefined. In both cases, the policy lacks a defensible basis because its commitments do not reflect the framework being assessed.

What HIPAA’s six-year rule actually covers — and what it does not

45 CFR §164.316(b)(2) establishes a documentation-specific retention floor, requiring Security Rule compliance documentation to be retained for six years from creation or the date it was last in effect, whichever is later. The documentation set includes written security policies and procedures, risk assessments and analyses, Business Associate Agreements (BAAs), training records, access logs, and security incident documentation. Backup job logs, disaster recovery test results, and restore records also belong in this evidence trail.

Clinical records are governed by a different set of rules. State law and CMS/Medicare requirements govern the patient information inside backup copies. State requirements frequently extend beyond six years. CMS/Medicare adds further distinctions, including six years for Medicare fee-for-service documentation, five years after a cost report closes, and longer periods for Medicare managed care program providers. Payer contracts and legal holds can also affect how long records must remain available.

The practical rule is to track the longest applicable requirement for a backup containing ePHI. Retention duration is only part of the obligation. 45 CFR §164.308(a)(7) establishes contingency planning duties that focus on protecting and recovering information. OCR’s enforcement settlement with Plastic Surgery Associates of South Dakota illustrates that distinction. After a ransomware incident in which the organization could not restore servers from backup and paid the ransom, the corrective action plan required robust backup procedures and regular restore testing.

What HIPAA does require — the five-part Contingency Plan and its backup obligations

HIPAA’s Contingency Plan has five implementation specifications with distinct purposes. The Data Backup Plan, Disaster Recovery Plan, and Emergency Mode Operation Plan are required. Testing and Revision Procedures and an Applications and Data Criticality Analysis are addressable. That distinction belongs in the policy’s account of its obligations. It should not be replaced by a blanket statement that all five specifications have the same regulatory status.

The Data Backup Plan requires retrievable, exact copies of ePHI. The Disaster Recovery Plan covers how to restore system access after a disruption, from a single-server failure to the loss of an entire site. The Emergency Mode Operation Plan governs the protection of ePHI while operations are degraded. Testing and revision connect the written plans to demonstrated restore capability and changes in the environment. Criticality analysis names the systems and data needed for patient care and operations, so decisions about recovery have a written basis.

HIPAA specifies the required outcome. It does not prescribe backup frequency, media type, or architecture, so the organization must explain why its chosen methods fit its risk environment. The documented plan should connect risk analysis, recovery targets, and system criticality to a backup schedule, storage locations, restoration procedures, authorized personnel, and failure protocols. The plan should include where offsite or cloud copies are stored. Audit logs recording who accessed backup systems and when form part of the six-year compliance documentation trail.

How SOC 2 handles retention — no fixed periods, but the written policy is the artifact under audit

SOC 2 prescribes no retention duration, backup frequency, or technology. Its flexibility shifts responsibility to the organization’s written commitments. Auditors check whether the controls in the system description work as designed and whether policy documents, logs, and test results back up that claim. A finding can therefore arise from a gap between the promised schedule and actual practice, rather than from failure to retain backups for a prescribed number of years.

The 2017 Trust Services Criteria remain the applicable criteria, with updated points of focus published by AICPA in September 2022. Availability criteria A1.1, A1.2, and A1.3 directly concern backup and recovery planning, related controls, and testing. Scope determines which commitments are being assessed. An organization that selects Availability must support its backup and recovery controls with documented policy, successful backup logs, and periodic recovery evidence. Selecting that category without the corresponding evidence creates an obligation the organization cannot substantiate.

Retention also has an endpoint under SOC 2. Confidentiality criterion C1.2 and Privacy criterion P4.2 address disposal of data no longer needed. The policy must therefore describe destruction as well as preservation, with deletion jobs logged and legal holds suspending automated deletion until release. Secure destruction methods should align with NIST SP 800-88, including cryptographic erasure for encrypted backups, verified overwriting, or physical destruction for tapes.

An organization may apply HIPAA’s six-year documentation rule to every backup and miss rules that require it to keep the records inside for longer.

Where the two frameworks converge and what a unified policy can anchor itself to

A unified policy gives three compliance buckets their own schedules. The first bucket contains HIPAA compliance documentation, including policies, risk assessments, BAAs, audit logs, and test records. Its minimum is six years from creation or the last effective date, whichever is later. This bucket preserves the evidence of compliance. It is distinct from the underlying patient information that backup systems protect.

The second bucket holds clinical records and the backup copies that contain them. Its schedule follows the longest applicable obligation under state law, CMS rules, payer contracts, or legal holds. The third holds general business data in backups, which follows the organization’s written retention schedule. SOC 2 requires that schedule to be followed consistently and supported by evidence.

The frameworks then converge around execution and proof. Both call for written controls, evidence of testing and restoration, safeguards around backup repositories, and controlled disposal. A single policy can map each category to its authority and named owner while supplying the documentation needed for both assessments. Legal holds must be clear exceptions that keep affected data from being deleted on the normal schedule. When a backup is the last usable copy of a record, the record’s legal retention requirement takes precedence over the backup program’s default expiration date.

Architecture choices that make a policy defensible in practice, not just on paper

Logs of backup runs show that jobs took place, and tested restores show whether the copies kept can be used for recovery. Immutability protects copies against alteration during the period when an intrusion may remain undetected. These controls address different failure modes.

The widely used 3-2-1 architecture keeps three copies on two media types, with one copy offsite. The 3-2-1-1-0 variant adds one offline or immutable copy and zero unverified backups. Many cyber-insurers now require that stronger arrangement. Sophos reported in 2024 that 95% of healthcare ransomware attackers targeted backups and that most of those attempts succeeded in compromising them. Against that threat, the immutability window should exceed the period an attacker can remain undetected plus the time needed to recognize that recent backups were already compromised, although practitioners disagree on the appropriate minimum.

Storage separation also supports the recovery commitment. An offsite or cloud copy avoids reliance on one location where a local event can destroy primary data and backups together. Encryption, access restricted to authorized personnel, and access logging protect the retained copies, while encryption also enables cryptographic erasure at expiration. None of those safeguards proves restorability by itself. Their purpose is to preserve a protected copy that testing can demonstrate is usable.

The 2025 HIPAA Security Rule NPRM signals a more explicit approach to testing. The proposal, published in the Federal Register January 6, 2025, would require information-system backup and recovery controls to be reviewed and tested at least every six months, and ePHI backup and recovery controls to be tested at least monthly. It would also eliminate the required/addressable distinction for encryption. The NPRM remains a proposal without current enforceable duties, and its timeline has slipped.

Building a single audit-ready policy — governance, documentation, and disposal

To turn that structure into an operating policy, organizations should begin with a regulatory matrix mapping each record type to its governing authority and retention floor. The matrix should separate compliance documentation, clinical records, and business data and use the longest period that applies to each category. Named owners then make those decisions accountable. The Privacy Officer oversees PHI retention compliance, approves exceptions, and authorizes legal holds. The Security Officer or IT Lead configures retention rules, encryption, and access controls and manages backup infrastructure.

The Compliance or Risk Manager should audit adherence and maintain the documentation trail for six years. Department Owners remain accountable for data within their workflows. The written schedule should include restoration tests, with results that serve as both HIPAA compliance documentation and SOC 2 recovery evidence. When tests fail, the organization must revise its plans and record the changes along with the failures in the log.

Legal holds require their own controlled process. The policy should name who triggers a hold, how automated deletion pauses for affected data, and how the hold is released. Litigation, regulatory inquiry, and active OCR investigation must be accounted for. The disposal process should then specify a method for each media type, including cryptographic erasure for encrypted cloud backups, verified overwriting for disk, and physical destruction for tapes under NIST SP 800-88. Every deletion job should be logged, and those logs should be kept for the compliance documentation period.

BAAs with cloud storage and SaaS backup vendors should specify retention duties, destruction procedures, and access controls so that performance is trackable and auditable. NinjaOne’s backup and endpoint management platform can help operationalize these commitments through automated backup scheduling, restore testing workflows, and centralized logging. Those functions help with contingency planning and gathering evidence, but the organization still decides which rules apply, how long to keep data, and who is responsible for it.

Why a well-designed retention policy still isn’t enough on its own

Retention and recovery cannot reverse data theft. In an exfiltration-first attack, attackers steal information before deploying encryption, so even intact, immutable backups leave notification obligations, potential OCR penalties, and reputational harm unresolved. The Change Healthcare incident illustrates this boundary. ALPHV/BlackCat disrupted operations and exfiltrated data, with OCR notification ultimately covering a very large number of affected individuals.

Egress monitoring, anomaly detection, and network segmentation address stages of the attack that backup controls do not. The NPRM’s proposed requirements for segmentation and mandatory encryption respond in part to this threat model. SOC 2 auditors likewise increasingly expect controls addressing detection and containment as well as backup availability.

Sources

  1. HIPAA Data Backup: Top Guide to Compliance and Recovery

    Provided background on HIPAA's contingency plan specifications, including the required versus addressable distinction and the five implementation specifications.

  2. HIPAA Backup Retention Requirements: Essential Guide for 2025 - Medical ITG

    Provided detail on the six-year documentation retention requirement under 45 CFR §164.316(b)(2) and the categories of records it covers.

  3. Backup Retention for HIPAA: What Medical Practices Must Know - Medical ITG

    Provided information on CMS/Medicare-specific retention periods and state law obligations that extend beyond the HIPAA six-year floor.

The Continuity Brief Editors

More in Backup Strategy

← Front page