As patient care extends beyond hospital walls, your cloud security perimeter not only expands but also fragments across SaaS platforms, home networks, and mobile devices. This checklist helps you ensure your cloud security posture can support hospital-at-home programs without creating compliance gaps or data exposure risks.
Prerequisites
Before starting this checklist, make sure you have:
- Current cloud asset inventory: Document every public, private, and SaaS platform handling protected health information.
- Vendor contract access: Review security terms and attestation documents.
- Shared responsibility model documentation from each cloud provider.
- Access to your identity and access management (IAM) configuration across all cloud environments.
- Authority to request vendor security validation beyond standard attestations.
If you're missing any of these, pause here. You can't validate controls you can't see.
Checklist Items
1. Map Your Shared Responsibility Boundaries
Done when: You have a document detailing which security controls your organization owns versus those managed by each cloud provider, specific to each platform.
Review your cloud service provider contracts and technical documentation. Create a responsibility matrix listing infrastructure-layer controls (provider's domain) and software-layer controls (your domain). Many healthcare organizations mistakenly believe their SaaS vendor's SOC 2 Type II report covers application-level access controls, it often doesn't.
What good looks like: A table mapping each ISO/IEC 27001 Annex A control to "Provider," "Shared," or "Customer" for every cloud platform. Your team can answer "who validates MFA configuration?" without checking with the vendor first.
2. Validate Software-Layer Controls Independently
Done when: You have documented evidence of your own security control testing for every cloud application handling patient data, not just the vendor's attestation report.
Request and review SOC 2 reports, but don't stop there. Test your own configurations: Can users access patient records without MFA? Do session timeouts work as configured? Can former employees still authenticate? The cloud provider's infrastructure security doesn't guarantee your application is configured securely.
What good looks like: A quarterly validation log showing you tested authentication controls, authorization rules, and data encryption settings in each SaaS platform. You found at least one misconfiguration and corrected it, because if you didn't find anything, you didn't look hard enough.
3. Document Cloud Vendor Security Requirements in Contracts
Done when: Every new cloud vendor contract includes specific security obligations written as enforceable terms, not aspirational language.
Standard vendor agreements often say "Vendor will maintain reasonable security measures." That's not enforceable. Specify: "Vendor must maintain SOC 2 Type II certification covering Security and Availability trust service criteria, provide annual penetration test summaries, and notify Customer within 24 hours of any security incident affecting Customer data."
What good looks like: Your procurement team rejects vendor paper without consulting you first because the contract template already requires FIPS-Validated Cryptography for data at rest, annual third-party security assessments, and right-to-audit language.
4. Implement Centralized Identity Management Across Cloud Platforms
Done when: You can provision, modify, and deprovision user access across all cloud applications from a single identity provider, and you have audit logs proving it works.
Home-based care programs add remote clinicians, contract staff, and third-party care coordinators. If each SaaS platform manages its own user directory, you'll inevitably leave orphaned accounts active after someone leaves. Connect every cloud application to your central identity provider via SAML or OIDC. Test deprovisioning by terminating a test account and verifying it's disabled everywhere within your defined timeframe.
What good looks like: When a home health nurse's employment ends, her access to your EHR, scheduling platform, telehealth system, and care coordination tools all terminate automatically within four hours. You can prove this happened by exporting authentication logs from each system.
5. Classify Cloud Data by Sensitivity and Location
Done when: You have a current inventory showing which cloud environments contain protected health information, where data physically resides, and which regulatory requirements apply.
Hospital-at-home programs often generate data in multiple jurisdictions. Your cloud provider might replicate data across regions for performance, potentially triggering state-specific breach notification requirements or cross-border data transfer restrictions. Map where your patient data lives, not just which vendor hosts it.
What good looks like: A data flow diagram showing patient data moving from home monitoring devices → cloud ingestion endpoint → processing region → storage region → analytics platform. You can answer "If AWS US-East-1 has an outage, which clinical workflows break?" without calling a vendor.
6. Validate Encryption for Data in Transit and at Rest
Done when: You have verified that every cloud platform uses FIPS-Validated Cryptography for stored patient data and TLS 1.2 or higher for data transmission, and you've documented the specific cipher suites in use.
Don't assume encryption is enabled by default. Log into each cloud platform's security settings and verify encryption status. Check whether you control the encryption keys or the vendor does. For home-based care, also verify that mobile apps and remote monitoring devices use encrypted channels.
What good looks like: A spreadsheet listing every cloud application, its encryption status (enabled/disabled), key management approach (customer-managed/vendor-managed), and the date you last verified the configuration. You identified one legacy integration using TLS 1.1 and upgraded it.
7. Define and Test Cloud Incident Response Procedures
Done when: Your incident response plan includes specific procedures for cloud-based security events, with documented contact information for each vendor's security team and tested escalation paths.
A compromised cloud account requires different response steps than an on-premises breach. You might not have direct access to logs or the ability to isolate affected systems. Document how you'll coordinate with cloud vendors during an incident, including who has authority to request forensic data and how quickly vendors commit to responding.
What good looks like: You ran a tabletop exercise simulating a compromised SaaS admin account. Your team knew which vendor to call, what data preservation steps to request, and how to notify affected patients. You documented three process gaps and assigned owners to fix them.
8. Establish Cloud Access Monitoring and Alerting
Done when: You have centralized logging that captures authentication attempts, privilege escalations, and data access events across all cloud platforms, with alerts configured for suspicious patterns.
Cloud environments generate massive log volumes. Focus on high-risk events: failed login attempts from unusual locations, privilege escalations, bulk data exports, and access outside normal business hours. For home-based care, also monitor for simultaneous logins from geographically distant locations, a home health aide shouldn't authenticate from Ohio and Florida within minutes.
What good looks like: Your SIEM ingests cloud audit logs from every platform. Last month it alerted on a clinician whose account authenticated from three different states in one day. Investigation revealed a compromised credential, which you revoked before any patient data was accessed.
Common Mistakes
Treating SOC 2 reports as proof your environment is secure. The vendor's SOC 2 Type II report validates their controls, not your configuration. You still own software-layer security.
Assuming cloud vendors understand healthcare compliance. Generic cloud platforms weren't designed for HIPAA. You must configure them correctly and validate those configurations regularly.
Ignoring the mobile and home network layer. Your cloud security is only as strong as the home WiFi network your clinician uses to access it. Address endpoint security and network segmentation for remote workers.
Failing to test cross-platform access revocation. Disabling a user in your identity provider doesn't always propagate to every integrated application immediately. Test your deprovisioning process with real accounts.
Next Steps
Work through this checklist in order, each item builds on the previous one. Start with the shared responsibility mapping, because you can't validate controls if you don't know who owns them.
Schedule this as a quarterly review, not a one-time project. Cloud environments change constantly as vendors update platforms and your organization adopts new tools. What was secure in January might have gaps by April.
If you find items you can't complete because you lack vendor cooperation or technical access, that's a risk that belongs in your risk register. Document it, assign an owner, and set a remediation deadline. Your auditor will ask about it eventually, so have a treatment plan ready.
