Business Continuity Planning

Business continuity planning under HICP Practice 8.7 requires you to integrate cybersecurity incident response with business continuity and disaster recovery so clinical and business operations can continue during a cyber event. Operationalize this by aligning triggers, roles, communications, backups, downtime workflows, and recovery priorities across IR, BCP, and DR, then proving it through tested exercises and retained evidence. ¹

Key takeaways:

• Integration is the requirement: IR, BCP, and DR cannot be separate documents with separate owners. ¹
• Your proof is operational: tested downtime procedures, recovery results, and decision logs beat polished binders. ¹
• Clinical continuity is the priority: define how care continues when EHR, imaging, pharmacy, identity, or networks are degraded. ¹

For a healthcare organization, “business continuity planning” in a cybersecurity context is not a generic disaster playbook. HICP Practice 8.7 sets a specific expectation: your cybersecurity incident response plan must connect cleanly to business continuity and disaster recovery planning so the organization stays operational during cyber disruption. ¹

CCOs, GRC leads, and security leaders usually inherit three partially overlapping programs: incident response (security-driven), business continuity (operations-driven), and disaster recovery (IT-driven). The compliance gap appears where these programs hand off to each other. During ransomware, identity outages, EHR downtime, third-party SaaS failures, or a security-driven shutdown of network segments, teams often discover that escalation paths, clinical downtime procedures, and recovery priorities were never aligned.

This page translates HICP Practice 8.7 into requirement-level execution steps you can assign, track, and test. The goal is simple: one coordinated operating model that clarifies who decides what, how patient care continues, what gets restored first, and what evidence you will retain to demonstrate resilience. ¹

Regulatory text

Requirement (HICP Practice 8.7): “Integrate cybersecurity incident response with business continuity and disaster recovery planning to ensure operational resilience.” ¹

Operator interpretation: You must connect (1) security incident response decision-making and containment actions with (2) business continuity workflows for sustained operations and (3) disaster recovery restoration of IT services and data. Integration means shared triggers, aligned severity levels, coordinated communications, defined clinical downtime operations, and a recovery sequence that matches patient-care priorities. ¹

Plain-English requirement interpretation

You are accountable for keeping healthcare delivery running during a cybersecurity incident. Your IR plan must not stop at “identify/contain/eradicate.” It must explicitly instruct the organization how it will:

• continue patient care with degraded systems,
• switch to downtime workflows,
• communicate internally and externally,
• recover critical technology services and data in a prioritized order,
• return safely to normal operations. ¹

If your BCP says “use downtime procedures” but your IR plan never triggers them, that is not integrated. If your DR runbooks restore systems in an order that conflicts with clinical priorities, that is not integrated. ¹

Who it applies to (entity and operational context)

HICP Practice 8.7 applies to:

• Healthcare organizations delivering care, billing, diagnostics, pharmacy operations, and support services that depend on technology. ¹
• Health IT vendors whose products or hosted services can disrupt care delivery when compromised or unavailable, especially EHR-adjacent systems, identity, e-prescribing, imaging, scheduling, and revenue cycle platforms. ¹

Operational contexts where auditors and regulators expect maturity:

• Ransomware or destructive malware that forces system isolation or shutdown
• Identity or access outages (SSO, MFA, directory services)
• EHR downtime (planned or unplanned) caused by cyber containment
• Third-party failures where a supplier incident becomes your availability incident
• Data integrity events where you cannot trust current records until validated ¹

What you actually need to do (step-by-step)

1) Define the integration points (documented crosswalk)

Create a one-page IR–BCP–DR integration map that answers:

• What incident severity levels trigger BCP activation?
• Who has authority to declare downtime and who can overrule?
• What containment actions require operational approvals (for example, shutting down network segments that affect clinical units)?
• Which DR restorations are required before returning to normal care workflows? ¹

Deliverable: a crosswalk table mapping IR phases to BCP/DR actions.

2) Align roles and governance (single command model)

Name accountable owners and a decision cadence:

• Incident Commander (security-led)
• Operations/Clinical Continuity Lead (clinical ops)
• IT DR Lead (infrastructure/applications)
• Compliance/Privacy liaison (if your operating model separates them)
• Third-party coordination lead (supplier comms and contract triggers)

Your plans should share the same on-call expectations and escalation contacts. One common failure is three separate call trees that drift out of date. ¹

3) Translate “continue operations” into specific downtime workflows

Write down what staff actually do when systems are degraded. Focus on clinical operations first:

• registration/admissions,
• orders, meds, and medication administration,
• lab/imaging orders and result reporting,
• care documentation,
• transfers and discharges,
• emergency department throughput.

Keep these as unit-ready playbooks, not policy prose. Where the process depends on paper forms or alternative systems, point to the exact location and owner. ¹

4) Make DR priorities match clinical priorities

Your DR runbooks should reflect the business/clinical impact of outages caused by cyber incidents. For each critical system:

• define restore dependencies (identity, network, databases),
• define integrity checks needed before go-live,
• define business sign-off required to resume operations,
• define a “safe mode” if full restoration is delayed.

Even if IT owns DR, operations must own the “return to service” decision for workflows that can harm patients if data is incomplete or wrong. ¹

5) Integrate third-party failure scenarios

BCP for cyber resilience requires explicit handling of third-party disruptions:

• SaaS outage or compromise,
• EDI clearinghouse disruption,
• cloud hosting incident,
• managed service provider incident.

