The Wake-Up Call: What Change Healthcare Taught Every Small Practice
The downstream impact was devastating. An AHA survey of nearly 1,000 hospitals found that 74% reported direct patient care impact, 94% were affected financially, and 60% required two weeks to three months to resume normal operations. An AMA survey found that 80% of physician practices lost revenue from unpaid claims, with smaller practices taking the most severe economic hit. Some were forced to use personal funds to keep their doors open.
The lesson for small telehealth practices is uncomfortable but essential: your practice doesn't need to be the direct target. When a critical vendor goes down — your clearinghouse, your EHR host, your telehealth platform — your ability to see patients, bill insurance, and communicate with staff depends entirely on whether you have a recovery plan that works independently of that vendor.
As we covered in Vendor Risk Beyond the BAA, a signed Business Associate Agreement does not guarantee that your vendor can recover quickly — or that their recovery timeline aligns with your clinical obligations. The Change Healthcare incident proved that vendor recovery can take months, and that practices without independent continuity plans face existential financial risk.
Recovery ≠ Backup: The Distinction That Saves Practices
Most practice managers, when asked about their disaster recovery plan, will say: "We have backups." That answer confuses the medicine with the cure. A backup is a copy of your data. Recovery is the proven, tested ability to take that copy and use it to restore your practice to a functional state — systems running, patients being seen, claims being submitted, and staff knowing exactly what to do.
❌ What Most Practices Have
- Automated backup runs nightly (probably)
- Backup stored on-premise or with one cloud vendor
- Nobody has tested a full restore in 12+ months
- No documented steps for "what to do when systems are down"
- Assumption that the EHR vendor will "handle it"
✓ What NIST CSF 2.0 Requires
- Verified backups with tested restoration (RC.RP-03)
- Prioritized recovery actions by criticality (RC.RP-02)
- Integrity verification of restored systems (RC.RP-05)
- Defined criteria for declaring "recovery complete" (RC.RP-06)
- Stakeholder communication throughout (RC.CO-03)
A backup is a noun. Recovery is a verb. If you've never practiced the verb, the noun is decoration.
RC.RP — Incident Recovery Plan Execution
NIST CSF 2.0 organizes recovery into six subcategories under RC.RP. Each one addresses a specific failure mode that has caused real harm to real healthcare organizations. Here's what each subcategory means in plain language for a telehealth practice:
| Subcategory | What It Means | Telehealth Translation |
|---|---|---|
| RC.RP-01 | Execute the recovery portion of the incident response plan | When the tabletop exercise becomes real: activate the runbook, assign roles, begin restoration in priority order |
| RC.RP-02 | Select, scope, prioritize, and perform recovery actions | Restore the EHR and patient scheduling first, then billing, then telehealth video, then analytics — not everything at once |
| RC.RP-03 | Verify integrity of backups before restoration | Confirm your backup isn't also compromised before restoring from it — ransomware actors frequently target backup systems |
| RC.RP-04 | Consider critical mission functions when establishing post-incident norms | Patient care comes first. Your recovery sequence should mirror clinical priority, not IT convenience |
| RC.RP-05 | Verify restored asset integrity and confirm operational status | After restoration, validate that data is complete, access controls are intact, and no malicious artifacts remain |
| RC.RP-06 | Define and apply criteria for end of recovery | "When can we declare this over?" — define measurable criteria: all systems operational, data verified, patients notified, documentation complete |
Recovery isn't about restoring everything simultaneously. It's about restoring the right things first. For a telehealth practice, the priority sequence is typically: (1) patient safety and communication, (2) EHR access and clinical documentation, (3) scheduling and appointment management, (4) telehealth video platform, (5) billing and claims submission, (6) analytics and reporting. Document this sequence before an incident — in a crisis, you won't have time to debate it.
RC.CO — Incident Recovery Communication
If RC.RP is the technical engine of recovery, RC.CO is the human one. Communication during a recovery isn't optional — it's a clinical obligation, a regulatory requirement, and the single largest factor in whether patients maintain trust in your practice afterward.
Who Needs to Know What, and When
| Audience | What They Need | When | Channel |
|---|---|---|---|
| Clinical staff | Downtime procedures activation, system status, paper charting protocols | Immediately upon incident confirmation | Phone tree, text blast, in-person briefing |
| Patients with same-day appointments | Whether their appointment will proceed, alternate contact information | Within 2 hours | Phone calls, text messages (from non-compromised system) |
| All scheduled patients (next 72 hours) | Updated scheduling status, whether telehealth visits are affected | Within 24 hours | Phone, email from alternate address, website notice |
| Business associates and vendors | Breach status, shared data exposure, coordinated response needs | Within 24 hours | Direct contact per BAA terms |
| Cyber insurance carrier | Incident notification per policy terms | Per policy (often within 24-72 hours) | Designated claims process |
| HHS / OCR (if breach confirmed) | Breach notification per HIPAA Breach Notification Rule | Without unreasonable delay; no later than 60 days after discovery | HHS Breach Portal |
| Practice leadership / board | Recovery progress, financial impact, regulatory exposure, patient impact | Daily briefings during active recovery | Secure briefing (not via compromised email) |
If your email is compromised, you cannot use it to notify patients or staff. If your patient portal is down, you cannot post notices there. Your communication plan must include out-of-band channels — a personal cell phone tree, a pre-configured text blast service, a static web page hosted separately from your primary site. Plan these channels before the incident. As we covered in The Compliance Trap, the gap between what you think you have and what actually works under pressure is where organizations fail.
RTO and RPO: The Two Numbers Every Practice Owner Must Know
Recovery planning comes down to two measurable targets that every practice leader must understand and approve — because they represent business decisions, not technical ones:
Recovery Time Objective (RTO)
How long can you be down? This is the maximum acceptable time between system failure and restoration. For a telehealth practice, an RTO of 4 hours means you must be able to restore critical systems (EHR, scheduling, telehealth platform) within 4 hours of an incident. Your RTO drives your infrastructure investment — shorter RTOs require more robust (and expensive) recovery solutions.
Recovery Point Objective (RPO)
How much data can you lose? This is the maximum acceptable data loss measured in time. An RPO of 1 hour means you can tolerate losing up to 1 hour of data — the last hour of chart notes, billing entries, and appointment changes. If your backups run nightly, your RPO is 24 hours. If that's unacceptable for your practice, you need more frequent backups or real-time replication.
Practical RTO/RPO Targets for Small Telehealth Practices
| System | Suggested RTO | Suggested RPO | Rationale |
|---|---|---|---|
| EHR / Clinical Records | 4 hours | 1 hour | Direct patient safety impact; clinical continuity requires access to recent records |
| Scheduling / Appointments | 4 hours | 4 hours | Patient communication depends on knowing who's coming; can reconstruct from printed schedules if needed |
| Telehealth Video Platform | 8 hours | N/A (SaaS) | Can fall back to phone visits temporarily; platform vendor manages their own backup |
| Billing / Claims | 24 hours | 4 hours | Revenue impact is real but not immediate; claims can be held and batch-submitted after restoration |
| Email / Communication | 2 hours | 24 hours | Staff coordination during incident requires email; historical email loss is tolerable |
| Practice Website | 24 hours | Weekly | Post patient-facing status updates; low-change content tolerates weekly backups |
RTO and RPO are not IT decisions — they are business risk decisions that must be approved by practice leadership. A 4-hour RTO for your EHR costs more than a 24-hour RTO. The question for leadership is: "What is 20 hours of additional EHR downtime worth in lost revenue, patient trust, and regulatory risk?" That conversation, documented and signed off by leadership, is exactly what NIST CSF 2.0 GOVERN (GV.RM) calls for. See our Governance Dashboard for how to report these metrics to your board.
The Telehealth Recovery Problem: What's Different When Care Is Virtual
Traditional disaster recovery was designed for organizations with a physical perimeter — restore the server room, bring the network back up, and staff walk back in. Telehealth breaks every one of those assumptions. When your clinicians work from home offices across multiple states and your patients connect from personal devices on residential Wi-Fi, "restoring normal operations" is a fundamentally different challenge.
Distributed Workforce
Your providers aren't in one building. Recovery communications must reach clinicians across multiple locations, time zones, and personal devices — and you can't assume they'll check their work email if it's down.
Patient Device Dependency
Patients scheduled for telehealth visits can't "walk in" as a fallback. You need alternate modalities — phone visits, rescheduling to in-person, or temporary platform alternatives — pre-planned and communicated fast.
Platform Interdependencies
Telehealth platforms depend on scheduling systems, EHR integrations, e-prescribing services, and billing APIs. As we covered in the API Security post, a single integration failure can cascade into a full operational disruption.
Documentation Continuity
When the EHR is down, clinicians need a paper charting fallback — even for telehealth visits conducted by phone. Those paper records must later be reconciled into the restored electronic system without data loss.
The Paper Charting Fallback Is Not Optional
Every telehealth practice needs a downtime documentation kit — printed forms, pen-and-paper workflows, and a reconciliation process for when systems come back. This isn't about going backward; it's about maintaining patient safety when technology fails. As Microsoft's Sherrod DeGrippo has emphasized, clinical staff need clear protocols for working offline, including manual charting and printed medication schedules.
Your downtime kit should include: printed patient schedules for the next 72 hours (refreshed daily), blank encounter forms with required data fields, medication reference sheets for patients on active treatment protocols, phone numbers for pharmacies and referral partners (not stored only in the EHR), and a reconciliation checklist for entering paper documentation into the restored EHR.
Artifact: The 1-Page Telehealth Recovery Runbook
A recovery plan that requires reading 200 pages under pressure is not a recovery plan — it's a paperweight. Below is a one-page runbook designed for a small telehealth practice. Print it. Post it. Drill it quarterly.
📋 Telehealth Recovery Runbook — 1-Page Quick Reference
Print this. Post it in the office, in the IT room, and in the practice manager's emergency folder.
🔴 PHASE 1: First 30 Minutes — Confirm and Contain
- Confirm the incident: Is this a system outage or a security incident? Contact IT support / MSP immediately.
- Do NOT attempt to restore from backup until the threat is contained — restoring onto a compromised system re-infects.
- Activate phone tree: notify practice manager, lead clinician, IT contact, and office manager.
- Disconnect affected systems from the network if directed by IT / incident response team.
- Pull the printed downtime kit: patient schedules, blank encounter forms, pharmacy contacts.
🟡 PHASE 2: Hours 1–4 — Stabilize and Communicate
- Begin paper charting for any patients currently being seen or in-office.
- Contact patients with same-day appointments: advise on status (phone visit, reschedule, or proceed).
- Notify cyber insurance carrier per policy terms.
- If breach is suspected: do NOT communicate via potentially compromised email. Use personal phones or pre-designated alternate channels.
- Document everything: who was notified, what was said, what decisions were made, and when.
🔵 PHASE 3: Hours 4–24 — Restore in Priority Order
- IT / MSP verifies backup integrity before beginning restoration (RC.RP-03).
- Restore systems in priority order: (1) EHR, (2) Scheduling, (3) Email, (4) Telehealth platform, (5) Billing.
- Contact patients with appointments in the next 72 hours with updated status.
- Notify business associates and vendors if shared data may be affected.
- Begin drafting patient notification communications if breach is confirmed.
🟢 PHASE 4: Days 1–7 — Verify and Normalize
- Verify integrity of restored data: spot-check patient records, confirm appointment histories, validate billing data (RC.RP-05).
- Reconcile all paper documentation into the restored EHR.
- Review and re-enable all integrations: e-prescribing, lab interfaces, telehealth API connections.
- Conduct access control audit: confirm all accounts are legitimate, no new unauthorized accounts exist.
- Re-baseline security monitoring and logging (connect to Monitoring Map).
⬛ PHASE 5: Days 7–30 — Learn and Improve
- Conduct post-incident review with all stakeholders. Document what worked and what didn't.
- Update this runbook based on lessons learned.
- File regulatory notifications if required (HHS/OCR breach report within 60 days of discovery).
- Schedule a recovery re-test within 90 days to validate improvements.
- Brief practice leadership / board on incident impact, response effectiveness, and investment recommendations.
IT Support / MSP: __________________ | Cyber Insurance: __________________
Practice Manager Cell: __________________ | Lead Clinician Cell: __________________
Legal Counsel: __________________ | Incident Response Retainer: __________________
Test It or Lose It: A Quarterly Recovery Validation Cadence
HIPAA classifies testing and revision procedures as "addressable" — which, as we've discussed in The Compliance Trap, many practices interpret as "optional." It isn't. "Addressable" means you must either implement it or document why an equivalent alternative is in place. NIST CSF 2.0 removes the ambiguity entirely: RC.RP-03 explicitly requires verifying backup integrity before using them for restoration.
Here is a practical quarterly testing cadence that a small telehealth practice can execute without shutting down operations:
Full Backup Restore Test
Restore your EHR database to a test environment. Verify patient record integrity, appointment data, and billing history. Measure actual restoration time against your RTO target. Document any gaps.
Communication Channel Test
Activate your phone tree and text blast system. Measure how long it takes to reach all staff. Test your out-of-band patient notification process. Confirm your alternate email / communication channels work.
Tabletop Exercise with Recovery Focus
Run the ransomware tabletop scenario with emphasis on the recovery phase. Walk through the runbook step by step. Identify decision points where staff hesitated or were unsure. Update the runbook.
Paper Charting Drill + Vendor Dependency Review
Run a 2-hour paper charting exercise during a low-volume period. Simultaneously review your vendor recovery SLAs: does your EHR vendor commit to a specific RTO? Does your telehealth platform have a published status page and incident history?
Your quarterly testing cadence should feed directly into the Telehealth Cyber Oversight Dashboard. Board-level metrics should include: last successful backup restore test date, actual RTO vs. target RTO, communication channel test results, and post-audit hardening sprint status (see Post-Audit Sprint).
HIPAA vs. NIST CSF 2.0: The Recovery Gap
| Recovery Capability | What HIPAA Requires | What NIST CSF 2.0 Adds |
|---|---|---|
| Data Backup | Create and maintain retrievable exact copies of ePHI (§164.308(a)(7)(ii)(A)) — Required | Verify backup integrity before restoration; confirm backups are isolated from attacker access (RC.RP-03) |
| Disaster Recovery Plan | Establish procedures to restore any loss of data (§164.308(a)(7)(ii)(B)) — Required | Prioritized recovery actions with defined RTO/RPO; integration with incident response; post-recovery verification (RC.RP-01, -02, -05) |
| Emergency Operations | Continue critical business processes during emergency mode (§164.308(a)(7)(ii)(C)) — Required | Paper charting fallback, alternate communication channels, vendor failover, distributed workforce coordination |
| Testing | Testing and revision procedures (§164.308(a)(7)(ii)(D)) — Addressable | Regular, documented testing with measurable outcomes; lessons learned feeding continuous improvement (RC.RP-06) |
| Recovery Communication | Breach notification to HHS and affected individuals (Breach Notification Rule) | Proactive stakeholder communication throughout recovery; internal and external status updates; trust preservation (RC.CO) |
| Post-Incident Normalization | Not specifically addressed | Defined criteria for "recovery complete"; post-incident operational norms; lessons learned integration (RC.RP-04, -06) |
The pattern is consistent with what we documented in the comprehensive NIST CSF 2.0 Guide: HIPAA establishes the regulatory floor. NIST CSF 2.0 builds the operational capability. The practices that survive incidents are the ones that treat HIPAA as the starting point, not the finish line.
Self-Assessment: Is Your Practice Recovery-Ready?
📋 Recovery Readiness Assessment — 10 Questions
Answer honestly. Each "no" or "I don't know" represents a gap that could extend your downtime from hours to weeks.
- Have you successfully restored your EHR from backup to a test environment in the past 12 months?
- Can you state your practice's RTO and RPO targets for critical systems — and has leadership approved them?
- Do you have a paper charting kit that is current, accessible, and that staff have been trained to use?
- If your email goes down, do you have an alternate way to reach all staff within 30 minutes?
- Do you have pre-drafted communication templates for patients, staff, vendors, and regulators?
- Are your backups stored in a location that is logically and physically separate from your production systems?
- Do you know your EHR vendor's committed RTO — and have you verified it in your BAA or SLA?
- Can your practice continue to see patients (even by phone) if both your EHR and telehealth platform are unavailable?
- Does your cyber insurance policy cover the full cost of incident response, forensics, and patient notification?
- Has your incident response / recovery plan been reviewed or tested in the past 12 months?
The Fractional CISO Role in Recovery Planning
Recovery planning requires someone who understands both the clinical workflow and the technical infrastructure — someone who can translate "RC.RP-03" into "test the backup restore every quarter and document the results." For most small telehealth practices, that person doesn't exist on staff.
A fractional CISO brings recovery planning into the governance structure your practice needs without the cost of a full-time hire. Specifically, a fractional CISO will conduct a business impact analysis to establish clinically-driven RTO/RPO targets, build and test the recovery runbook with your team, establish the quarterly testing cadence and track results on your governance dashboard, coordinate with your MSP and vendors to validate their recovery commitments, and ensure your recovery capabilities satisfy both HIPAA contingency plan requirements and NIST CSF 2.0 RECOVER function outcomes.
The investment in recovery planning pays for itself the first time your practice avoids even a single day of additional downtime. As the Sophos 2025 data shows, the mean recovery cost for healthcare organizations has dropped to $1.02 million — but that's the mean. For small practices without tested recovery plans, a single incident can be an existential event.