What Are Immutable Backups?
An immutable backup is a backup copy stored so that, once written, it cannot be changed or deleted until a pre-set retention period expires. Immutability is enforced by the storage system or a separate security boundary, not just a software setting on the backup server.
Common approaches include:
- Object storage with write-once-read-many (WORM) retention
- Hardened backup repositories with immutable file systems
- Snapshot immutability on storage arrays
- Air-gapped or offline copies
What immutability is not: a normal backup folder with restricted permissions, or a “do not delete” policy that an attacker can change after gaining admin access. Outsourcing your backups to a third party does not make them immutable on its own. The third party’s backup must still be stored in a hardened repository with demonstrable immutability controls.
Why Immutable Backups Matter for ePHI
For healthcare and health-adjacent environments, availability and integrity are just as critical as confidentiality. If ePHI systems are unavailable for days, patient care and operations are impacted. If restored data has been tampered with, clinical and billing decisions can be affected.
Immutable backups reduce both risks by protecting recovery points from modification and deletion.
Key scenarios where immutability is critical:
Ransomware attacks. Attackers increasingly seek and destroy backups before deploying ransomware. Immutability helps ensure at least one clean restore point survives.
Insider risk and credential theft. If an attacker obtains admin credentials, immutable retention can still prevent deletion or alteration of backup data.
Operational mistakes. Accidental deletion or misconfigured retention policies are far less likely to wipe out your last known-good copy.
Audit readiness. Demonstrable, enforced retention combined with documented restore testing supports control implementation and evidence packages.
How Immutable Backups Support HITRUST Control 16.09l1Organizational.4
HITRUST control 16.09l1Organizational.4 states: “The organization maintains offline and/or immutable backups of data.”
Immutable backups are not a standalone HITRUST checkbox, but they can materially strengthen your control implementation and simplify evidence gathering for assessors.
Immutable retention provides enforced protection against alteration and deletion of backup copies, supporting evidence that backups are protected, retained as required, and recoverable after a security event.
Example evidence artifacts assessors will look for:
- Backup architecture diagram
- Immutable storage configuration screenshots or exports
- Retention policy documentation
- Privileged access and MFA settings
- Backup job reports
- Restore test results with dated evidence
- Incident recovery runbook
The assessor will want to see evidence that the backup cannot be altered or deleted during the retention period. The key is demonstrating how immutability is configured and implemented within the in-scope environment.
Immutable Backup Implementation Checklist
Use this checklist to evaluate or build out your backup architecture:
- Define retention requirements by data class and system (for example, critical clinical applications versus internal tools) and document the rationale.
- Use immutable storage that enforces retention outside the backup server’s administrative control, such as a separate account, tenant, or security boundary where feasible.
- Apply least privilege and MFA for backup administrators and storage administrators, and limit who can change retention settings or disable immutability.
- Separate duties where practical. The person who administers production systems should not be the only person who can delete or alter backups.
- Maintain multiple copies following the 3-2-1-1-0 rule: three copies of data, two different media types, one copy offsite, one copy offline or immutable, and zero errors on your last restore test.
- Consider a second immutable location to reduce single-account risk.
- Monitor and alert on backup failures, retention policy changes, and unusual delete attempts.
- Routinely test restores rather than relying on backup completion results alone. Document and retain dated evidence of restore validation activities, including recovery testing from immutable storage and ransomware recovery scenarios.
- Document the recovery workflow including who declares an incident, who can access immutable copies, and how keys and credentials are handled.
Frequently Asked Questions
Does outsourcing backups to a third party satisfy the HITRUST immutability requirement?
No. Outsourcing your backups does not automatically make them immutable. The third party must store backups in a hardened repository with demonstrable immutability controls. Your evidence package should reflect those specific configurations.
What is the difference between offline backups and immutable backups?
Offline backups (such as tape or air-gapped media) are physically disconnected from the network. Immutable backups use enforced retention locks, often in cloud-native object storage, to prevent modification or deletion. Both approaches can satisfy the HITRUST requirement, and some organizations use both for layered protection.
What evidence does a HITRUST assessor expect for this control?
Assessors generally look for a backup architecture diagram, immutable storage configuration documentation, a retention policy, access control evidence including MFA settings, backup job reports, and dated restore test results.
Does the immutability requirement apply to e1, i1, and r2 assessments?
The offline and/or immutable backup requirement under 16.09l1Organizational.4 is a foundational control that has been applied consistently across assessment types, and the updated language that carries the immutability standard has remained in place through the current CSF version (v11.8 ).
At Clearwater, we work with healthcare organizations and health business services every day who are preparing for HITRUST assessments, and backup architecture is one of the areas where we consistently see gaps that create real risk, not just audit findings. The shift to immutable backup requirements in HITRUST v11.3 is not a paperwork change. It reflects where the threat environment actually is.
If your organization has not yet evaluated your backup architecture against 16.09l1Organizational.4, now is the time. The operational gap between a mutable and an immutable recovery point can be the difference between a contained incident and a business-disrupting event that compromises patient data and trust.
We are happy to walk through how your current backup strategy maps to this requirement and whether your evidence would hold up under assessor scrutiny. Contact us to start the conversation.
This post is for informational purposes and does not constitute formal HITRUST readiness or assessment advice.
