Cloud & Infrastructure
Updated
Hybrid-cloud readiness is not a count of servers that can be moved. For a healthcare practice, it is evidence that clinicians can still find accurate information, staff can continue essential work during an outage, electronic protected health information (ePHI) remains protected, and someone owns every dependency that crosses the cloud and the practice.
This guide is narrower than a general migration plan. Use it before approving a pilot or cutover for an EHR-connected application, imaging workflow, document platform, communications service, or other workload that will remain partly on premises. It produces a go, conditional-go, or no-go decision. It does not certify HIPAA compliance, and a vendor's willingness to sign a business associate agreement (BAA) does not prove that the practice's configuration or operating procedures are compliant.
Define the workload before evaluating the cloud
Write one workload boundary that a clinical and technical owner can both recognize. Name the patient-care process, users, sites, devices, interfaces, data stores, identity provider, internet and power dependencies, vendor support path, recovery sequence, and on-premises components that remain. The HHS risk-analysis guidance says the analysis must include all ePHI an organization creates, receives, maintains, or transmits. A diagram that omits a scanner, interface engine, local cache, or vendor support account creates a false readiness result.
Classify what happens when each dependency fails. "The application is unavailable" is not enough. State whether appointments stop, medication history becomes inaccessible, results queue locally, claims pause, or a paper workflow begins. Give the downtime procedure a clinical owner and test whether the information captured during downtime can be reconciled without duplicate or wrong-patient entries.
Make shared responsibility specific
A cloud provider operates some controls; the practice and its partners retain others. Responsibility changes among software, platform, and infrastructure services, and it can change again for managed add-ons. The HHS cloud-computing guidance explains that a cloud service provider maintaining ePHI is generally a business associate even when it cannot decrypt the data. HHS also advises customers to understand the offered environment, perform their own risk analysis, and align BAA and service-level terms.
Create a responsibility record for identity, endpoint security, encryption and key control, vulnerability remediation, logging, backup, restoration, incident notification, data return, secure deletion, interface monitoring, and support escalation. For each row, name the party that performs the control, the party that verifies it, and the evidence retained. "Vendor handles security" is not an acceptable owner.
Use the readiness scorecard
Score each row 0 when evidence is absent or the control cannot work, 1 when it is designed but not demonstrated in the target workflow, and 2 when a named owner has current evidence from a test or operating record. This is a local decision aid, not a regulatory score or industry benchmark.
| Readiness check | Evidence to record | Owner and decision field |
|---|---|---|
| Clinical workflow and downtime | Walkthrough, downtime form, reconciliation result, unacceptable patient-safety impact | Clinical owner; score; blocking issue |
| Data and interfaces | ePHI inventory, source and destination, retention, interface failure and replay test | Data owner; score; exception |
| Legal and vendor terms | BAA determination, executed agreement when required, SLA, subcontractor and data-return terms | Privacy or contract owner; score; approval |
| Shared security controls | Responsibility map for access, encryption, patching, logging, response, and deletion | Security owner; score; evidence link |
| Identity and endpoints | Role map, MFA method, privileged path, device baseline, joiner/mover/leaver test | Identity owner; score; open action |
| Connectivity and local dependencies | Bandwidth and failover test, DNS, power, printing, scanning, device and site dependencies | Infrastructure owner; score; failure impact |
| Recovery and rollback | Restore result, measured recovery, integrity check, rollback trigger and decision authority | Continuity owner; score; last test |
| Operations and support | Monitoring alert, escalation test, maintenance notice, vendor contact and after-hours coverage | Service owner; score; acceptance |
The NIST HIPAA Security Rule resource guide offers implementation questions and mappings that can strengthen the evidence column. Use it as a cybersecurity resource, not as a substitute for applying the actual rule to the practice.
Apply hard gates before totals
A high total must not hide one unsafe dependency. Mark no-go when the clinical downtime and reconciliation path has not been exercised; a required BAA or accountable contracting decision is missing; ePHI locations are unknown; the recovery or rollback path cannot be demonstrated; privileged access lacks an accountable owner; or a critical interface can fail without detection. The HHS Security Rule summary describes requirements for risk analysis, security incident procedures, contingency planning, evaluation, and business-associate arrangements. Those responsibilities do not disappear during a migration.
Use conditional go only when remaining gaps have a named owner, due date, compensating measure, and written acceptance by the clinical, security, and operational decision makers. Use go when hard gates pass and the evidence demonstrates that the pilot boundary is supportable. Record the exact approved scope; approval for one location or interface is not blanket approval for the full migration.
Prove recovery and safe rollback
Backups are inputs, not recovery evidence. Restore representative data into an isolated destination, confirm integrity and access, time the workflow, and document dependencies needed before clinical use resumes. HHS's ransomware fact sheet connects backup, disaster recovery, emergency operations, application criticality, and periodic contingency-plan testing. Recovery evidence should cover the hybrid boundary, including cloud configuration, identities, keys, interface queues, and on-premises services.
Define rollback before cutover: who can call it, what observable condition triggers the decision, the last safe decision time, which writes must be reconciled, and how users learn that the old path is active again. Avoid an improvised reversal that produces two writable systems or two versions of a patient record.
Run a limited pilot with observable exit criteria
Choose a pilot whose risk is representative but containable. Capture authentication failures, interface errors, help-desk demand, workflow delays, monitoring coverage, backup completion, and unresolved exceptions. The CISA Cloud Security Technical Reference Architecture emphasizes identity, logging, configuration management, data protection, incident response, and recovery as connected cloud-security capabilities. A pilot should therefore test the operating system around the service, not only whether the application launches.
At the gate review, show the scorecard, hard-gate status, test records, accepted exceptions, rollback readiness, and a recommendation. The clinical owner decides whether care delivery remains workable; privacy and security owners assess their domains; operations confirms supportability; and the accountable executive accepts residual business risk.
Related planning guides
Use the broader cloud migration checklist to organize the full project, the healthcare MSP selection guide to examine provider claims and responsibilities, and the backup versus disaster recovery guide to clarify continuity design. This scorecard remains the pre-cutover decision record for the specific hybrid healthcare workload.