A cloud service can supply compliant features, but it does not accept the covered entity’s legal duties. Under HIPAA, the healthcare organisation must decide what data is stored, how access is granted, how breaches are assessed, and how notifications are handled. The provider may alert administrators, but internal policy, governance, and response remain the customer’s responsibility.
Why the Compliance Burden Does Not Move to Microsoft 365
Microsoft 365 can provide security features, logging, encryption options, and contractual commitments, but those capabilities do not replace the healthcare organisation’s role as the entity deciding why PHI is processed, who may access it, and how exceptions are handled. In practice, compliance is a shared control environment, but legal accountability remains with the covered entity or its business associate chain, not the cloud platform alone.
The important distinction is between service capability and operational responsibility. A cloud provider may harden the platform, but the organisation still owns data classification, retention, access approval, workforce rules, incident triage, and the decision to treat an event as a reportable breach.
Which HIPAA Duties Still Belong to the Healthcare Organisation
HIPAA does not outsource the core governance decisions that make PHI handling compliant. The organisation must define permissible use, map roles to access, review who can see mailboxes and shared files, and confirm that admin privileges do not exceed business need. That is where policy becomes compliance: the service can enforce settings, but it does not decide the organisation’s accountability model.
That same boundary applies to breach assessment and notification. Microsoft may provide alerts, audit trails, and tenant telemetry, but the organisation must determine whether an exposure involved PHI, whether the event meets breach criteria, and whether notification obligations are triggered. Those judgments depend on internal context, not vendor automation alone.
This is why a HIPAA-ready deployment still requires local governance over data handling choices, exception approval, and review of inherited controls. The platform supports compliance, but it does not close the loop on legal ownership.
What “Shared Responsibility” Means in a PHI Environment
Shared responsibility means the provider secures the cloud service and the customer secures the way it is used. For PHI, that division is especially important because configuration choices determine whether the environment actually supports least privilege, retention discipline, and auditability. A secure default is helpful, but a mis-scoped sharing rule or an overbroad mailbox permission can still create an exposure the organisation must answer for.
Practically, the healthcare organisation should treat Microsoft 365 as part of its control stack, not as a compliance substitute. If PHI is stored in email, Teams, SharePoint, or OneDrive, the organisation still needs documented access review, retention governance, backup and recovery expectations, and a process for investigating alerts from the tenant. Those operational controls define whether the deployment is defensible.
For broader cloud governance context, see CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 Security and Privacy Controls, and the NIST Cybersecurity Framework 2.0.
Where Accountability Breaks Down in Practice
The most common failure is assuming that a compliant service automatically creates a compliant workflow. In reality, responsibility breaks down when organisations leave tenant settings, access grants, and exception handling to ad hoc administrators without clear ownership. Another failure mode is believing that provider alerts are sufficient evidence of due diligence when the internal team has not defined what to investigate, who must decide, or how quickly to escalate.
PHI risk also grows when security and compliance teams are separated from the business process that actually stores the data. If users can move PHI into collaboration tools without review, the organisation can lose track of where regulated information lives and who can reach it. That creates both privacy exposure and response delay.
For the control implications of identity and access handling in cloud environments, the SOC 2 Trust Services Criteria (AICPA) and ISO/IEC 27002:2022 Information Security Controls are useful references for governance, access restriction, and logging discipline.
Risk and Threat Considerations
The main risk is not that Microsoft 365 is inherently non-compliant, it is that organisations confuse provider controls with their own compliance duties. That confusion can leave PHI overexposed through broad sharing, weak role design, poor retention control, or delayed incident review.
Failure mechanism: The tenant can be configured securely at the platform layer while the organisation still permits excessive access, incomplete review, or weak breach triage for PHI-bearing content.
Impact: The result can be unauthorized disclosure, missed notification deadlines, weak audit evidence, and a compliance gap that remains with the healthcare organisation even when the cloud service functions as designed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | M365 PHI compliance depends on controlling who can access regulated data. |
| LOG — Logging and Monitoring | HIPAA accountability relies on tenant alerts and audit trails for PHI events. | |
| Recommendation — Apply IAM governance to restrict PHI access by role and business need. Enable logging and monitoring to support PHI investigations and breach review. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | PHI access in M365 should be limited to the minimum necessary users and admins. |
| AU-6 — Audit Review, Analysis, and Reporting | The organisation must review logs and alerts to assess PHI exposure and response needs. | |
| Recommendation — Enforce least privilege for PHI storage, sharing, and administrative access. Review audit records to identify PHI incidents and trigger response actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question turns on customer responsibility for access decisions over PHI. |
| A.5.24 — Information security incident management planning and preparation | HIPAA duties include internal breach handling and escalation, not just provider alerts. | |
| Recommendation — Define and enforce access rules for PHI across Microsoft 365 services. Prepare incident procedures that assign PHI triage and notification ownership. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Shared responsibility for PHI depends on customer access governance over the service. |
| CC7.2 — System Monitoring | Customer monitoring is needed to detect PHI exposure and misuse in cloud services. | |
| Recommendation — Implement access controls that limit PHI exposure in the tenant. Monitor PHI activity and investigate anomalies promptly. | ||
Practitioner Guidance
What to verify: Confirm who owns PHI classification, who approves access, and who decides whether an event is reportable. If those decisions are not documented outside the platform, the organisation has not actually assigned accountability.
What good looks like: The tenant settings, access reviews, incident workflow, and retention rules all map to named internal owners, and provider alerts feed a defined response path rather than an informal email thread.
Practitioner takeaway: Treat Microsoft 365 as a control environment you operate, not a party that inherits your legal obligation; compliance is only credible when internal governance can prove how PHI is protected, reviewed, and escalated.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
