HIPAA Contingency Plan Checklist: What a Compliance Officer Needs on File Before an OCR Investigation

When the Office for Civil Rights (OCR) opens an investigation after a breach report, its data request is predictable. It asks for the risk analysis, the risk management plan, the policies and procedures, the training records, the business associate agreements, and the contingency plan with evidence that it was tested. The entities that settle for six and seven figures are rarely the ones with no plan; they are the ones whose plan has no date on it, no test behind it, and no connection to the systems that actually failed. This checklist is written for the compliance officer who has to assemble that evidence file. It covers the five elements the current Security Rule requires at 45 CFR 164.308(a)(7), the measurable clauses the proposed update would add, and the artefact that proves each one.

The five elements the rule requires today

The contingency plan standard has five implementation specifications. Three are required under the current rule and two are addressable; the proposed rule would make all five required. Treat them all as required now.

The clocks the proposed rule adds

Four numbers from the proposal belong in the plan now, because each one is a question an investigator can ask whether or not it is yet in the regulation.

• 48 hours: retrievable exact copies of ePHI no more than 48 hours older than the live data. Check: the newest backup of every ePHI store, listed with its timestamp.
• 72 hours: written procedures to restore critical electronic information systems and data within 72 hours of a loss. Check: the sum of the runbook target durations for every system the criticality analysis marks critical.
• 12 months: contingency plans reviewed and tested at least annually. Check: the date of the last rehearsal and of the last revision.
• 24 hours: a business associate must notify the covered entity within 24 hours of activating its contingency plan. Check: the clause in each BAA, and the named recipients.

Our post on disaster recovery architecture for the 72-hour objective covers how the infrastructure meets the first two; this checklist is about the paper.

Section 1: inventory and criticality

• A technology asset inventory listing every system that creates, receives, maintains or transmits ePHI, including SaaS tenants, backup targets, interfaces and the endpoints that sync them. The proposed rule would require it; the current risk analysis guidance already expects it.
• A network map showing how ePHI moves between those systems.
• A criticality ranking with, for each system: impact of unavailability at 1 hour, 1 day and 3 days; dependencies; agreed RPO; agreed RTO; and which tier it restores in.
• Sign-off on the ranking by clinical and operational leadership, not only IT. An investigator checks that the business agreed what "critical" means.
• A review date within the last 12 months, and a record of the review after the last material change (a new EHR module, a migration, an acquisition).

Section 2: backup

• A written backup policy that states, per system, the method (snapshot, dump, agent), the frequency, the retention, the storage location and whether the copy is off-site and immutable.
• For every ePHI store, evidence that the newest copy is within the policy's frequency, and within 48 hours. A monthly export of job history, filed, is enough.
• Evidence that backups are encrypted and that the keys are held separately from the production credentials.
• Evidence of integrity checks: restore-verification results, checksum reports, or an equivalent.
• For data held by business associates (the hosted EHR, the collaboration suite, the billing service), a statement from each one of its backup frequency and restoration objective for your data, and a note of what you verified. "The vendor's trust page" is a legitimate entry; it should be recorded as such.

Section 3: disaster recovery

• A runbook per critical system, in restoration order, with: the copy it restores from; prerequisite systems; ordered steps; the acceptance test that marks the system restored; a target duration per step; and the named role responsible.
• A summary page that adds the target durations by tier and states the planned RTO against the 72-hour ceiling.
• A contact and escalation list, including the hosting and backup providers' 24/7 channels, reviewed within the last 12 months.
• Documentation of where the restoration happens: production, a standby environment in a second datacenter, or a rebuilt platform, and who provides it.
• Evidence that at least one restoration has been performed from the off-site copy, with timings. If the only restores on record are single files from the recycle bin, the investigator will notice.

Section 4: emergency mode operation

This is the element most often missing, because it is a clinical and operational document rather than an IT one.

