164.310(d)(2)(iv) Data backup and storage for HIPAA

What 164.310(d)(2)(iv) data backup and storage asks before equipment moves

The requirement asks for a retrievable, exact copy of electronic protected health information (ePHI), made when needed, before the equipment holding that data is moved. It targets a specific loss event: ePHI disappearing during relocation, repair or replacement of a server, workstation, storage array or removable medium. A move is a point where drives get powered down, shipped, swapped or wiped, and where a single missing copy can leave an organization unable to serve patients or prove what records it held.

The specification is addressable, not required. Under 45 CFR 164.306(d)(3), the organization must first assess whether a copy step is reasonable and appropriate for its environment. If it is, the organization implements it. If not, it must document why and adopt an equivalent alternative measure where that is reasonable and appropriate. In practice, most organizations will find that copying data before a move is reasonable, so the documented decision is usually to implement it, but the assessment itself still needs a written record. Assessors look for that reasoning, not only for a backup file.

What makes this hard in practice is rarely the copy itself. Teams often do not know every location where ePHI sits before a move, including local caches, exported spreadsheets and shadow copies on laptops. A copy made without a verified restore test proves little, because the question is whether the data can be retrieved, not whether a job reported success. Ask who decides when a pre-move copy is required, what the restore check looks like, and where the record of each copy is kept. The broader, required data backup plan sits in the contingency plan standard at 45 CFR 164.308(a)(7), so this step should feed that plan rather than replace it.

Which systems, media and teams fall under the pre-move copy step

The pre-move copy step applies wherever ePHI sits on hardware or media that is about to be relocated, repaired or retired. The cards below cover the asset types, the teams and the third parties that decide whether a move triggers the step, so the scope is settled before any equipment leaves a site.

Servers and database hosts

Physical and virtual servers that run EHR databases, file shares, imaging archives or application back ends are the most common reason this step applies. Before a rack move, data center migration or hardware swap, confirm which volumes hold ePHI, whether application-consistent copies exist, and who signs off that the copy can be restored. Inventory these hosts against the risk analysis so none is missed during a change window.

Storage arrays and SAN volumes

Storage arrays often hold ePHI across many logical volumes, snapshots and replicas, and a controller swap can make the data unreadable without a copy. Ask whether the array's own replication is an exact, retrievable copy or whether an independent copy is needed. Record every LUN, pool and replica that contains ePHI, since a copy that omits one volume leaves that data exposed during the move.

Laptops, workstations and removable media

Laptops, desktops, USB drives and external disks are moved far more often than servers and are easy to overlook. Check local storage, synced folders and removable drives used for clinical or billing work before equipment is reassigned, shipped for repair or taken off site. Workstation use and device controls usually live in different policies, so confirm which team owns the copy decision for user-held devices.

Backup appliances and tape

Backup appliances, tape libraries and the media they write to are themselves storage that can hold ePHI. A move of the backup hardware can break the chain of recoverable copies if the catalog and media are not kept in step. Confirm that the catalog can locate every copy after relocation, and that encrypted or offline media can still be read on the target equipment.

Cloud-hosted ePHI

ePHI in cloud services does not move on a truck, but provider migrations, region changes, account consolidation and service retirements can require an exact, retrievable copy before the change. Review the provider's business associate terms and shared responsibility split, then document who initiates the copy and where it is stored. Cloud snapshots that the provider controls may not satisfy the step on their own.

Equipment handled by vendors

Hosting providers, colocation staff, repair depots and equipment lessors may take custody of devices that hold ePHI. Business associates and their subcontractors can hold ePHI on equipment the covered entity never sees, so contracts should require the vendor to notify the covered entity before any move and to support the copy. Ask vendors for their written procedure, the people accountable for each device, and proof of copy before custody changes.

Facilities, IT operations and asset management

Facilities teams schedule moves and control physical access, IT operations performs the copy and verifies it, and asset management records who is responsible for each device. The pre-move step fails most often at the handoffs between these groups. Assign one owner for each move, require a ticket that lists affected assets and ePHI locations, and keep the copy verification result in the same record as the movement log.

How this differs from the required backup plan in 164.308(a)(7)

The addressable specification in 164.310(d)(2)(iv) is much narrower than the required data backup plan in 164.308(a)(7)(ii)(A). The backup plan is a continuous contingency measure that keeps retrievable copies of ePHI so operations can resume after a loss. The specification here is a single, equipment-linked step: when a device or electronic medium holding ePHI is about to be moved, the organization must consider whether to create a retrievable, exact copy first. Your contingency plan answers the question "can we recover if systems fail?" This specification answers "do we have a verified copy before this hardware leaves our control?" Confirm that both live in your documentation, and that the move procedure in your device and media controls points to the backup plan for the actual copy method.

