How should healthcare organisations share responsibility for data security when migrating to the cloud?

What shared responsibility means in a healthcare cloud migration

Shared responsibility is the operating model that keeps cloud security practical. The provider secures the underlying cloud platform, but the healthcare organisation still owns the security of the data it places there, including classification, lawful processing, access governance, and who can see protected health information. If that boundary is not explicit, teams often assume the cloud vendor is responsible for controls the customer must actually design, configure, and verify.

For healthcare, the boundary matters because regulated and sensitive data rarely sits in one place or under one team’s control. Security responsibility has to follow the data through storage, sharing, backup, analytics, and support workflows, not stop at the infrastructure layer. The practical question is less “who hosts it?” and more “who can prove the control works at each stage of use?”

Which responsibilities stay with the healthcare organisation?

The customer side of the model usually covers data governance, identity and access design, encryption decisions, monitoring, auditability, retention, and incident response. In practice, that means deciding which datasets may move, which users or systems may access them, what conditions must be met, and how access is reviewed over time. The cloud platform may offer the capability, but the organisation must define the policy and validate the configuration.

Healthcare teams should also treat compliance as a shared design requirement, not a post-migration review. If the organisation cannot demonstrate data minimisation, logging, segregation of duties, and timely revocation of access, the migration is incomplete even if the cloud service itself is secure. The security model should be documented before go-live so business, clinical, and security owners agree on the same control boundary.

That is why cloud security assessments often map customer responsibilities to CSA Cloud Controls Matrix domains, especially IAM, data security, audit, and infrastructure governance. It is also why implementation guidance such as ISO/IEC 27002:2022 Information Security Controls remains useful for translating high-level responsibility into concrete controls.

How should teams prove the boundary is working in practice?

The most reliable approach is to make responsibility testable. Before migration, organisations should confirm who owns each control, what evidence will demonstrate that it is active, and how exceptions will be approved. After migration, they should continuously verify access paths, logging coverage, encryption configuration, and administrative privileges rather than relying on design documents alone.

That verification has to include the full identity path behind access to the cloud environment and to the data itself. A control is not really shared if only the vendor can explain it or if the customer cannot see who granted access, how it is reviewed, and when it is removed. For healthcare data, the most important assurance is often not technical novelty but operational visibility across users, service accounts, and third-party integrations.

Where cloud environments are part of a broader governance programme, the team should align control ownership with recognised security functions such as NIST Cybersecurity Framework 2.0 and the shared-control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls. Those references help teams turn “shared responsibility” into a measurable operating model rather than a procurement statement.

What should healthcare organisations watch most closely after migration?

The highest-risk failure is assuming the provider’s secure platform automatically makes the data secure. In reality, most cloud-related exposures come from customer-controlled misconfigurations, overly broad access, weak monitoring, or unclear ownership when multiple teams and vendors touch the same dataset. Healthcare also has a high consequence profile, so even a small access mistake can create outsized privacy, safety, and regulatory impact.

Cloud risk is amplified when access is granted for convenience, then left in place after the immediate project ends. That is especially dangerous for shared folders, analytics platforms, support accounts, and cross-environment permissions. When responsibility is split but not documented, no one notices a lingering entitlement until an audit finding or incident forces the issue.

For cloud-native control design, the NIST Privacy Framework is useful for thinking about data use and minimisation, while NIST SP 800-207 Zero Trust Architecture reinforces the “verify explicitly” mindset that healthcare cloud deployments need when access is distributed across applications, staff, and vendors.

Practitioner Guidance

What to prioritise: Define the shared responsibility boundary in writing before data moves, and tie each control to a named owner, evidence source, and review cadence. If the control cannot be evidenced, it is not operationally shared.

What to verify: Confirm that the customer side owns access decisions, logging review, data classification, retention, and exception handling. The vendor may provide tooling, but the healthcare organisation must be able to demonstrate who approved access, when it was last reviewed, and what triggers revocation.

Common mistake: Treating cloud adoption as a security transfer instead of a control reallocation. That shortcut usually leaves governance gaps around data access, audit evidence, and compliance accountability, which are the exact areas healthcare regulators and auditors tend to examine.

Practitioner takeaway: A safe cloud migration is not measured by how much security the provider offers, but by how clearly the healthcare organisation can own, prove, and continuously enforce the controls that protect patient data.

Related resources from NHI Mgmt Group

• How should security teams apply the shared responsibility model after migrating sensitive data to the cloud?
• Who should own cloud data security in organisations with shared responsibility across security, infrastructure, and development teams?
• How should healthcare organisations begin strengthening HIPAA security when patient data may sit across EHRs, cloud services, and business systems?
• How should healthcare organisations build a patient data privacy and security plan that covers ePHI across systems, cloud apps, and third parties?