The HIPAA Contingency Plan with a SOC 2 Spin

Managing compliance for a healthcare tech company brings many challenges, among them HIPAA and SOC 2 requirements, which can feel like solving two puzzles at once. One area where these two frameworks overlap heavily is Contingency Planning, or, to better put it, how would you handle the worst-case scenarios?

The HIPAA Security Rule (specifically the Administrative Safeguards at §164.308(a)(7)) legally requires you to have a Contingency Plan:

Standard: Contingency plan.  Establish (and implement as needed) policies and procedures for responding to emergencies or other occurrences (e.g., fire, vandalism, system failure, or natural disaster) that damage systems containing electronic protected health information.

If this is your first time going through a HIPAA audit, or if you are doing both a SOC 2 and a HIPAA audit, you might be wondering what goes into a Contingency Plan. The good news is that you need one solid plan that meets the requirements for both frameworks.

The updated HIPAA Security Rule overhauls the healthcare cybersecurity landscape by moving from flexible, optional safeguards to mandatory, enforceable technical controls. The rule eliminates the “addressable” loophole, making the following contingency planning control mandatory:

“Organizations must possess the provable ability to restore critical systems within 72 hours of an incident.”

Here is a breakdown of what a HIPAA Contingency Plan requires, how it maps to SOC 2, and what auditors look for during the review.

5 Core Pieces of a Modern HIPAA Contingency Plan

HIPAA breaks the contingency plan down into five specific implementation specifications. Three of the five were “required,” and the other two are “addressable,” which basically means you still had to do them unless you had a highly justifiable alternative (most likely you did not). With the 2026 changes, those “addressable” factors are becoming strict requirements. If you are working off an old plan, it may no longer be compliant. Here is how the five elements stack up across both frameworks.

1. Data Backup Plan (Required)

HIPAA asks for procedures to create retrievable and exact copies of electronic protected health information (ePHI).

The SOC 2 Spin: Just having a copy of your data isn’t enough anymore. The constant threat of ransomware requires an off-site and immutable backup strategy. Auditors expect you to have your backups completely secure from tampering, and that they happen frequently enough to meet your Recovery Point Objectives (RPO) – the maximum amount of data an organization can afford to lose following an unexpected disruption or disaster, measured in time.

2. Disaster Recovery Plan (Required)

HIPAA requires a plan to restore lost data outlining specific timeframes, resource requirements, and key points of contact.

The SOC 2 spin: This lines up perfectly with the SOC 2 Availability criteria. Auditors want to see your Recovery Time Objective (RTO) clearly defined. What if your primary cloud region goes down? How fast are you able to spin up another? Who has the authority to hit the button? And who are the third-party vendors you rely on to make it happen?

3. Emergency Mode Operation Plan (Required)

This is uniquely a HIPAA requirement, but it’s incredibly important. This requires you to maintain ePHI security while operating in emergency mode.

The SOC 2 spin: Security controls get put on the back burner when disaster strikes, and your only focus is usually to get systems back up and running. SOC 2’s incident response and Security criteria echo the following need: you must have procedures in place to keep unauthorized users out and data encrypted, even when everything is broken, and you’re working out of a degraded, secondary environment.

4. Testing & Revision Procedure (Addressable, But Now Required for 2026)

You must periodically test and update your plan.

The SOC 2 spin: “Periodic” at a minimum means annually. The good thing is that you only need to test this once to cover both HIPAA and SOC 2 requirements. Auditors expect to see more than just a dusty binder with test plans. This usually entails a mix of tabletop exercises where your team discusses a simulated disaster, along with technical evidence that proves you restored a database.

5. Application & Data Criticality (Addressable, But Now Required for 2026)

You need to figure out which applications and data are most critical to know, and what you need to recover first.

The SOC 2 spin: This ties directly into the SOC 2 Risk Assessment requirements.  You can’t protect everything equally. The key here is to document a tiering system that outlines recovery timelines for the most critical to least critical databases in your environment.

What Auditors Actually Look for in a Contingency Plan during HIPAA & SOC 2 Audits

If you are preparing for a HIPAA or SOC audit or both, here is what you need to know when it comes to evidence collection. The key here is that auditors do not want to see a plan that is just a theory. The gold standard for building this out is the framework defined in NIST SP 800-34 (Contingency Planning Guide for Information Technology Systems), streamlined here for a modern cloud-native footprint.

1. Conduct a Criticality Analysis

Prerequisite: You cannot protect everything equally. Before writing any policies, you must know what is actually at stake. Perform an Applications and Data Criticality Analysis (often called a Business Impact Analysis) to map out your infrastructure.

• Inventory every database, application, and vendor that creates, stores, or transmits electronic protected health information (ePHI).
• Assign a priority tier to each system. Tier 1 systems are essential for immediate patient care or core operations; Tier 3 systems (like internal wikis) can wait.
• Define strict Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for each tier.