Under 45 CFR 164.306(d)(3), the decision runs in three steps. First, assess whether a retrievable exact copy before the move is reasonable and appropriate for each category of equipment, considering the ePHI it holds, the move's risk and the copy's availability. Second, if it is reasonable and appropriate, implement it, for example by taking a verified copy with a tool your team already operates and recording the result. Third, if it is not, document the reasons and implement an equivalent alternative measure, provided that measure is reasonable and appropriate. Tools such as Bareos and restic can produce and verify copies, and restic's check command with read-data options can confirm stored data is unmodified, but the assessment and the record of the decision belong to your organization. Keep the assessment dated and approved, and revisit it when equipment types or move procedures change.

Illustrative example: a diagnostic imaging workstation with a failed disk is being sent to a vendor for repair, and the disk cannot be read reliably enough to copy. The documented alternative might state that the ePHI on the workstation was replicated to the managed storage system before the failure, that the most recent replica was verified against the source, that the vendor contract prohibits retention of any media and requires certified destruction, and that the device is logged in the movement record. A reviewer would then ask whether the replica is actually retrievable and whether the vendor terms are enforceable, so test a restore from that replica and confirm the contract language with counsel before relying on the alternative.

How an assessor tests the pre-move copy and what evidence passes

This table compares what an assessor does, what evidence they request and where organizations usually fall short for each part of the 164.310(d)(2)(iv) pre-move copy. Read it as a checklist: each row is a test point, and the findings column shows where a documented decision or a traceable link is missing.

Test point	What the assessor requests	Common findings
Documented addressable decision	The written assessment of whether making an exact copy before a move is reasonable and appropriate, the reasoning, and either the implementation or the documented equivalent alternative	No documented decision exists, or the decision was made informally and never reviewed
Move procedure	The written procedure that tells staff to create a retrievable copy of ePHI before hardware or media leave or are moved, with a named owner and approval point	Procedure covers disposal or re-use but says nothing about moves, or staff describe a practice the document does not contain
Sample equipment moves	A sample of recent moves, such as ticket or change records, traced to the backup job or copy created before the device left the site	Move tickets exist but no link to a backup job, so the assessor cannot confirm a copy preceded the move
Copy existence and scope	Backup job records, catalog or inventory showing which ePHI sets were copied, when, and where the copy is held	Copies exist for some systems but not for the devices actually moved, such as laptops, removable media or local storage
Restore test of a sampled copy	Evidence that a sampled copy was restored to a usable state, with the restore date, the person who ran it and the result	Copies exist but cannot be restored, the restore was never tested, or the restored data could not be verified as complete
Integrity verification	Records showing that the stored copy was checked for consistency, such as verification job logs or repository check output	No verification step, or logs that show jobs ran without any integrity check
Access to the copy	Evidence that the copy is protected in line with the organization's other ePHI safeguards and that access is limited to authorized staff	Copies sit on shared storage or personal devices with broader access than the source system allowed

Implementing the pre-move copy step in six stages

This sequence turns the addressable pre-move copy step into a documented, tested and repeatable routine, so that before any equipment holding ePHI is moved, the organization knows what is being moved, has a retrievable copy, and can show an assessor how it got there.