Define: who contacts the third party, what information you request, what contractual notifications are triggered, and what continuity steps you take while waiting. If you use Daydream to manage third-party risk, link continuity requirements to each critical third party record so contract clauses, contacts, and contingency steps are retrievable during an incident. ¹

6) Test the integrated plan and retain proof

Run exercises that force cross-team decisions:

• security containment vs clinical disruption tradeoffs,
• downtime activation and communications,
• restoration sequencing,
• return-to-normal criteria.

Capture outcomes, decisions, gaps, and assigned remediations in an after-action record. Testing is where “integration” becomes auditable reality. ¹

Required evidence and artifacts to retain

Auditors typically want artifacts that show the plan is integrated, current, and tested:

• Integrated IR/BCP/DR crosswalk (single view of triggers, handoffs, and responsibilities)
• Incident severity definitions and activation criteria shared across plans
• Current call tree with role-based contacts and alternates
• Downtime workflows for clinical and business functions (approved by owners)
• DR runbooks with restore dependencies and validation steps
• Exercise materials: scenario, participant list, timeline of events, decisions, lessons learned, remediation tracker ¹

Common exam/audit questions and hangups

Expect questions like:

• “Show me where incident response triggers business continuity activation.” ¹
• “Who can declare EHR downtime for a cyber incident, and how is that communicated?” ¹
• “How do you prioritize restoration of systems to support patient care?” ¹
• “What evidence shows you tested the integrated plan and closed gaps?” ¹
• “What is your contingency plan if a critical third party is unavailable?” ¹

Hangups that slow reviews:

• Plans exist but reference each other vaguely (“see BCP”) without shared triggers or owners.
• DR is treated as a purely technical exercise without operational sign-off criteria.
• Downtime procedures exist but are not connected to security-driven shutdown scenarios. ¹

Frequent implementation mistakes and how to avoid them

Mistake: Integration is just cross-references

Avoidance: Require explicit “if/then” steps and a single severity-to-action matrix that both security and operations approve. ¹

Mistake: No decision record for containment actions that disrupt care

Avoidance: Add a decision log template to the IR kit, including approver, time, rationale, and expected operational impact. ¹

Mistake: DR restoration order reflects technical convenience

Avoidance: Make clinical and revenue cycle owners sign the restoration priority list and require validation checks before declaring “restored.” ¹

Mistake: Third-party outages are excluded from BCP

Avoidance: Maintain a list of critical third parties with downtime contacts, notification requirements, and manual workarounds. Daydream can store and surface these details under pressure if you standardize the record fields and bind them to your continuity playbooks. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat HICP Practice 8.7 primarily as a defensible healthcare cybersecurity practice and an audit expectation rather than a penalty-specific citation. Your risk is operational: a cyber incident can interrupt care delivery, trigger patient safety events, and create cascading regulatory exposure across privacy, security, and contractual obligations if continuity and communications fail. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and map)

• Inventory your current IR plan, BCP, DR runbooks, downtime procedures, and third-party outage playbooks. ¹
• Create the IR–BCP–DR integration crosswalk and confirm accountable owners for each decision point. ¹
• Identify the top operational “kill switches” security might pull (network isolation, privileged access shutdown, EHR access restriction) and document required approvals and communications. ¹

Next 60 days (write the missing operating procedures)

• Publish severity-to-action criteria: when BCP activates, when DR begins, when leadership is paged. ¹
• Update downtime workflows so they match cyber scenarios, not only generic outages. ¹
• Align DR restoration priorities to clinical operations, then capture validation and sign-off steps per system. ¹

By 90 days (test, fix, and institutionalize)

• Run an integrated tabletop exercise with security, IT, clinical ops, compliance, and key third-party stakeholders where applicable. ¹
• Produce an after-action report with remediations, owners, and tracking to closure. ¹
• Operationalize ongoing maintenance: a controlled change process for contact lists, dependencies, and third-party continuity details (Daydream can centralize ownership and approvals so updates do not get trapped in emails). ¹

Frequently Asked Questions

What does “integrate” mean in HICP Practice 8.7?

It means IR, BCP, and DR share triggers, roles, communications, and restoration priorities so teams execute one coordinated response. Cross-referencing documents is not enough if handoffs and decision rights are unclear. ¹

Who should own the integrated plan: Security, IT, or Operations?

Security typically owns incident command, IT owns recovery execution, and Operations owns continuity of care workflows and return-to-normal sign-off. You need a defined governance model that connects these roles and prevents conflicting decisions. ¹

How do we handle ransomware where containment disrupts clinical systems?

Pre-define which containment actions require clinical/operations approval and what downtime workflow activates immediately. Document the decision record and communicate consistently through one incident communications lead. ¹

Does this requirement include third-party outages (cloud, SaaS, MSP)?

Yes in practice, because third-party incidents can become your operational disruption. Your continuity plan should specify who engages the third party, what you ask for, and what workarounds you run while services are unavailable. ¹

What evidence will auditors accept as proof we operationalized this?

They look for an integration crosswalk, current downtime procedures, DR runbooks aligned to business priorities, and exercise artifacts with remediation tracking. Evidence should show real coordination across security, IT, and operations. ¹

We have downtime procedures, but staff do not follow them. What should we do?

Treat downtime execution as an operational readiness issue: clarify who declares downtime, make procedures unit-specific, and test them in exercises that include frontline roles. Track gaps as remediations until closed. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices