164.308(a)(7)(ii)(A) Data backup plan requirements

164.308(a)(7)(ii)(A) data backup plan: what the requirement asks for

The data backup plan specification requires written procedures to create and maintain retrievable exact copies of electronic protected health information. It is a required implementation specification, not an addressable one, so you cannot document it away as unreasonable. If you have been asked to prove that backups of ePHI exist, the question an assessor will ask is narrower than whether backups run: can you show that a defined set of ePHI is copied on a defined basis, that the copies are exact, and that you can get the data back when you need it. The risk this specification addresses is simple to state and expensive to live with: ePHI that cannot be recovered after ransomware encryption, hardware loss, a failed storage array or an operator error.

It is harder in practice than the one sentence suggests. ePHI rarely sits in one database. It spreads across EHR and billing systems, file shares, email archives, imaging stores, laptops, SaaS tools and the reporting copies people export to spreadsheets. Teams often assume a backup job that reports success is a working backup, yet a job can succeed while capturing the wrong paths, skipping open files or writing copies that cannot be restored. The rule does not prescribe a backup method, a frequency or a retention period. Those decisions belong to your risk analysis, which HHS OCR's guidance names as the place to determine what data to back up and how. The rule also does not certify anything. No HIPAA certification exists, so an assessor will look for your written procedures, the systems they cover, and proof of retrievability, such as restore records from a recent test.

Start with an inventory that maps each ePHI location to a named backup owner, then ask the vendor or engineering lead for documented restore tests with dates, scope and results. Confirm whether your backup tooling can verify and restore data independently of the production environment. Open-source options such as Bareos and restic both offer verification and restore features, but whether they meet your recovery expectations depends on your environment and your documented procedures. Keep the backup procedure separate from the device-level copy requirement in 164.310(d), which covers retrievable copies before equipment is moved, so each one has its own evidence trail.

Which systems and copies fall under the backup plan

The backup plan is only as complete as its scope. Start from every location where ePHI is created, stored or exported, then let the risk analysis and the applications and data criticality analysis under 164.308(a)(7)(ii)(E) set the priorities and the recovery expectations for each one.

Core clinical and business systems

Start with the EHR database, practice management records, billing systems and any custom application that writes ePHI to a database. Confirm whether each one is backed up at the database level, the file level or both, because a file copy of a live database often cannot be restored to a consistent state. Record the owner of each system and the person who can authorize a restore. The backup plan should name these systems explicitly so an assessor can trace each one to a job in the backup platform.

File shares and document repositories

Shared network drives, scanned document folders and clinician desktops synced to shared locations often hold ePHI that no application owner thinks of as a system. Map where staff actually save patient letters, referral packets and exported spreadsheets. Check whether endpoint sync tools create copies outside the protected share. Unmapped repositories are the most common reason a backup plan appears complete while leaving ePHI unprotected.

Email archives, imaging and SaaS exports

Email stores, picture archiving systems, diagnostic image stores and exports pulled from SaaS applications each carry their own retention and restore behavior. Confirm whether the SaaS vendor retains data for your restore needs or whether you must export and back up the data yourself. Imaging archives are often very large, so their recovery priority and storage tier should be decided separately from transactional systems.

Backups held by cloud and hosting providers

When backup copies sit with a cloud or hosting provider, that provider creates, receives, maintains or transmits ePHI and is a business associate. Confirm that a business associate agreement covers the backup service, the storage location, the encryption keys and the provider's own subcontractors. Ask the provider to state in writing how it isolates your copies and how restores are performed, so the contract and the technical design match.

Copies on removable media

Tapes, external drives, USB sticks and optical media used for backup or transfer are copies of ePHI in their own right. List who creates them, where they are stored, how they are encrypted, and how they are destroyed or reused. The device and media controls under 164.310(d) govern the movement and disposal of this equipment, so the backup plan and the media procedures must describe the same copies consistently.

Who owns the scope when a third party runs backups

The covered entity or business associate remains responsible for the backup plan even when a managed service provider runs the jobs. The organization should approve the scope in writing, keep the authority to change it, and receive evidence that each listed system is backed up and restorable. The implementation partner can configure and document the backups, but only the organization can decide which systems count as in scope based on its risk analysis. Confirm this split in the service agreement before the work starts.

How the backup plan differs from the device copy in 164.310(d)

The contingency backup specification in 164.308(a)(7)(ii)(A) and the device and media specification in 164.310(d)(2)(iv) both produce a retrievable exact copy of ePHI, but they answer different questions. The backup plan is an environment-wide continuity control: it defines which systems and data sets are copied, how often, where the copies are kept, and how they are restored after a failure or emergency. The device specification is a single hardware action: before a specific piece of equipment is moved, decide whether a retrievable exact copy is needed and, if so, make it. One is a standing program. The other is an event-triggered decision that happens at the point a device leaves your control.

In practice, one backup process can satisfy both if its records show what was copied and when. A Bareos job catalog or a restic snapshot list can establish that a given system's ePHI was copied at a given time, and an auditor can trace that record to the equipment in question. That shortcut has limits. A recent scheduled backup does not, by itself, show that someone assessed whether a move required a copy, and a backup taken last week may not reflect the data on a workstation being retired today. Confirm with your security official that the decision step, the owner, the date and the resulting copy reference are recorded for each device move, even when the copy itself comes from the routine job.

The proposed January 6, 2025 revision would add a separate data backup and recovery standard at 164.312(i), including backup monitoring and testing, as described in the proposed rule in the Federal Register. That proposal is not in force, and the current rule does not contain it. Until a final rule is published, the obligations described above remain the ones that apply, and your records should be built to show both the scheduled backup and the device-level decision.

How assessors test the data backup plan

This table compares five tests an assessor typically runs against the 164.308(a)(7)(ii)(A) data backup plan, the evidence each one asks for, and the gaps that tend to surface. Read each row as what the assessor looks for, not as a guaranteed result, and use it to prepare your own evidence before an audit or OCR inquiry.

Test approach	Evidence requested	Common findings
Confirm a written backup procedure exists and matches the risk analysis	Written backup procedure, dated risk analysis, and a mapping showing which ePHI systems the procedure covers	Procedure exists but does not reflect the current risk analysis or names systems that have since been retired
Sample systems to confirm backups run and are retained	Backup job logs, success and failure reports for a sample period, and retention settings per system	Failed jobs with no documented follow-up, or retention set without a stated business or legal reason
Request a restore demonstration of a selected dataset	Restore record showing the dataset, the backup point used, the time taken, and a check that restored data matches the source	Backups were never restored, or the restore succeeded only for a test file and not for a full ePHI dataset
Review the backup copy's protection from alteration and unauthorized access	Access lists for backup storage, encryption settings, integrity check results, and separation of backup credentials from production	Backup repository reachable by ordinary workforce accounts, or no record of integrity verification
Check that backup scope includes all ePHI systems	Inventory of ePHI locations compared with the backup job list, including endpoints, file shares, databases and SaaS exports	Servers are backed up but laptops, removable media, or SaaS-held records are not, and scope is undocumented

Implementing the data backup plan step by step

This sequence takes a covered entity or business associate from an unclear view of where ePHI lives to a documented, tested backup procedure that a compliance lead can file as evidence of 164.308(a)(7)(ii)(A). Each step closes with a deliverable that feeds the next one.