2. Deploy Preventive Controls and Backups

Must happen before defining failover mechanics. Once you know your RPOs, implement the technical infrastructure required to meet them.

• Establish an off-site, immutable backup strategy to guarantee that even a successful ransomware deployment cannot encrypt your backups.
• Configure backup schedules to ensure data loss never exceeds the RPOs defined in Step 1.
• Secure these environments with stringent logical access controls, primarily MFA and least-privilege enforcement.

3. Define the Recovery Strategies

Focus on the 72-hour restoration mandate. Determine exactly how you will restore the Tier 1 and Tier 2 systems using the backups secured in the previous step.

• Map out the technical failover architecture. If your primary cloud region goes down, document the precise mechanics of spinning up the secondary region.
• Identify all external dependencies and ensure you have Business Associate Agreements (BAAs) and Service Level Agreements (SLAs) in place with vendors required to execute the recovery.

4. Draft the Master Contingency Plan

The primary artifact for the audit. Compile everything into a single, formally approved document. To meet both frameworks, this master file must explicitly contain:

• The Disaster Recovery Plan (DRP): The step-by-step technical procedures to restore operations.
• The Emergency Mode Operation Plan: Specific procedures detailing how encryption, access controls, and ePHI security will be maintained while operating out of a degraded or secondary environment.
• Roles and Responsibilities: Name specific titles and contact information. “The IT Team” is not an acceptable owner.

5. Test the Plan & Capture Evidence

Failure to capture timestamped logs nullifies the test. With the elimination of “addressable” loopholes, theoretical capabilities are no longer accepted. You must possess the provable ability to restore critical systems within the mandatory 72-hour window.

• Run an annual tabletop exercise with leadership and engineering to talk through a simulated disaster.
• Execute a live technical test: have an engineer pull an ePHI backup from cold storage and successfully restore it to an isolated test environment.
• Save the timestamped system logs and IT tickets; this is the exact technical evidence auditors will demand.

One of the most common auditor findings is treating disaster recovery as a “check-the-box” documentation exercise. Many companies rely solely on the fact that they run automated backups. In reality, you should know that backing up data is not the same as recovering a system. You can’t recover user access, network configurations, or interconnected applications from a raw database file. Auditors look for timestamped system logs proving that an engineer actually pulled an ePHI backup from cold storage and successfully restored it to a functional, isolated test environment. If you haven’t tested the actual restoration process, your plan is incomplete.

6. Establish a Maintenance Cycle

Required at least annually. Operationalize the document so it evolves alongside your tech stack.

• Require an annual review and sign-off from executive leadership.
• Maintain a meticulous version history log.
• Revisit the criticality analysis (Step 1) whenever there is a major architectural shift or a new product launch.

Focusing on the above won’t just get you a clean audit report – it will make your company resilient when things inevitably go sideways (fingers crossed they never do!).

Frequently Asked Questions About HIPAA Contingency Planning

HIPAA contingency planning raises many questions, especially as the 2026 rule changes take effect. Here are answers to some of the most common ones we hear.

What Is the Biggest Change to HIPAA Contingency Planning in 2026?

Historically, organizations could opt out of certain technical safeguards (like strict testing or specific backup strategies) if they documented a reason why it wasn’t “reasonable or appropriate” for their specific environment. Moving forward, these controls are mandatory. You are now strictly required to have off-site, encrypted backups and the provable, tested ability to restore critical systems within 72 hours of an incident.

Does This Rule Apply to Health Tech Vendors or Just Hospitals?

It applies to both. Under HIPAA, hospitals and clinics are “Covered Entities,” but the software vendors, cloud hosts, and IT service providers they rely on are “Business Associates.” If your tech company handles, stores, or transmits ePHI on behalf of a healthcare provider, you are legally required to maintain and test a HIPAA-compliant contingency plan. Check out our blog on the difference between a HIPAA business associate and a covered entity to learn more.

Building a Contingency Plan That Holds Up When It Matters

At the end of the day, building a robust contingency plan shouldn’t just be about checking off boxes for your next audit. The healthcare cybersecurity landscape has shifted toward stricter enforcement, like mandatory 72-hour system restoration capabilities and the complete elimination of “addressable” loopholes – having a functional, testable playbook is non-negotiable.

By aligning HIPAA requirements with SOC 2’s availability and security criteria, you do more than save your team from managing two separate compliance pipelines. You build a culture of genuine resilience. When a system failure or a security incident eventually hits, you won’t be scrambling to figure out what to do; you’ll simply be executing a plan you already know works.

If you are interested in engaging Linford & Company for our auditing services, if you need a HIPAA or a SOC audit report, or if you have any questions, please feel free to contact us. Our team consists of IT audit professionals who are highly skilled at HIPAA audits and  SOC 2 audits. We will be happy to answer any questions you may have and to assist with your compliance needs.

This article was originally published on 2/3/2016 and was updated on 6/10/2026.