Category: Administrative Safeguards

Contingency Plan

Also known as: Alternate Plan, Backup Plan, Plan B

Simply put

A contingency plan is a backup strategy that describes how an organization will keep operating and recover its information systems if something unexpected disrupts them, such as a major hardware or software failure, an emergency, or another event. In healthcare compliance, it helps ensure that access to important information can be maintained or restored when normal operations are interrupted. Generally, it is a written plan prepared in advance rather than an improvised response.

Formal definition

In the context of information systems, a contingency plan is a written plan for recovering one or more information systems at an alternate facility in response to a major hardware or software failure or other disruption. Under the HIPAA Security Rule, contingency planning is generally addressed as an administrative safeguard requiring covered entities and business associates to establish policies and procedures for responding to emergencies or other occurrences that damage systems containing electronic protected health information (ePHI). Practitioners should note that specific implementation specifications (such as data backup, disaster recovery, and emergency mode operation) and their designation as required or addressable are defined in the applicable regulatory text and should be verified against the current Security Rule. Addressable specifications are not optional; they require the entity to assess whether the specification is reasonable and appropriate and to implement it or a documented equivalent. The scope of this entry is limited to the general definition and its role in the Security Rule; readers should confirm exact requirements against current HHS OCR guidance, and note that the HITECH Act, state law, or frameworks such as the HITRUST CSF may impose additional expectations.

Why it matters

For healthcare organizations, information systems are often the backbone of patient care, billing, and communication. When those systems are disrupted by a major hardware or software failure, an emergency, or another unexpected event, the consequences can extend beyond inconvenience to affecting access to critical health information. A contingency plan matters because it establishes, in advance, how an organization will keep operating and recover its systems rather than improvising a response in the middle of a crisis. This preparation is especially significant for systems containing electronic protected health information (ePHI), where continued availability and integrity of data are central compliance concerns.

Under the HIPAA Security Rule, contingency planning is generally addressed as an administrative safeguard, meaning covered entities and business associates are expected to have policies and procedures for responding to occurrences that damage systems containing ePHI. Because contingency planning is a written, prepared strategy rather than a reactive scramble, it helps organizations demonstrate that they have thought through recovery scenarios and taken reasonable steps to maintain or restore access to important information.

Practitioners should keep in mind that the specific implementation specifications associated with contingency planning, and whether they are designated as required or addressable, are defined in the applicable regulatory text and should be verified against the current Security Rule. Addressable does not mean optional; it means the entity must assess whether a given specification is reasonable and appropriate and either implement it or document an equivalent measure. Readers should also note that the HITECH Act, state law, or frameworks such as the HITRUST CSF may impose additional expectations beyond the baseline Security Rule requirements.

Who it's relevant to

Security Officers

Security officers are typically responsible for developing, maintaining, and testing contingency plans for systems containing ePHI. They must ensure the plan addresses recovery from major hardware or software failures and other disruptions, and confirm that implementation specifications are handled consistently with the current Security Rule.

Covered Entities and Business Associates

Both covered entities and business associates are generally expected under the Security Rule to establish policies and procedures for responding to emergencies or other occurrences that damage systems holding ePHI. Business associates should confirm how these obligations flow through their business associate agreements.

IT and Disaster Recovery Teams

IT staff and disaster recovery teams put contingency plans into practice through activities such as data backup and system restoration at alternate facilities. They translate written plans into operational capabilities and should verify that recovery procedures align with the organization's documented plan.

Compliance Officers and Auditors

Compliance officers and auditors evaluate whether an organization's contingency plan exists, is documented, and reflects the required and addressable specifications defined in the applicable regulatory text. They should confirm requirements against current HHS OCR guidance and note where the HITECH Act, state law, or the HITRUST CSF may add expectations.

Inside Contingency Plan

Data Backup Plan

A required implementation specification under the Security Rule's contingency plan standard that calls for establishing and implementing procedures to create and maintain retrievable exact copies of ePHI.

Disaster Recovery Plan

A required implementation specification directing covered entities and business associates to establish and, as needed, implement procedures to restore any loss of ePHI and the systems that support it following a disruptive event.

Emergency Mode Operation Plan

A required implementation specification requiring procedures to enable continuation of critical business processes for protecting the security of ePHI while operating in emergency mode.

Testing and Revision Procedures

An addressable implementation specification calling for periodic testing and revision of contingency plans. Addressable does not mean optional; the entity must implement it if reasonable and appropriate, or document why not and adopt an equivalent alternative where appropriate.

Applications and Data Criticality Analysis

An addressable implementation specification calling for assessment of the relative criticality of specific applications and data in support of other contingency plan components, helping prioritize recovery efforts.

Common questions

Answers to the questions practitioners most commonly ask about Contingency Plan.