• Downtime procedures per critical system: how registration, orders, results, medication administration and documentation continue on paper or on a downtime viewer when the EHR is unavailable.
• How ePHI created during the outage is protected (locked storage for paper, encrypted devices for any electronic capture) and how it is reconciled into the system afterwards, with a named owner.
• Communication templates for staff and, where appropriate, patients. Keep the downtime procedures where staff can find them during an outage, which usually means a printed copy per unit and a controlled documentation platform; our post on XWiki for healthcare knowledge management shows how clinical protocols are versioned and audited there.
• Access procedures for emergency mode: who can grant break-glass access, how it is logged, and how it is revoked, because the Security Rule's emergency access procedure requirement sits alongside this plan.
• A training record showing that the people who would execute downtime procedures have been through them. A procedure nobody has practised is a document, not a plan.

Section 5: testing and revision

• A test schedule: at least annually for the full plan, and after material changes.
• For the most recent test: scope, scenario, the copy restored from, the environment restored into, step timings, planned versus measured RTO per system, deviations from the runbook, acceptance test results, newest record date against the RPO, participants, and sign-off by the compliance officer.
• A revision log for each plan document showing what changed after each test and why.
• For tests performed by a managed provider on your behalf, the provider's report, and a record that someone from your organisation observed or reviewed it.

Section 6: business associates

• A current list of every business associate that holds or can access ePHI, mapped to the systems in the inventory.
• A signed BAA for each, with the contingency-related clauses identified: breach notification, and, ahead of the final rule, a 24-hour notice of contingency plan activation. Our guide to business associate agreements for hosted collaboration explains what to look for.
• The written verification of each associate's technical safeguards that the proposed rule would require annually, or the attestation you are relying on in the meantime, with a note on its scope.
• For the associates in tiers 0 to 2 of the criticality analysis, their stated restoration objective for your data and the date you last confirmed it.

How to use the checklist

Work through the six sections and mark each line green, amber or red: green has a dated artefact on file, amber has an artefact older than 12 months or without sign-off, red has nothing. Fix the reds in sections 1 and 2 first, because the criticality analysis and the backup evidence are what every other section depends on, and because they are the two items OCR's enforcement history shows it asks about most. Then schedule the rehearsal that turns section 5 green, since a single well-documented restoration test moves more lines than any other action.

For a health system that hosts its critical systems with MassiveGRID, most of sections 2, 3 and 5 arrive as part of the managed service: the backup job history, the runbooks, the off-site copy, the annual rehearsal report and the written attestation, all under a Business Associate Agreement. What stays with the covered entity is what should: the criticality decisions, the emergency mode procedures, and the sign-off.

Frequently Asked Questions

What are the five elements of a HIPAA contingency plan?

Under 45 CFR 164.308(a)(7): a data backup plan, a disaster recovery plan and an emergency mode operation plan, which are required, and testing and revision procedures and an applications and data criticality analysis, which are addressable today. The proposed Security Rule update would make all five required and add testing at least every 12 months.

Does HIPAA require a specific backup frequency or recovery time?

The current rule does not. The proposed update sets two measurable limits: retrievable exact copies of ePHI no more than 48 hours old, and written procedures to restore critical systems and data within 72 hours of a loss. Entities should set their own tighter RPO and RTO per system in the criticality analysis.

What does OCR ask for after a breach report?

Typically the most recent risk analysis and risk management plan, Security Rule policies and procedures, workforce training records, business associate agreements, the contingency plan with evidence of testing, and incident documentation for the event itself. Investigations frequently turn on whether these documents existed and were current before the incident.

Can a hosting provider's disaster recovery testing count as our test?

It can form part of the evidence if the provider is a business associate under a signed BAA, the test covers your systems and data, you receive the report, and someone from your organisation reviewed or observed it. The covered entity remains responsible for the plan as a whole, including the emergency mode procedures the provider cannot perform for you.

How long must contingency plan documents be retained?

Six years from the date of creation or the date the document was last in effect, under the Security Rule's documentation requirements. That includes superseded versions of the plans and past test reports.