Confirm the ePHI inventory and criticality ranking
The security official and the system owners list every system, database, file share, and backup target that stores or transmits ePHI, then rank them by how much the business depends on each one. This work draws on the risk analysis and the applications and data criticality analysis under 164.308(a)(7)(ii)(E). The output is a signed inventory with an owner and a criticality rank for each system. Confirm that cloud services, SaaS tools, and endpoints that hold ePHI are on the list, since these are the places teams most often miss.
Define backup scope and retention from the risk analysis
Using the inventory and the risk analysis, the compliance lead and system owners decide what must be backed up, how often, how long copies are kept, and where they are stored. The rule does not set a retention period or backup frequency, so the decisions should trace back to identified risks and to the business's recovery needs. HHS OCR's risk analysis guidance treats identifying what data to back up and how as a decision the risk analysis should inform. The output is a written backup scope statement that lists each system, its frequency, its retention, and its storage location.
Choose and configure backup tooling in your environment
The platform or infrastructure team selects backup software and deploys it inside the organization's own cloud accounts, data centers, or air-gapped network. Open-source options include Bareos, where the Director schedules and supervises backup, restore, verify, and archive jobs and keeps a SQL catalog of backed-up files, and restic, which writes encrypted, deduplicated repositories. Configure the jobs to match the scope statement, and confirm that the tool's restore and verification features do what the team expects before relying on them. The output is a configuration record and a job schedule matched to the scope.
Set up integrity checks and repository access controls
Enable integrity verification on the backup repository so that the stored data can be shown to be complete and unmodified. For restic, this means running the check command on a schedule, with read-data or read-data-subset options to read pack files back and confirm the stored data is intact. Restrict who can write to, delete from, or read the repository, and log those actions. The output is a verification schedule, its logs, and an access list that names the people and service accounts with permissions on the repository.
Run and document an initial restore test
Restore a representative set of files and at least one full system or database from the backup into an isolated test environment. Record what was restored, the source backup point, the time taken, who performed the test, and whether the restored data matched the original. Any failures should be logged with root causes and fixes. This test shows that backups are retrievable, which is the core of the specification. The output is a dated restore test record with results signed by the reviewer.
Write the backup procedure and assign owners
Turn the scope, tooling configuration, verification schedule, and restore test results into a written procedure. The procedure should name the owner for each job, the person who reviews verification logs, the escalation path for failed backups, and the approver for changes to scope or retention. Link the procedure to the disaster recovery plan and the emergency mode operation plan so that restore steps match the wider contingency plan. The output is an approved backup procedure with named owners and a revision history.
Schedule recurring restore tests under contingency testing
Place restore tests on a recurring calendar under the testing and revision procedures in 164.308(a)(7)(ii)(D). Each test should draw on different systems over time, include at least one full restore, and feed any gaps back into the scope, tooling, or procedure. The rule does not set a testing interval, so the risk analysis and the organization's own history should determine how often tests run. The output is an approved testing calendar, a log of completed tests, and a record of changes made after each test.

Evidence that shows a data backup plan works

A backup procedure only counts once it leaves a trail. The cards below cover the documents, scope mapping, job records, verification output, restore tests and repository access records that together show ePHI can be retrieved. Keep them linked to the same backup scope so an assessor can follow one set of ePHI from source system to tested restore.

Written backup procedure

The written procedure states what is backed up, how often, where copies are kept, who runs and reviews jobs, and how failures are escalated. It should reflect the risk analysis decisions on what data to back up and how. Check that the document names the current owner, the review date and the approval record, and that it matches what the backup tools are actually configured to do.

ePHI-to-backup scope mapping

This mapping ties each system holding ePHI to its backup job, retention setting and copy location. Build it from the risk analysis data inventory, not from memory of which servers are important. An assessor will pick a system from the inventory and ask where its copies live, so gaps between the inventory and the backup configuration are the first thing to look for.

Bareos job and catalog records

The Bareos Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. Export job history and catalog entries to show what was backed up, when, and which point in time a restore can select. Keep these records outside the backup server so they survive a compromise of that server.

Restic check and read-back output

Running restic check verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset reads pack files back to confirm the stored backup data is unmodified. Keep dated output from each run, including the subset tested, so the record shows integrity was verified on an ongoing basis rather than once at setup.

Dated restore test records

Restore tests show that backups can be recovered in practice. Each record should state the date, the systems and data restored, the backup point used, who performed the test, and whether the restored data matched expectations. A failed test with a documented fix is better evidence than no test at all, and the results should feed back into the contingency plan.

Repository access records

Backup repositories hold complete copies of ePHI, so access to them needs its own evidence. Export the list of accounts and keys that can read, write, restore or delete backups, along with review records and logs of administrative actions. Confirm that backup administrators are not the only reviewers of their own access, and that deletion of copies is logged.

What meeting the data backup plan costs

This table breaks down the cost components of a HIPAA data backup plan under 164.308(a)(7)(ii)(A), showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for requesting a written quote based on your data volume and scope, since no prices or durations are published here. The main takeaway is that open-source tooling can remove license spend, but staff time, storage and recurring restore testing remain the largest variables.

