How do we put a HIPAA contingency plan in place?

Start

We hold electronic health information and need a contingency plan

The HIPAA Security Rule asks for policies and procedures for responding to an emergency or other occurrence that damages systems holding electronic protected health information (ePHI). Fire, vandalism, system failure and natural disaster are the Rule's examples. The standard has five implementation specifications, three required and two addressable.

• Then: Are we a covered entity or a business associate?

Decision

Are we a covered entity or a business associate?

HIPAA binds covered entities and business associates that create, receive, maintain or transmit ePHI. Whether it applies to you, and in which role, is for counsel to confirm. If you do not know, take the cautious branch and ask counsel while you carry on, because the work is also good continuity practice.

• Yes, or not known: Ask counsel to confirm your role while you carry on
• No: HIPAA does not bind you: use the pack as a reference only

Outcome

HIPAA does not bind you: use the pack as a reference only

The pack says others may read the procedure as a reference. Without a duty under HIPAA, your sector or contracts decide which continuity and recovery duties apply to you. Confirm that with counsel, your auditor or your supervisor.

Step

Ask counsel to confirm your role while you carry on

The pack leaves the question of whether HIPAA applies, and in which role, to counsel. Where the answer is not yet known, the plan is still worth building. Record counsel's answer in your own register. A hybrid entity applies the rows to its health care components only.

• Then: Name who owns the plan, and the security official

Step

Name who owns the plan, and the security official

The Rule asks for one named security official. The pack suggests the IT lead as owner of the contingency plan standard, and says to use your own titles. If a service provider runs your IT, the duty stays with you: name the provider in your plan and your own owner by name.

• Then: List the systems that hold ePHI and the failures to plan for

Step

List the systems that hold ePHI and the failures to plan for

Start from the systems that hold ePHI, including those a supplier runs. The pack's failures for a disaster recovery procedure are a server, storage or database failing, a data centre or cloud region going down, a network line failing, a faulty update stopping devices, and a lost site. An attack is a separate case: incident response runs it. If ePHI is encrypted in an attack, HHS says a breach is presumed unless a low probability of compromise is shown. “When does a security incident become a reportable HIPAA breach?” covers that.

• Then: Agree what each system must achieve: time and data loss

Step

Agree what each system must achieve: time and data loss

Each critical service has a business owner who agrees how long it can be down and how much data it can lose, from a business impact analysis. IT proposes what is achievable. The pack's rule is a recovery time shorter than the maximum tolerable downtime, and a backup interval for each data set no longer than its recovery point. Your own standard may set different figures.

• Then: Are the backup, disaster recovery and emergency mode plans in use?

Decision

Are the backup, disaster recovery and emergency mode plans in use?

These three specifications are required. Required means implemented: size and cost may shape how, never whether. The backup plan keeps retrievable exact copies of ePHI. The disaster recovery plan has procedures to restore any loss of data. The emergency mode plan lets critical business processes continue while protecting ePHI. If you are not sure all three are written and working, answer no.

• Yes: Assess the two addressable specifications against your environment
• No, or not known: Write each plan, with a runbook for every system

Step

Write each plan, with a runbook for every system

For disaster recovery, the pack records one method for each system: repair in place, fail over, restore elsewhere from backup, rebuild, or the supplier's own recovery. Each has a runbook with the steps, the time they take and who may run them, and a method never tested is recorded as untested. For emergency mode the pack is silent: the workaround for each critical service is a starting point, and counsel confirms the fit.

• Then: Assess the two addressable specifications against your environment

Step

Assess the two addressable specifications against your environment

Testing and revision procedures, and the applications and data criticality analysis, are addressable. Addressable is assessed and never optional. Weigh size, complexity and capabilities, technical infrastructure, cost, and the probability and criticality of the risks to ePHI. Who decides follows your own risk acceptance rules for the residual risk.

• Then: Is each one reasonable and appropriate in our environment?

Decision

Is each one reasonable and appropriate in our environment?

If the safeguard is reasonable and appropriate, you implement it. If it is not, you document why and put an equivalent alternative measure in place where one is reasonable and appropriate. If you do not know, treat it as reasonable and appropriate: the pack says an addressable specification is never skipped without a record.

• Yes, or not known: Implement it as written
• No: Document why not, and use an equivalent measure where one exists

Step

Implement it as written

A specification found reasonable and appropriate is put in place as written: a criticality analysis of each application and data set the plan depends on, and a routine to test and revise the plans. The next steps set out how to test and review.

• Then: Record each addressable decision, even where you implement

Step

Document why not, and use an equivalent measure where one exists

Write down the reasons, and what you do instead and why it reduces the same risk. The record is the evidence that you assessed the specification. Ask counsel to read the reasons if you want a second view. Review the decision with the next risk analysis and on any trigger, such as a new system or supplier that handles ePHI.

• Then: Record each addressable decision, even where you implement

Step

Record each addressable decision, even where you implement

The pack asks for one record for each addressable specification: the risks it addresses, the four factors, whether it is reasonable and appropriate, the decision, any alternative, who decided and when, and when it is reviewed. Keep it in your own register. The pack gives the Rule's documentation period as six years.

• Then: Test recovery with an approved plan, a stop point and a way back

Step

Test recovery with an approved plan, a stop point and a way back

The Rule asks for periodic testing and revision of contingency plans and does not say how. The recovery test is this pack's own rule, because it proves a recovery time. The pack's default is to test each critical service at least every 12 months, restoring data and recording the time and data lost against the objectives. A written plan approved by the business owner comes first, with a stop point and a way back. A tabletop alone proves no recovery time.

• Then: Did the test meet its time and data-loss objectives?

Decision

Did the test meet its time and data-loss objectives?

Take both measures from logs, not memory: the time from the decision to recover to the owner's confirmation, and the data between the newest restored data and the failure. A miss against an objective is an objective gap with an owner. If a measure was not taken, answer no.

• Yes: Write the lessons into the plans and review them
• No, or not known: Raise each miss as a gap and agree the fix

Step

Raise each miss as a gap and agree the fix

The pack's default is that the gap's owner agrees the change that closes it within 10 working days, with a due date, and the service's risk owner is told. Record every finding in the report, including what went as planned and what the test did not show.

• Then: Write the lessons into the plans and review them

Step

Write the lessons into the plans and review them

The pack reviews each recovery plan at least every 12 months, after every test and real recovery, and after a significant incident or change. Lessons from tests go into the plan, and a copy of every plan can be reached when the main systems are down. Keep test records for the pack's default of 3 years, or longer where law or a contract asks.

• Then: The plan, its decisions and its test records are in your own files

Outcome

The plan, its decisions and its test records are in your own files

You hold the three required plans, a decision record for each addressable specification, test reports against objectives and a review date. Whether it is enough under the Rule is for counsel and the regulator to say. The Rules provide no certificate, and this flow does not say that you comply.