Who is accountable when a healthcare organisation stores PHI in a messaging platform without proper safeguards?

Why This Matters for Security Teams

Storing PHI in a messaging platform shifts the technical surface area, but it does not shift the compliance duty. Healthcare organisations still have to prove that access is limited, messages are retained appropriately, auditability is preserved, and disclosures are controlled. A Business Associate Agreement helps define contractual responsibility, but it is not a substitute for operational safeguards or governance. The practical risk is not just a policy gap; it is unauthorized disclosure, weak retention, and unmanaged sharing through consumer-like workflows.

For security and privacy teams, the key issue is that messaging tools often blur the line between collaboration and data storage. That means PHI can spread into devices, notifications, exports, backups, and third-party integrations faster than the original risk assessment assumed. Controls such as encryption, identity enforcement, logging, and retention need to be mapped to the actual data path, not just the platform category. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it translates policy into enforceable control families.

In practice, many security teams encounter PHI exposure only after a retention, forwarding, or device-sync issue has already spread the message beyond the intended workflow.

How It Works in Practice

Accountability follows the organisation that chooses the platform, configures the workflow, and authorises PHI use. That means the covered entity or business associate must define whether messaging is permitted for clinical coordination, whether PHI is allowed in channels or direct messages, and how users authenticate before access. If the platform stores content, then the organisation is also responsible for encryption at rest, key management, session protection, logging, and the ability to remove or export PHI under policy.

Operationally, this usually breaks down into four steps:

• Classify what PHI may be sent, by whom, and for which business purpose.
• Require strong identity controls, including MFA and role-based access boundaries.
• Apply retention, deletion, and audit logging settings that match legal and clinical requirements.
• Review integrations, mobile sync, backups, and notification previews for unintended PHI leakage.

The platform provider may support safeguards, but responsibility for configuration, oversight, and workforce behaviour remains with the healthcare organisation. That is consistent with HIPAA’s shared responsibility model and with broader privacy governance expectations. Security architects should map the platform to HHS HIPAA Security Rule guidance, then validate controls against messaging-specific risks such as unmanaged forwarding, BYOD access, and cross-account data mixing. If the environment includes alerts, case management, or automated summaries, the organisation should also check whether those outputs create new PHI copies that fall under the same retention and access rules. These controls tend to break down when consumer messaging habits are allowed inside clinical workflows because users treat the platform as temporary, while the system may preserve or replicate data permanently.

Common Variations and Edge Cases

Tighter control often increases friction for clinicians and support staff, requiring organisations to balance rapid communication against privacy and audit requirements. That tradeoff is especially visible in emergency care, telehealth, and contractor-heavy operations, where speed matters and message volume is high. Best practice is evolving on how much PHI should be permitted in general-purpose messaging tools, and there is no universal standard for this yet. Some organisations allow limited PHI only in managed channels, while others prohibit PHI entirely and route it through dedicated patient communication systems.

Edge cases arise when the messaging platform is hosted by a business associate, when messages are mirrored into e-discovery archives, or when AI features summarize conversations. In those cases, the original organisation still needs to understand where PHI is stored, who can retrieve it, and whether downstream systems create additional compliance exposure. If a tool supports ephemeral messages, that does not automatically mean legal retention obligations disappear. Likewise, encryption alone does not solve unauthorized access if permissions are too broad or shared accounts are used.

For risk owners, the right question is not whether the platform is “secure enough” in the abstract, but whether the specific workflow can meet HIPAA, security, and privacy requirements under real operating conditions.

Related resources from NHI Mgmt Group

• Who is accountable when PHI is shared in Slack without proper safeguards?
• Who is accountable when a high-risk relationship is approved without proper EDD?
• How do organisations govern agent security without over-trusting platform safeguards?
• Who is accountable when a healthcare partner misuses delegated PHI access?