Cost component	One-time or recurring	What drives it	How to keep it down
Backup software tooling or licenses	Recurring if commercial; none for open source	Commercial licensing model, number of protected hosts, support tier	Choose open-source tools such as Bareos or restic and confirm their license terms with your legal team
Engineering time to design and configure	One-time, with periodic revision	Number of ePHI systems, backup schedules, retention rules, encryption and catalog setup	Map ePHI locations first and scope backup jobs to the systems the risk analysis identifies
Storage and retention capacity	Recurring	Volume of ePHI, change rate, retention period, number of full and incremental copies, off-site copies	Deduplicate and compress, set retention by criticality, and request a storage estimate from your vendor based on your data volume
Restore testing labor	Recurring	Frequency of restore tests, number of systems tested, time to rebuild and verify restored data	Test a representative sample on a fixed schedule and automate integrity checks where the tooling supports them
Integrity verification compute and bandwidth	Recurring	How much backup data is read back for verification, and how often	Scope read-back checks to a subset of data on a schedule, and confirm the impact with your platform team
Evidence upkeep	Recurring	Logs of job results, restore test records, retention settings, and documented changes to the plan	Export job reports and restore records automatically into your documentation system
External review or penetration testing	Recurring, optional	Whether you choose an outside review of backup and recovery, and its scope	Limit scope to the backup infrastructure and recovery paths, and request a fixed-scope written quote
Assessor sampling effort	Recurring at each assessment	How many backup jobs, restore records and plan revisions the assessor samples	Keep records indexed by system and date so samples can be produced quickly

Who owns the backup plan, who can help and where the auditor stops

Your organization owns the data backup plan under 45 CFR 164.308(a)(7)(ii)(A). The rule requires procedures to create and maintain retrievable exact copies of ePHI, and the decisions behind those procedures belong to people inside the covered entity or business associate. Your risk analysis is the input that tells you which systems hold ePHI, how much data is at stake and how quickly it must come back. Your team also decides what is backed up, how long copies are kept and which systems are restored first.

Scope decisions: Decide which systems, databases, file shares and endpoints holding ePHI are in the backup plan, based on the risk analysis.
Retention and recovery priorities: Set retention periods and the order in which applications and data are restored, informed by your criticality analysis.
Restore authority: Name who may approve a restore, a restore to a new location or the release of backup media.
Sign-off and records: Approve the written plan, review restore test results and keep the documentation the rule expects.

Check that each of these decisions has a named owner and a dated record of approval before any partner begins technical work.

Where organizations fall short on backup plans and how to close the gap

Most backup programs exist on paper and run on schedule, yet fail the moment someone needs an exact, retrievable copy of ePHI. The gaps below cluster around four questions an assessor will ask: what is backed up, how it is tied to the risk analysis, whether the copies are protected, and whether restores were proven and recorded.

Backups configured but never restored

A job that reports success proves only that data was written somewhere. Section 164.308(a)(7)(ii)(A) asks for retrievable exact copies, so the plan must show that files can be brought back intact. Assign the security official or system owner to run a dated test restore of a defined ePHI dataset each quarter, compare the restored output against the source, and keep the result with the plan. Ask the backup administrator to confirm the restore tool and version used.

Scope that omits SaaS, endpoints and shadow copies

Backup scope is often drawn around the core database and file server, while ePHI also sits in SaaS mailboxes, laptops, exported spreadsheets, and staff-held copies. Build the inventory from the same data-flow map used for the risk analysis, then list each location as in scope, out of scope with a documented reason, or covered by a vendor's backup terms. Ask the team to search for exports and local caches before signing off the scope.

No documented link to the risk analysis

OCR's risk analysis guidance names identifying what data to back up and how as a decision the risk analysis should inform. When the backup plan is written without reference to the risk analysis, the reasons for frequency, retention and location cannot be traced. Require the backup plan to cite the risk identifiers it addresses and the applications and data criticality ranking it uses. Ask the security official to confirm that each backup decision maps to a documented risk or an accepted residual risk.

Backup repositories without access control or integrity checks

A backup repository holds a complete copy of ePHI, so an unprotected repository is an exposure and a ransomware target. Check that repository credentials are separate from production administrator accounts, that access is logged, and that stored data is protected against deletion or alteration. For open-source tools, have the engineer run restic check with --read-data-subset on a schedule so that pack files are read back and verified, and record the output.

Restore tests that are not recorded

Restore tests that happen informally leave no evidence, and an assessor cannot credit them. Each test should record the date, the dataset, the person who ran it, the restore time observed, the comparison method, and any failure with its corrective action. Store these records with the contingency plan, linked to the testing and revision procedures in 164.308(a)(7)(ii)(D). Ask the compliance lead to sample the last two test records before the next assessment.

Questions buyers ask about the backup requirement

How much effort does a HIPAA data backup plan take, and what drives it?

The effort depends mainly on how many systems hold ePHI, how much data they hold, and how many of those systems the risk analysis and applications and data criticality analysis mark as critical. Most of the work is one-time design: listing every ePHI store, deciding what must be copied and how often, choosing where copies live, and writing the procedures. Recurring work is operational: running jobs, watching failures, rotating media or keys, and running restore tests. Costs rise with more systems, longer retention, multiple sites, and stricter restore expectations. Ask any quote to separate design, build, and first-year operation so you can see which part recurs.

Can our own team set up HIPAA-compliant backups without a partner?

Yes, a covered entity or business associate can design and run its own backup plan, and the Security Rule does not require outside help. The standard asks for procedures to create and maintain retrievable exact copies of ePHI, so the question is whether your team has the skills to build, document, and test those procedures. Teams that run backup tooling daily often handle the build well and struggle with the written plan, the restore tests, and the evidence trail. Consider a partner if your staff lacks backup engineering time, if systems span cloud and on-premises environments, or if you need an independent review of the design.

What does the backup work need from our internal staff?

Your staff must supply knowledge that no outside party can infer on its own. That includes which applications hold ePHI, who owns each system, what recovery priority each one has, and how clinical or business operations depend on them. Staff also approve the retention period, approve where copies are stored, and sign off on the restore test results. Someone in your organization should own the plan as the designated contingency lead and review restore evidence on a schedule. Plan for these contributions early, because delays in naming system owners are a common cause of slow backup projects.

How long does setting up a HIPAA backup plan take?

Timing depends on scope and environment: the number of ePHI systems, whether they run in a cloud account or in your data center, how many backup targets you need, and how quickly your team can approve the design. A single system with an existing backup tool is a far smaller job than a multi-site environment that needs new tooling and restore testing. Ask any partner for a timeline tied to a written scope, with milestones for inventory, design, build, restore testing, and documentation. Do not accept a duration that is not connected to the systems in scope.

Do HIPAA backups have to be encrypted?

The backup specification in 45 CFR 164.308(a)(7)(ii)(A) does not itself state an encryption rule, but encryption is covered by a separate topic in this guide set. Read the encryption requirements there before you design the backup repositories, because the answer affects key management, storage location, and restore procedures. Your risk analysis should also record how backup copies are protected in transit and at rest. Confirm the exact requirements with your compliance lead or counsel rather than relying on a general summary.

Can a partner certify that our backups meet HIPAA?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and HHS does not endorse or recognize private certifications. A partner can prepare your backup design, configure the tooling, run restore tests, and organize evidence, but it cannot issue a HIPAA certificate or attestation. Any vendor offering a HIPAA certification should be treated with caution. Compliance is demonstrated through your own documentation and records, which OCR can review in a complaint investigation, compliance review, or audit.

What does a partner deliver, and what does an auditor test?

A partner delivers the working system and its evidence: a documented inventory of ePHI stores, backup and retention configuration, restore test records, and procedures your staff can follow. The organization owns the controls and the decisions behind them. An independent auditor or assessor, where one is engaged, tests whether the controls operate as described and whether the evidence supports the claim. The auditor does not design your backups, and a partner does not judge its own work. Keep those roles separate in your contract and in your records.

How DeployOpen scopes and prepares backup evidence

DeployOpen works on the data backup plan as an implementation partner. We set up backup systems and evidence inside your own infrastructure, so your organization owns the plan, the decisions behind it and the restore tests that show retrievable copies of ePHI. Only an independent assessor or auditor can judge whether your program meets the requirement.

How we scope

Engagements are fixed-scope, with the systems holding ePHI and the backup targets named in writing before work starts.
We confirm which applications and data sets are in the backup scope, using your risk analysis and criticality ranking as inputs.
The written scope states which backup platform, retention approach and restore test deliverables are included and excluded.

How we build

We deploy Bareos on your own infrastructure, with the Director, storage and SQL catalog configured for your backup schedule.
Where encrypted deduplicated repositories fit the scope, we configure restic and run its check command with read-data options to confirm stored data is unmodified.
We set up restore jobs for representative systems so your team can show that backed-up ePHI can be retrieved as an exact copy.

How we hand over

We document the backup procedures, schedules, job logs, verification results and restore test records in a format your assessor can review.
Restore test results are recorded with dates, scope, outcome and any corrective action, so evidence traces back to each test.
Your team receives runbooks and access to the catalog and logs, and you confirm which items remain your responsibility after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which you can add after the initial scope closes.
We can help you prepare backup evidence for an assessment, but the organization and the independent assessor remain responsible for conclusions.
Before any engagement, confirm with us which backup and recovery requirements from the proposed rule your environment would need to meet.