Inventory equipment and media that hold ePHI
Start by listing every server, workstation, laptop, storage array, removable medium and backup appliance that stores or temporarily holds electronic protected health information. Compare the list against your risk analysis and data flow records so that nothing holding ePHI is missed. The owner of the asset register, usually IT operations with input from the security official, signs off the inventory. The step is complete when each item has an owner, a location and a note on whether it holds the only copy of any ePHI.
Make and document the addressable decision
Under 45 CFR 164.306(d), assess whether a retrievable exact copy before a move is reasonable and appropriate for each category of equipment. If you implement it, record that decision. If you do not, document why and describe the equivalent alternative measure you adopt, such as encryption of the data before transport or a verified backup taken on a fixed schedule. The security official and a business leader should approve the decision record, which becomes evidence for the assessor that the specification was actually considered.
Define the move trigger in procedures
Write the trigger into your change management and asset disposition procedures so that any relocation, repair, return, replacement or decommissioning of covered equipment starts with a copy check. Name who may approve a move, who performs the copy, and who confirms it before the equipment leaves. The procedure should also link to the device accountability record so that movement and copy are tied together. The step is done when the procedure has been approved and staff who handle moves have been told where it lives.
Set the copy method, scope and retention
Choose the tool and method for the pre-move copy, such as a full image, an incremental backup or a snapshot, and set how long the copy is kept after the move. Open-source options include Bareos, which schedules backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files, and restic, which stores encrypted, deduplicated snapshots. Retention should respect your contingency plan and any longer period your own policies set for documentation. Write these settings into a runbook with the exact job names, repository locations and access controls, and confirm them with your engineers against the vendor documentation before relying on them.
Test restores before relying on the copy
A copy that cannot be restored does not satisfy the step. Run a restore test on a sample of each equipment category, and use integrity checks where your tool provides them. For example, restic's check command verifies the structure of snapshots, trees and pack files, and its read-data options read pack files back to confirm the stored data is unmodified. Record the date, the tester, the data set restored, the result and any fault found, and fix faults before the next move. The restore test log is the evidence that the copy is retrievable, not just present.
Record each move and close the loop
For every movement of covered equipment, create a move record that names the device or medium, the copy identifier, the person who confirmed the copy, the destination, and the date and time of the move. Store the copy identifier with the record so that a later investigator can find the exact copy that existed before the move. Review move records periodically against the inventory, and feed any gaps or failed restores back into the risk analysis and the procedure. The step is complete when the move record set can be traced from an asset back to its copy and to the approval that allowed the move.

Bareos and restic for producing the copy and proving it restores

The copy required by 164.310(d)(2)(iv) is only useful if it can be produced on demand and shown to be intact. Bareos produces the job record of each copy, while restic produces integrity evidence on the stored data. Neither tool decides whether a copy is made before equipment moves; that decision, and the procedure around it, stays with the organization.

Bareos as the job record

Bareos is licensed under AGPL-3.0-only. Its Director schedules and supervises backup, restore, verify and archive jobs, and keeps a SQL catalog of the files it has backed up. For 164.310(d)(2)(iv), that catalog and the job logs give you a record to link to each pre-move copy, showing when it ran and what it covered. Confirm that job records are retained long enough to answer an assessor's questions about a specific device move.

Restores from a point in time

Bareos can restore files selected from the current backup or from one taken before a given date and time. This matters when equipment is moved after a problem has already started, because the copy you need may be the one taken before the move, not the latest one. Test this with a restore drill on a non-production system and record the result, since a documented restore is stronger evidence than a backup job marked as successful.

restic integrity checks

restic is licensed under BSD-2-Clause. Its check command verifies the structural consistency of snapshots, trees and pack files. Adding --read-data or --read-data-subset makes it read pack files back to confirm the stored backup data is unmodified. Schedule these checks and keep the output, since they show that the copy you would restore is intact at the time of the check, not only at the time it was written.

Reading data versus structure

The structural check and the data read-back answer different questions. A structural check confirms that the repository's metadata is consistent. A read-data check confirms that stored content can be read and matches what was written. Full read-data checks take longer and cost more I/O than structural checks, so decide with the security official how often each runs and whether a subset check is acceptable for routine runs.

Copy decisions stay with the organization

Neither tool decides whether a pre-move copy is required, which systems it covers, or who authorizes the move. Those decisions belong in the device and media procedure, and an addressable specification still requires you to document why a measure is or is not reasonable and appropriate. Use the tools to produce and check the copy, and keep the decision record separate from the tool output.

License review before deployment

AGPL-3.0-only obligations can apply to modified versions of Bareos that are offered to users over a network, so changes to the software may trigger source disclosure duties. restic's BSD-2-Clause terms carry fewer conditions. Have counsel review the license terms for your deployment, including any customization DeployOpen or your own staff makes, before the tooling is placed in production.

What meeting the pre-move copy requirement costs

This table lists the cost components of making a retrievable exact copy of ePHI before equipment moves, who is paid for each, whether it is one-time or recurring, and what drives it up. Use the last column to decide what to request in a written quote. No dollar figures appear because none were supplied for this requirement.

Cost component	One-time or recurring	What drives it up	What to ask for in a quote
Backup tooling or licenses	One-time setup, recurring if commercial	Number of systems holding ePHI, licensing model per host or terabyte, need for vendor support contracts	Whether the tool is open source, which license applies (for example AGPL-3.0-only for Bareos or BSD-2-Clause for restic), and any paid support or subscription lines
Storage capacity for copies	Recurring	Volume of ePHI, retention period for copies, number of sites and copy locations, encryption overhead	Storage sizing assumptions, retention periods, where copies sit (on-premises, cloud or air-gapped), and who pays for storage growth
Engineering time to build the procedure and runbooks	One-time, with periodic revision	Number of equipment types, complexity of the environment, integration with the contingency plan under 164.308(a)(7)	Named deliverables such as the move procedure, copy verification steps and sign-off roles, plus the hours or fixed fee per deliverable
Restore testing	Recurring	Restore frequency, data volume per test, number of systems in scope, need to test before each equipment move	Test schedule, what a test restores and verifies, how results are recorded, and whether test restores run in the client's environment
Evidence upkeep for move records	Recurring	Frequency of equipment moves, number of people who handle hardware, linkage to the accountability record under 164.310(d)(2)(iii)	Format of the move log, who maintains it, retention of copy verification records, and how records are produced at audit
External testing or review	Recurring or periodic	Scope of the review, whether the copy process is tested alongside other safeguards, depth of sampling	Whether the review is a fixed-scope engagement, the testing method, and whether results go to the client only
Auditor or assessor sampling time	Recurring, set by the assessor	Number of moves sampled, number of sites, quality of existing records	Confirm with the assessor how many moves they sample and what evidence they request before the review starts
Documentation of the addressable decision	One-time, with annual review	Number of exceptions, need for an equivalent alternative measure under 164.306(d)	Whether the decision record is included in scope and who approves it, the security official or the organization's management

Evidence that satisfies the pre-move copy and how to keep it current

An auditor testing 164.310(d)(2)(iv) will look for proof that the organization decided how to handle this addressable step, that the copy happens before equipment moves, and that a copy can actually be restored. The cards below cover the records that prove each of those points and the routine checks that keep them current between audits.

Addressable decision record

This is the written determination that the pre-move copy is either implemented or replaced by an alternative. It should name the equipment classes it covers, state why the step is or is not reasonable and appropriate given the ePHI involved, and be signed by the security official. Review it whenever the backup architecture or the population of moved equipment changes, and confirm the reasoning still holds rather than reusing last year's text.

Equipment move procedure

The move procedure should place the copy step before any hardware or media leaves its location, name the person who confirms the copy, and point to the backup job record that proves it. Walk through the procedure against a sample of recent moves each quarter to confirm staff follow it in practice, not just on paper. Record every deviation and the corrective action taken.

Backup job logs linked to move tickets

A backup job log shows that a copy ran, but it only satisfies this step when it is tied to a specific move ticket by time, system and equipment identifier. Require the ticket to reference the job ID and completion status before the move is approved. Each quarter, pick a sample of tickets and confirm the linked job completed successfully and covers the device being moved.

Restore test results

A copy that cannot be restored does not meet the intent of the step. Record each restore test with its date, the systems and data sets included, who ran it, and whether the restored data matched the source. Set the test schedule in the organization's own risk-based plan, and include at least one test that restores from a copy created before a move. Open-source tools such as restic can verify backup data by reading pack files back, which gives a repeatable check to record alongside the restore test.

Alternative measure record

Where the copy is not done, the organization must document why it is not reasonable and appropriate and what equivalent measure replaces it. Typical examples include full-disk encryption with secure key escrow, or a verified replication copy held elsewhere. Keep the alternative measure current with the equipment it covers, and confirm the chosen measure still protects the ePHI as the environment changes. Illustrative case: a device that holds only transient data may need a documented alternative rather than a backup copy.

Asset movement log

The asset movement log records each movement of hardware and electronic media, the person responsible, and the destination. It is the anchor that lets an assessor connect a move to its copy, its move ticket and its restore test. Reconcile the log against the asset inventory each quarter, and investigate any device that moved without a matching ticket or copy record.

Who owns the copy, who can prepare it and what the auditor checks

Your organization owns the Security Rule obligation. The addressable decision is yours: you must assess whether making a retrievable exact copy of ePHI before equipment is moved is reasonable and appropriate for your environment, implement it if it is, and document the reasoning and any equivalent alternative if it is not. Your workforce also runs the move procedure and performs the restore tests that show the copy actually works.

