[ HIPAA BACKUP ]
The Security Rule does not say “back up nightly.” It says what your contingency plan must contain. Here is the regulation, quoted, and what each part means in a dental practice.
Updated
The standard sits in the Security Rule’s administrative safeguards. This is the text, quoted from the Electronic Code of Federal Regulations (current to 2 October 2026).
(7)(i) Standard: Contingency plan. Establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information.1
The standard has five implementation specifications. Three are required and two are addressable:
| Specification | Status in the regulation | What the regulation says |
|---|---|---|
| Data backup plan | Required | Establish and implement procedures to create and maintain retrievable exact copies of electronic protected health information.2 |
| Disaster recovery plan | Required | Establish (and implement as needed) procedures to restore any loss of data.3 |
| Emergency mode operation plan | Required | Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.4 |
| Testing and revision procedures | Addressable | Implement procedures for periodic testing and revision of contingency plans.5 |
| Applications and data criticality analysis | Addressable | Assess the relative criticality of specific applications and data in support of other contingency plan components.6 |
The regulation defines both words. A required specification must be implemented. An addressable specification is not optional: you assess it, and either implement it or document why not and put an equivalent measure in place.
(2) When a standard adopted in § 164.308, § 164.310, § 164.312, § 164.314, or § 164.316 includes required implementation specifications, a covered entity or business associate must implement the implementation specifications.7
(3) When a standard adopted in § 164.308, § 164.310, § 164.312, § 164.314, or § 164.316 includes addressable implementation specifications, a covered entity or business associate must— (i) Assess whether each implementation specification is a reasonable and appropriate safeguard in its environment, when analyzed with reference to the likely contribution to protecting electronic protected health information; and (ii) As applicable to the covered entity or business associate— (A) Implement the implementation specification if reasonable and appropriate; or (B) If implementing the implementation specification is not reasonable and appropriate— (1) Document why it would not be reasonable and appropriate to implement the implementation specification; and (2) Implement an equivalent alternative measure if reasonable and appropriate.8
The sections below follow each specification. After the regulation’s words, the explanations are DDSArk’s own plain-English guidance for dental practices, not regulatory text. Where a section mentions DDSArk, the wording is from the approved claims list.
Procedures “to create and maintain retrievable exact copies” of electronic patient information. Three words carry the weight: procedures (a repeatable, written method rather than someone remembering), retrievable (you can actually get the copy back) and exact (a faithful copy, not a summary).
For each one, decide how it is copied, how often, and where the copy lives, and write that down.
The written procedure itself (the regulation requires policies and procedures to be kept in writing, quoted under “Documentation” below). Our suggestion, not a regulatory list: keep the job logs and a record that someone checked that the copies are complete.
Keep at least one copy away from the practice, keep at least one copy that the systems it protects cannot alter or delete, encrypt copies, and verify that each copy matches what it was taken from. How DDSArk fits: Immutable recovery points; Encrypted with AES-256-GCM, client-side before upload; Replicated to a second, independent provider (Wasabi).
Procedures “to restore any loss of data.” A copy that nobody knows how to restore does not meet this. The regulation sets no restore time, so the targets are yours to set from your own priorities.
The written restore procedure and restore order, the contact list, and the results of your restore tests (see the testing section).
Restore to clean or separate hardware instead of over a system you do not trust, keep a copy close to the practice for speed and a copy away from it for safety, and keep a printed copy of the procedure. How DDSArk fits: Backups are restored at the edge: the DDSArk agent downloads and decrypts them at the practice. Median restore time 11 min (median time to recover a full practice server, per DDSArk restore tests).
Procedures “to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode.” The plan is about two things at once: keeping the practice working, and keeping patient information protected while normal systems are unavailable.
The written emergency procedure and the name or role that authorises it.
A daily export or printout of the schedule and a way to read recent records without the full system make the paper fallback much shorter. Your own systems decide what is possible.
Procedures “for periodic testing and revision of contingency plans.” The regulation does not define “periodic.” Because the specification is addressable, you must assess it and either implement it or document why not and what you do instead.
If you implement testing, your records of it. If you decide not to, the written reason and the equivalent measure.
You need backups you can restore to a separate machine without touching production. Our HIPAA backup self-check turns this into a short list of questions.
To “assess the relative criticality of specific applications and data in support of other contingency plan components.” This is the step that decides your restore order and your targets, so do it first even though the regulation lists it last.
Example only, not a requirement. The regulation requires the assessment, not these answers; your ranking may differ.
| System | Example rank | Why (in this example) |
|---|---|---|
| Practice management | 1: restore first | The schedule, charts and ledger all depend on it. |
| Imaging | 1: restore first | Clinical decisions need current images. |
| Phones and fax | 2: restore next | Needed to reach patients and reschedule. |
| Documents and scanned forms | 2: restore next | Consents and histories support treatment. |
| Claims and clearinghouse access | 2: restore next | Revenue depends on it, but it can wait for the clinical systems. |
| 3: when possible | Important, but the practice can run for a short time without it. |
The written assessment, and evidence that your restore order and targets follow from it. Update it when you add or retire a system.
Match the copy strategy to the ranking: the systems you restore first should have the copy you can restore fastest.
Practices focus on § 164.308(a)(7) and miss these. Each is quoted first, then explained.
(i) Contingency operations (Addressable). Establish (and implement as needed) procedures that allow facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan in the event of an emergency.9
Recovery needs physical access too: who can get into the office or the equipment room after hours in an emergency, and who holds the keys or codes.
(iv) Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected health information, when needed, before movement of equipment.10
An office move, a server replacement or a workstation refresh is a moment to take a fresh copy first.
(ii) Emergency access procedure (Required). Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.11
Separate from the backup itself: how someone gets the patient information they need when the normal route is down.
(b)(1) Standard: Documentation. (i) Maintain the policies and procedures implemented to comply with this subpart in written (which may be electronic) form; and (ii) If an action, activity or assessment is required by this subpart to be documented, maintain a written (which may be electronic) record of the action, activity, or assessment.12
(i) Time limit (Required). Retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later.13
Treat the contingency plan and your records of testing it as documentation to keep for the full period.
(b)(1) Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.14
(3) Implementation specifications: Written contract or other arrangement (Required). Document the satisfactory assurances required by paragraph (b)(1) or (b)(2) of this section through a written contract or other arrangement with the business associate that meets the applicable requirements of § 164.314(a).15
(2) Implementation specifications (Required)—(i) Business associate contracts. The contract must provide that the business associate will— (A) Comply with the applicable requirements of this subpart; (B) In accordance with § 164.308(b)(2), ensure that any subcontractors that create, receive, maintain, or transmit electronic protected health information on behalf of the business associate agree to comply with the applicable requirements of this subpart by entering into a contract or other arrangement that complies with this section; and (C) Report to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required by § 164.410.16
A backup service or IT provider that stores copies of your electronic patient information is maintaining it on your behalf, which is the situation these provisions address. Ask your compliance adviser how they apply to your arrangements. See also whether your backup provider needs a BAA and our HIPAA and BAA page. How DDSArk fits: Signs a HIPAA Business Associate Agreement; Master BAA available for multi-location groups.
Proposed — not in effect Status verified
On 6 January 2025, HHS published a proposed rule (90 FR 898) that would rewrite parts of the Security Rule. It is a proposal, not law. Nothing below is a current obligation; the rule described above stays in force unless and until a final rule takes effect. Status: As of 2026-10-06, the Federal Register lists one document under rulemaking identifier RIN 0945-AA22: the proposed rule "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information", published 6 January 2025 (90 FR 898, document 2024-30983). No final rule has been published under that identifier.17
The proposal would move contingency planning to a new § 164.308(a)(13). The proposed text, quoted from the Federal Register, includes:
(13) Standard: Contingency plan —(i) General. Establish and implement as needed a written contingency plan, consisting of written policies and procedures for responding to an emergency or other occurrence—including but not limited to fire, vandalism, system failure, natural disaster, or security incident—that adversely affects relevant electronic information systems.18
(B) Data backups. Establish and implement written procedures to create and maintain exact retrievable copies of electronic protected health information, including verification that the electronic protected health information has been copied accurately.19
(C) Information systems backups. Establish and implement written procedures to create and maintain backups of the covered entity's or business associate's relevant electronic information systems, including verification of success of backups.20
(D) Disaster recovery plan. (1) Establish (and implement as needed) written procedures to restore loss of the covered entity's or business associate's critical relevant electronic information systems and data within 72 hours of the loss.21
(2) Review and test contingency plans required by this paragraph (a)(13) at least once every 12 months, document the results of such tests, and modify such contingency plans as reasonable and appropriate in accordance with the results of those tests.22
(D) Report to the covered entity activation of its contingency plan under § 164.308(a)(13) without unreasonable delay, and in no case later than 24 hours after activation of the contingency plan.23
Read the full document at the Federal Register (90 FR 898); HHS also publishes a fact sheet on the proposal. Adopting some of these practices early (written backup verification, an annual restore test) is a reasonable choice for any practice, but it is a choice, not a requirement today.
No. Here is what the regulation itself shows: The text of the HIPAA Security Rule (45 CFR 164.302 through 164.318, Subpart C of Part 164), as published in the eCFR up to date as of 2026-10-02, contains no occurrence of the word stems "certif" or "accredit": it contains no certification or accreditation program.24 The rule’s own way of checking where a practice stands is an evaluation that the practice carries out:
(8) Standard: Evaluation. Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart.25
HHS has an FAQ on the related question, titled “Are we required to certify our organization’s compliance with the standards?”
So when a vendor says its product has a HIPAA seal, ask for what actually matters instead: a signed business associate agreement, a written description of its safeguards, and evidence that it restores. Ask when it last restored a customer-sized dataset, how long that took, and whether you can see the record.
We turned the sections above into a fill-in contingency plan for a dental practice: a criticality worksheet, backup plan, restore order, emergency mode checklist, testing log and vendor list. It is free, ungated and printable.
Open the HIPAA contingency plan template for dental practices.
No backup product is compliant by itself. HIPAA places the obligation on the practice: a contingency plan with a data backup plan, a disaster recovery plan and an emergency mode operation plan (45 CFR 164.308(a)(7)), and a written agreement with any vendor that maintains patient information for the practice.
No. For an addressable specification the practice must assess whether it is reasonable and appropriate, implement it if so, and otherwise document why not and implement an equivalent alternative measure if reasonable and appropriate (45 CFR 164.306(d)(3)).
Six years from the date it was created or the date it last was in effect, whichever is later (45 CFR 164.316(b)(2)(i)).
No. It appears only in a proposed rule published 6 January 2025 (90 FR 898). As of 2026-10-06 the Federal Register shows no final rule. Until a final rule is published and takes effect, the current Security Rule applies.
A vendor that maintains a practice’s electronic patient information on its behalf is the situation 45 CFR 164.308(b) addresses: the practice needs satisfactory assurances, documented in a written contract or other arrangement. Ask your compliance adviser how this applies to your own arrangements.