Is a contingency plan the same thing as a data backup?

No. A data backup is only one component of a contingency plan. Under the HIPAA Security Rule, the contingency plan standard is broader and generally encompasses several implementation specifications, including a data backup plan, a disaster recovery plan, and an emergency mode operation plan, along with (as addressable specifications) testing and revision procedures and applications and data criticality analysis. Treating backups alone as a complete contingency plan typically leaves significant gaps in how an organization would continue operations and protect ePHI during and after a disruption. Readers should verify the specific implementation specifications against the current regulatory text.

Since testing and revision procedures are labeled addressable, can we skip them?

No. Addressable does not mean optional. For addressable implementation specifications, a covered entity or business associate must generally assess whether the specification is a reasonable and appropriate safeguard in its environment and, if so, implement it. If it is not reasonable and appropriate, the organization is typically expected to document why and to implement an equivalent alternative measure where reasonable and appropriate. Simply ignoring testing and revision procedures without that analysis and documentation would generally not satisfy the Security Rule.

Which parts of a contingency plan are required versus addressable?

Under the Security Rule contingency plan standard, the data backup plan, disaster recovery plan, and emergency mode operation plan are generally treated as required implementation specifications, while testing and revision procedures and applications and data criticality analysis are generally treated as addressable. Because addressable still requires assessment and documentation, organizations should not equate it with optional. Confirm the current classification of each specification against the applicable regulatory text before relying on it for a compliance decision.

How do we perform an applications and data criticality analysis?

An applications and data criticality analysis generally involves identifying the software applications and data, particularly ePHI, that are most critical to operations, then prioritizing them for backup, recovery, and continued availability during an emergency. This analysis typically informs the other contingency plan components by clarifying what must be restored first and what level of availability is needed. Because it is an addressable specification, an organization should assess whether it is reasonable and appropriate for its environment and document the outcome.

How does the contingency plan relate to business associates and their subcontractors?

Business associates are directly obligated to comply with the applicable Security Rule requirements, including the contingency plan standard, for the ePHI they create, receive, maintain, or transmit. Obligations flow to subcontractors through the required business associate agreements. In practice, a covered entity should consider how a business associate's contingency planning affects the availability of ePHI, and a business associate should consider its subcontractors' capabilities. These expectations are typically addressed contractually rather than by HIPAA regulating every vendor directly.

Does maintaining a contingency plan guarantee we can recover from any disruption or breach?

No. A contingency plan is intended to reduce the impact of disruptions and support the availability of ePHI, but no plan can guarantee recovery from every event or prevent all breaches. Its effectiveness generally depends on factors such as the quality of backups, the frequency and realism of testing, the accuracy of the criticality analysis, and timely revision as systems change. Note that state law, the HITECH Act, or other frameworks may impose additional requirements, and a HITRUST CSF certification, while it may map to related controls, does not by itself establish HIPAA compliance.

Common misconceptions

The contingency plan is only about recovering IT systems after a natural disaster.

Under the HIPAA Security Rule, the contingency plan standard focuses specifically on responding to emergencies or other occurrences (such as fire, vandalism, system failure, or other events) that damage systems containing ePHI. Its purpose is protecting the availability and security of ePHI, which is broader than disaster recovery alone and includes data backup, emergency mode operation, and, on an addressable basis, testing and criticality analysis.

The addressable implementation specifications (testing and revision, criticality analysis) are optional and can be skipped.

Addressable does not mean optional. A covered entity or business associate must assess whether each addressable specification is reasonable and appropriate in its environment, and either implement it, implement an equivalent alternative measure where reasonable and appropriate, or document the rationale for not implementing it.

The contingency plan requirement applies to all forms of PHI.

The contingency plan is a Security Rule administrative safeguard and therefore applies only to electronic protected health information (ePHI). Protections for PHI in oral or paper form fall under the Privacy Rule rather than this standard.

Best practices

Address all three required implementation specifications (data backup plan, disaster recovery plan, and emergency mode operation plan) and document how each is satisfied for systems containing ePHI.

Do not skip the addressable specifications; formally evaluate testing/revision and applications and data criticality analysis, and document the decision to implement, adopt an equivalent alternative, or not implement with a supporting rationale.

Use a risk analysis and criticality assessment to prioritize which applications and data must be restored first, aligning recovery objectives with the ePHI that is most critical to operations.

Periodically test the plan and revise it based on results, organizational changes, and lessons learned, retaining documentation of testing activities.

Verify that backups produce retrievable, exact copies of ePHI and confirm restoration capability rather than assuming backups are usable.

Confirm that business associates handling ePHI maintain their own contingency plans through the business associate agreement, and verify specific requirements, penalties, and any state law or HITECH obligations against the current regulatory text since figures and provisions change over time.