Prove the care can continue, isolate, and return clean.
Cyber assurance becomes clinically meaningful when every essential service can show who may act, what it depends on, how it degrades safely, when it must isolate, and what evidence permits trusted restoration.
Healthcare cybersecurity is often described through frameworks, inventories, vulnerabilities, alerts, controls, and incident plans. Those are necessary. They do not by themselves prove that an emergency department can register and identify patients safely, a pharmacy can dispense, a laboratory can communicate results, or a hospital can restore trustworthy records after compromise.
The Clinical Cyber Safety Case starts with a service-level claim: a defined care capability can remain safe through loss or compromise, isolate when necessary, and return to digital operation only after technical and clinical evidence agree. The label is an editorial operating model, not a government program, certification, or regulatory term.
Its one-page Minimum Viable Care assurance card identifies the care promise, patient consequence, clinical and cyber owners, dependencies, trust boundaries, organization-defined downtime and recovery objectives, degraded workflow, isolation authority, restoration prerequisites, reconciliation owner, last proof, and next test.
This service-level discipline can be used alongside the site’s existing guidance on healthcare cybersecurity for executives, the Ascension cyberattack case, healthcare supply-chain resilience, and the hospital-of-the-future agenda. Those enterprise perspectives become safer when each critical service also has a testable care claim, two accountable release authorities, and evidence for extended downtime, clean recovery, and reconciliation.
Five proof loops keep the card alive: identity; dependency and supplier; safe isolation; continuity under extended downtime; and clean recovery with data reconciliation. Each loop connects a condition to evidence, exception, owner, decision, and retest date.
Cyber resilience is not proven when a control exists on paper or a server turns green. It is proven when a critical clinical service can enter a known degraded state, protect patients, contain unsafe trust, restore from a verified foundation, reconcile the work performed during disruption, and show the evidence again.
The approach complements broader enterprise cybersecurity. It concentrates leadership attention on a smaller question that can be tested: what must this service accomplish for patients when digital trust is uncertain, and what must be true before normal operation resumes?
The twelve evidence exhibits below move from authority and Minimum Viable Care through five proof loops, reconciliation, evidence cadence, management measures, and final assurance decision.
Know which cyber claim is a duty, a practice, or a choice.
Begin with the current source and entity. The HIPAA Security Rule remains in effect for covered entities and business associates and protects electronic protected health information. A January 2025 update remains proposed as of August 3, 2026. Do not build a binding-duty statement from proposed text.
Medicare-participating hospitals also operate under the hospital emergency-preparedness condition of participation. CMS guidance treats cyber-caused communications interruption as part of all-hazards planning. That emergency-preparedness regulation does not specifically prescribe antivirus or electronic-security products and should not be generalized to every healthcare entity.
HITECH section 13412 requires OCR to consider whether a regulated entity adequately demonstrated that recognized security practices were in place for the prior twelve months in certain enforcement and audit activities. This is not a safe harbor, certification, Security Rule substitute, or penalty guarantee. Preserve what was actually implemented and used.
Voluntary resources serve different purposes. The 2026 ASPR RISC 2.0 cyber module is a registration-required self-assessment scored against NIST CSF 2.0 and HHS goals. The 2026 ASPR TRACIE facility-level assessments support planning. Neither is an audit, attestation, regulation, or proof that a service is safe.
Maintain one authority register across legal, compliance, security, emergency preparedness, clinical operations, information technology, biomedical engineering, facilities, privacy, and vendors. A service card can point to the register rather than reproducing every rule and interpretation.
Define the care that must remain safe when trust is uncertain.
Minimum Viable Care is not ordinary service with fewer conveniences, and it is not permission to accept preventable harm. It is the locally defined, time-bounded clinical capability that can be delivered safely under specific degraded conditions while leaders restore capability, transfer patients, reduce scope, or activate another site.
Choose one critical service and one disruption condition. Examples include loss of the electronic health record, identity service, network, laboratory interface, medication system, imaging archive, communications platform, connected device function, vendor-hosted application, or a utility on which technology depends.
Set downtime and recovery objectives from local clinical consequence, dependency, staffing, supply, technology, and risk. No source in this framework creates a universal government recovery-time threshold for every service. Record the owner, rationale, assumption, validation method, and condition for revision.
Include extended conditions. A workflow that works for thirty minutes may fail after a shift change, rising census, depleted labels, unavailable specialists, delayed results, repeated transcription, staff fatigue, or inability to reconcile accumulating paper. Define safe duration and the evidence supporting it.
Make reduction decisions visible to patients and partners when appropriate. Alternate sites, longer waits, rescheduled services, different communication, and manual processes need accessible instructions, language support, privacy, complaint routes, and clear advice about when emergency care remains available.
Put the entire service claim on one evidence card.
The assurance card is a navigation surface, not the complete plan. It lets an executive, clinician, security lead, incident commander, auditor, or recovery team see the service claim, current proof, exceptions, and next decision without searching through disconnected documents.
Assign two accountable owners. The clinical owner defines necessary care, safe degraded work, patient consequence, service limits, and return-to-use validation. The cyber owner defines trust boundaries, isolation, technical prerequisites, investigation, recovery evidence, and monitoring. Neither can release the service alone.
Link every field to a controlled evidence object: dependency map, role matrix, technical configuration, supplier record, downtime procedure, exercise result, restoration test, clinical validation, reconciliation script, deficiency log, risk acceptance, or corrective action. Preserve version and review date.
Mark uncertainty explicitly. Unknown supplier dependency, incomplete inventory, untested manual workflow, stale contact, unsupported device, unverified backup, or unresolved data-integrity question should appear as an exposure, not disappear behind a green summary.
Keep the card usable offline and during loss of the normal collaboration platform. Protect sensitive architecture and access details while ensuring authorized responders can retrieve what they need. Test access under the same disruption assumptions as the service.
Use unambiguous card states. Current means the claim and all material proof remain within scope and date. Limited means named conditions or interim controls narrow the assurance. Expired means evidence has aged or a material change occurred. Refused means the service cannot support the claim. Never let an expired or limited card appear as current because a remediation ticket remains open.
Prove who can act in normal, emergency, and recovery states.
Identity is a clinical dependency. People and services need the right access at the right time, while compromise of a privileged or shared identity can spread disruption across applications, cloud services, devices, backups, and recovery tools.
Map workforce, patient, device, service, administrator, emergency, vendor, application, certificate, and machine identities that the care service uses. Record the authoritative source, authentication, privilege, approval, lifecycle, shared use, logging, recovery dependency, and behavior when the primary identity system is unavailable.
Zero trust architecture rejects implicit trust based only on network location or ownership. Use that principle to examine each access request, resource, identity, device condition, and policy. NIST SP 800-207 is guidance and an abstract architecture, not a product, legal rule, or maturity certification.
Test identity loss and compromise separately. Loss asks whether authorized people can continue safe work when authentication services fail. Compromise asks whether the team can contain a trusted-but-hostile identity without disabling essential care. The fallback for one may be unsafe for the other.
Close the proof loop when the organization can demonstrate the expected access, detect and revoke inappropriate access, support emergency clinical need, preserve evidence, and rebuild trust without relying on an identity whose integrity remains uncertain.
Trace the care service past the edge of the network.
A clinical service may depend on identity, network, power, name resolution, time, certificates, data feeds, cloud platforms, medical devices, remote support, a laboratory, pharmacy, clearinghouse, telecommunications carrier, or specialized supplier. Local system availability can hide a failed external dependency.
Build the map from the clinical task outward. For every dependency, record the function, owner, provider, trust boundary, data, access, upstream and downstream reliance, concentration, support window, recovery role, alternate, manual route, time limit, and evidence source. Include utilities and physical access where their loss creates digital downtime.
NIST supply-chain guidance can organize risk across products and services, but it is voluntary unless adopted through an applicable requirement or contract. Use it to ask for supplier evidence, vulnerability handling, recovery support, component visibility, secure updates, and exit or data portability without treating a questionnaire as proof.
For medical devices, use manufacturer labeling and cybersecurity evidence as procurement, deployment, maintenance, isolation, and recovery inputs. The February 2026 FDA premarket guidance primarily addresses manufacturers and FDA submissions, including section 524B. A provider should not claim that the manufacturer’s submission duty became the provider’s duty.
The CISA Known Exploited Vulnerabilities Catalog identifies evidence of active exploitation. Binding Operational Directive 22-01 remediation dates apply to federal civilian executive branch agencies, not private hospitals. A healthcare organization should set its own documented windows using exploitation, exposure, clinical consequence, compensating controls, test capacity, and vendor support.
Pre-authorize the boundary between containment and care.
Technical containment can protect the enterprise and simultaneously remove a clinical capability. Disconnecting a device, disabling an identity, blocking a vendor, closing a network path, or taking an application offline needs a decision process that weighs cyber propagation against immediate patient consequence.
Define isolation units in advance: account, session, endpoint, device, application, interface, vendor connection, subnet, location, service, site, cloud tenant, or another controlled boundary. For each, identify the signal, evidence confidence, technical authority, clinical authority, safe alternate, communication, monitoring, rollback, and escalation.
Prepare a smallest-safe-boundary sequence. Begin with the narrowest action that can contain the credible path while protecting care, then expand when evidence or speed requires it. Do not delay urgent containment for perfect certainty, but record assumptions and clinical safeguards.
Exercise disagreement. A security responder may see urgent lateral movement while a clinical leader sees an unstable patient relying on the system. The protocol needs a rapid decision authority, alternate capability, real-time observation, and a way to revise the decision as evidence changes.
NIST SP 800-61 Revision 3, finalized in April 2025, integrates incident-response recommendations with cybersecurity risk management. It is voluntary unless adopted by an applicable authority or contract. Use it to strengthen preparation, detection, response, recovery, and learning while keeping clinical consequence explicit.
For connected medical devices and facility controls, pre-identify who can assess safe disconnection, which local function remains, whether the device must be replaced or quarantined, how the patient moves, and when the manufacturer or service organization participates. Preserve evidence without leaving an unsafe device in care solely because its forensic value is high.
Design for the hour when the temporary workflow stops working.
A short exercise can prove that forms exist and still miss the breaking point. Extended downtime changes volume, staff mix, supplies, fatigue, patient identification, result delivery, medication reconciliation, referral, transfer, scheduling, discharge, privacy, record storage, and the ability to locate the latest truth.
Model the service across time. Identify what changes at fifteen minutes, two hours, a shift, overnight, a weekend, a surge, or multiple days. Those are planning intervals, not universal thresholds. Use local clinical consequence and capacity to determine when the service narrows, diverts, transfers, or closes.
Include utility failure. Loss of power, network, telecommunications, water, environmental control, or physical access can create the same digital and clinical consequences as malicious disruption. The 2026 ASPR TRACIE extended-downtime assessment is a voluntary planning tool and explicitly is not mandatory.
Test with representative staff, shifts, sites, languages, disabilities, and patient complexity. Include new employees, rotating clinicians, partners, and teams whose usual communication channel is unavailable. Measure task completion, error opportunity, delays, workload, supply consumption, patient understanding, and ability to escalate.
End the exercise after reconciliation planning, not when the simulated system returns. Count the records, orders, results, administrations, transfers, registrations, charges, and communications that must be brought back into trusted systems without duplication or omission.
Make restoration a two-key clinical and cyber release.
A restored application can be reachable while identities, configurations, data, interfaces, devices, dependencies, logging, or downstream workflows remain untrusted. Return to service should require both technical evidence that the environment is acceptably clean and clinical evidence that the complete care task works safely.
Define restoration prerequisites before the event: investigation and containment status, trusted administrative path, source media or image, known configuration, protected credentials, required patch or mitigation, dependency order, backup or source evidence, interface validation, monitoring, supplier role, and rollback.
Restore dependencies in an order that supports the clinical service, not simply the easiest servers. Identity, network services, certificates, time, interfaces, shared data, devices, vendor connections, and monitoring may need to precede an application. Record the reason for sequence and any temporary trust.
Use representative clinical validation without exposing real patients to an unproven environment. Simulate the full task with appropriate test data and devices, then apply a controlled production release with heightened observation. A successful login or test message is not complete workflow proof.
Keep the hold bench available. Pressure to reopen can convert uncertainty into invisible risk. If identity, integrity, containment, dependency, or clinical workflow cannot be validated, continue the degraded route, narrow the service, or transfer care until the owner pair can justify release.
Define the watch period and rollback path before release. Assign enhanced logging, clinical observations, reconciliation checks, help-desk cues, supplier availability, decision cadence, and triggers for removing the service again. A staged return can limit consequence, but only if staff know which functions are trusted, which remain unavailable, and where to report a mismatch.
Reconcile every clinical fact created outside the trusted system.
Downtime creates parallel truth. Paper forms, local files, printed lists, phone calls, verbal orders, device displays, partner messages, and temporary systems may carry pieces of the patient record. Restoration does not automatically make those facts complete, current, correctly matched, or safe to import.
Define the reconciliation unit for the service: patient, encounter, order, result, medication, specimen, image, procedure, appointment, transfer, discharge, charge, device event, or communication. Assign a clinical owner and a data owner for each queue, with source, custody, priority, matching rule, verification, exception, and completion evidence.
Prioritize by patient consequence, not ease of entry. Critical results, medication administrations, transfusions, allergies, procedures, transfers, and care-plan changes may need rapid confirmation before routine scheduling or financial data. Define who can resolve a conflict and who contacts the patient or partner.
Keep automatic replay constrained until teams understand the interruption. Queued interfaces can release duplicates, old messages, or events in an unsafe sequence. Validate source, destination, time, identifier, idempotence, rejection handling, and downstream behavior before opening the flow.
Retain evidence and learn from reconciliation load. The number and type of manual items, mismatches, near misses, unresolved records, staff hours, and patient contacts reveal where the degraded workflow or restoration design needs improvement.
Retest when the service changes, not only when the calendar says so.
Assurance decays. A passed exercise may no longer describe the service after a software release, network change, new device, vendor acquisition, identity migration, staffing redesign, facility move, interface replacement, policy change, new threat, or failure discovered elsewhere.
Give every evidence object an owner, scope, method, result, date, environment, participants, limitation, exception, correction, next review, and change trigger. Do not convert one successful unit, shift, or application test into enterprise assurance.
Use the 2026 ASPR facility-level cybersecurity and extended-downtime assessments to prompt local review where helpful, and record the evidence behind each answer. These tools are voluntary planning resources, not certifications, audits, regulations, or attestations.
Test the boundary between services. One card may pass alone while a shared identity, communications platform, supplier, network, utility, staff pool, or recovery team becomes the limiting resource during simultaneous disruption. Cross-card exercises reveal concentration and sequencing conflicts.
Close every test with an evidence receipt: claim tested, observed result, care effect, exception, immediate control, root issue, owner, funding or decision, due date, retest, and updated card status. An exercise is incomplete when lessons remain in presentation notes.
Measure the strength of the claim, not the volume of activity.
Counts of scans, alerts, policies, training completions, tickets, and backups can show work without showing whether the clinical service can withstand loss of trust. Service assurance measures connect conditions, proof, exceptions, care performance, and recovery.
Begin with card coverage and freshness: critical services with an owner pair, defined Minimum Viable Care, verified dependencies, tested isolation authority, extended-downtime evidence, clean-recovery proof, reconciliation owner, and no overdue material exception. Report the scope and confidence of each measure.
Add patient and workforce effects: care delayed or diverted by technology failure, identification or medication defect, result communication failure, staff hours consumed, manual queue growth, missed break, near miss, patient complaint, privacy incident, and subgroup access. Protect sensitive data and small groups.
Separate exposure from readiness. A service can have material unresolved vulnerability and strong tested continuity, or low apparent exposure and weak recovery. Leaders need both dimensions to decide whether to remediate, compensate, restrict, replace, diversify, transfer, or accept time-limited risk.
Give every red condition a patient consequence, owner, interim control, due date, funding decision, and retest. Avoid a composite score that lets strong documentation cancel an untested recovery path or a known high-consequence dependency.
Grade evidence strength without turning it into a decorative score. A policy statement, interview, configuration sample, observed workflow, controlled simulation, extended exercise, and successful clean restoration support different confidence. Record environment and limitations. Prefer the smallest claim the evidence can honestly sustain, then strengthen it through representative testing.
Sign the service claim, limit it, or refuse it.
A Clinical Cyber Safety Case ends in a management decision, not a maturity label. The clinical and cyber owner pair presents the care claim, current evidence, exceptions, patient consequence, interim controls, recovery readiness, reconciliation capability, and resources required.
The accountable executive can accept the claim within defined conditions, limit the service or technology, require correction before continued use, transfer the capability, or accept time-bound residual risk at the proper level. No assurance seal should imply immunity from attack or perfect safety.
Reopen the decision after a material incident, failed test, supplier change, service redesign, architecture change, new legal duty, recognized exploitation, recurring downtime, unexplained data mismatch, patient harm, or missed correction date. Assurance is a renewable claim.
Connect the cards across enterprise governance. Shared dependencies, recovery sequencing, workforce capacity, vendor concentration, and competing restoration objectives require portfolio decisions. A locally valid card can still depend on a shared capability whose total demand exceeds capacity.
Preserve candor. A red or refused claim is useful evidence that protects patients and directs investment. Do not punish teams for exposing uncertainty, and do not let a polished dossier outrank observed failure, frontline concern, or unresolved clinical risk.
Conclusion: make cyber resilience a clinical evidence claim.
Healthcare organizations need enterprise cybersecurity, regulatory compliance, risk management, incident response, and technical controls. The Clinical Cyber Safety Case does not replace them. It forces their value to be demonstrated at the point where failure affects care.
One Minimum Viable Care card names the service, patient consequence, owner pair, organization-defined objectives, dependencies, trust boundaries, degraded workflow, isolation authority, restoration prerequisites, reconciliation owner, and current proof. That compact record turns broad readiness into a bounded claim leaders can challenge.
The five proof loops prevent a false return to normal. Identity must be trustworthy. Dependencies and suppliers must be visible. Isolation must contain cyber risk without creating uncontrolled clinical harm. Extended downtime must remain safe over time. Recovery must begin from an acceptably clean foundation and end with reconciled clinical truth.
No card certifies immunity from attack, perfect safety, or legal compliance. Its value lies in disciplined candor: what was tested, what failed, what remains unknown, who owns the consequence, which interim control protects patients, and when the evidence will be renewed.
A service should return only when the clinical and cyber keys turn together. That two-key release is the difference between restoring technology and restoring trustworthy care.
Sources and further reading
- HHS OCR, The HIPAA Security Rule. Current binding requirements for covered entities and business associates protecting electronic protected health information. The January 2025 Security Rule update remains proposed as of August 3, 2026.
- 42 CFR 482.15, Hospital Emergency Preparedness. Binding emergency-preparedness requirements for Medicare-participating hospitals. Its hospital scope should not be generalized to every healthcare entity, and local recovery objectives are not prescribed here.
- CMS, Homeland Security Threats. CMS planning information that includes cyber-caused communications interruption in all-hazards preparedness. The underlying regulations consider electronic security but do not specifically require an antivirus product.
- HHS OCR, Security Rule Guidance Material and Recognized Security Practices. Official guidance on Security Rule topics and HITECH recognized-practices consideration. Recognized-practices evidence is not safe harbor, certification, a compliance substitute, or a penalty guarantee.
- ASPR, RISC 2.0 Cybersecurity Module. A 2026 voluntary, registration-required self-assessment scored against NIST CSF 2.0 and HHS cybersecurity goals. It is not certification or compliance proof.
- ASPR TRACIE, Health Care Facility-Level Cybersecurity Assessment. A 2026 voluntary facility planning tool. It is not an audit, regulation, attestation, or evidence that one clinical service can operate safely through disruption.
- ASPR TRACIE, Health Care Facility-Level Extended Downtime Assessment. A 2026 voluntary planning tool that also considers utility-caused downtime. It explicitly is not mandatory and does not prescribe a universal safe duration.
- NIST SP 800-61 Revision 3, Incident Response Recommendations and Considerations. Finalized in April 2025 and superseding Revision 2. It is voluntary unless adopted by an applicable law, regulator, contract, or policy.
- NIST SP 800-207, Zero Trust Architecture. Guidance that rejects implicit trust based only on location or ownership. It is an abstract architecture, not a product, legal rule, certification, or maturity score.
- NIST SP 800-161 Revision 1 Update 1, Cybersecurity Supply Chain Risk Management Practices. Voluntary product and service supply-chain guidance that can inform supplier evidence, recovery support, concentration, and exit or data-portability planning.
- CISA, Known Exploited Vulnerabilities Catalog. A source of evidence on vulnerabilities known to be exploited. Federal BOD 22-01 deadlines bind federal civilian executive branch agencies, not private hospitals.
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. February 2026 guidance primarily for manufacturers and FDA premarket review. Providers can use labeling and manufacturer evidence without assuming manufacturer submission duties.