The addressable decision: a written assessment, signed off by the security official, that records why the step applies to each class of equipment holding ePHI.
The move procedure: the steps staff follow before any server, storage array, laptop or media leaves a facility or is repurposed, including who authorizes the copy.
Restore tests: scheduled, recorded restores from the copy into a test environment, with results reviewed by a named person.
Ownership of exceptions: any equipment class excluded from the copy, with a documented alternative measure and its rationale.
Linkage to the contingency plan: confirmation that this step fits inside the broader data backup plan required under 164.308(a)(7).

Before engaging anyone, confirm internally who signs the addressable decision and who can approve a move.

Common questions about the pre-move copy step

Is the data backup and storage step under HIPAA required or addressable?

It is an addressable implementation specification, not a required one. Under 45 CFR 164.306(d)(3), you must first assess whether making a retrievable exact copy of ePHI before equipment is moved is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you must document why and implement an equivalent alternative measure if one is reasonable and appropriate. Addressable does not mean optional: the assessment and its documented outcome are what an auditor or OCR investigator will ask to see.

Is there a HIPAA certification that covers this safeguard?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and it does not endorse or recognize private certifications. Any vendor or consultant offering a HIPAA certificate for this step is offering something HHS does not recognize, and such a certificate would not prevent OCR from later finding a violation. What you can provide is documented evidence: your assessment of the specification, the copy procedure, restore test records and equipment movement logs. Independent assessors may review that evidence, but they do not certify HIPAA compliance.

How much effort does the pre-move copy step take, and what drives it?

The effort depends on how many systems hold ePHI, how often hardware is moved or replaced, and whether copies already exist from your contingency backups. Most of the work sits in the assessment and documentation, then in building a repeatable procedure that staff follow before each move. Effort rises with the number of storage locations, the volume of data, the need to verify restores, and the number of teams that move equipment. No duration figure is supplied for this step, so ask any provider to break the estimate into assessment, procedure, tooling and testing hours in a written scope.

Can an in-house team carry out this work without outside help?

Often yes, if the team already runs backup and restore operations and owns asset tracking. The work needs staff who know where ePHI resides, who can document the addressable decision, and who can test restores. Teams without that experience usually need help with the design of the procedure and the restore verification. An in-house team should still confirm that its assessment is defensible, because the decision to implement or document an alternative is the organization's responsibility, not a tool's.

What does the organization need to provide before a partner can start?

A partner needs an inventory of systems and media that hold ePHI, the current risk analysis, the existing contingency and data backup plan under 45 CFR 164.308(a)(7)(ii)(A), and the equipment move procedures in use. It also needs access to the environments where copies will be made and written sign-off on who approves moves. Without these inputs, a partner cannot tell which equipment moves need a copy or how the copy relates to the broader backup plan.

Can a partner prepare the evidence for this specification?

A partner such as DeployOpen can plan, implement and document the technical side, including configuring backup tooling in your own infrastructure, writing the pre-move procedure and collecting restore test records. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. The organization still owns the addressable decision and the risk judgment, and an independent assessor reviews the evidence. Ask any partner to confirm in writing which parts it delivers and which remain yours.

Which open-source tools help produce evidence for the copy step?

Bareos can schedule and supervise backup, restore and verify jobs and keeps a SQL catalog of backed-up files, which gives you a record of what was copied and how to restore a selected file. restic can check snapshots, trees and pack files for structural consistency, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Both tools produce logs you can attach to the evidence file. Confirm that each tool meets your encryption and access requirements before storing ePHI in it.

How DeployOpen scopes and prepares the pre-move copy evidence

DeployOpen plans and implements self-hosted open-source backup tooling inside your own infrastructure so that a retrievable, exact copy of ePHI can be made before equipment is moved. The organization still owns the safeguard, and an independent assessor decides whether the evidence is sufficient.

How we scope

Written scope identifies every system, device and media type holding ePHI that may be moved or retired.
Scope records which move events trigger a pre-move copy and who authorizes each move.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Configure a backup director and catalog, such as Bareos, to schedule and supervise copy jobs for in-scope systems.
Set retention and restore testing so the copy can be retrieved as an exact, usable copy when needed.
Apply integrity checks, such as restic check with read-data options, to confirm stored backup data is unmodified.

How we hand over

Document the pre-move copy procedure, roles and decision points in language your staff can follow.
Provide job logs, catalog exports and restore test records mapped to the evidence an assessor will request.
Record the documented reason and equivalent alternative measure if the copy is judged not reasonable and appropriate.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Review the copy procedure when equipment moves, system changes or the scope in the written agreement changes.
Confirm with your compliance lead and independent assessor which evidence formats they accept before build starts.