The healthcare organisation remains accountable for how PHI is handled, even when a third-party platform is involved. A BAA defines vendor responsibilities, but internal teams still own configuration, access control, monitoring, and staff behaviour. In practice, legal, compliance, security, and business owners must share responsibility for governance, evidence, and remediation.
Why This Matters for Security Teams
When PHI is exposed in a Zoom meeting or chat, the immediate question is not whether the platform was involved, but whether the healthcare organisation controlled the use of that platform in a way that met its privacy, security, and compliance obligations. Under the HIPAA security model, accountability does not disappear because a third-party service is used. Vendor contracts matter, but they do not replace internal governance, workforce training, access control, or incident response discipline. NIST SP 800-53 Rev. 5 is useful here because it shows how technical and administrative safeguards must work together, not in isolation.
The most common mistake is treating the collaboration tool as the owner of the risk. In practice, the organisation decides who can join, what can be shared, how chats are retained, and whether meeting settings are secure by default. A business associate agreement can define a vendor’s obligations, but it does not transfer the organisation’s duty to protect PHI. This is especially important when chat logs, screen shares, recordings, or calendar links are left accessible after the meeting ends.
In practice, many security teams encounter PHI exposure only after a user has already shared it in the wrong meeting, rather than through intentional governance of meeting controls.
How It Works in Practice
Accountability usually splits across four layers: the healthcare organisation, the platform provider, the workforce user, and the governance functions that oversee them. The organisation remains responsible for deciding whether the tool is approved for PHI, how it is configured, and whether the associated risks are documented and monitored. The platform provider may support encryption, logging, and admin controls, but those capabilities only help if they are turned on and enforced.
For operational teams, the practical control points are straightforward:
- Use a formal approval process for any collaboration platform that may handle PHI.
- Apply meeting controls such as waiting rooms, authenticated joins, host approval, and restricted chat.
- Disable unnecessary recording, file transfer, transcription, and persistent chat where PHI is not required.
- Review audit logs, access settings, and retention rules on a recurring basis.
- Train users on what counts as PHI and how quickly a harmless-looking chat can become a reportable exposure.
This is where governance meets evidence. If a regulator, auditor, or incident responder asks who approved the setting, who monitored the session, and who acted after the exposure, the answer must come from internal records, not vendor assurances. A BAA is necessary when the platform may touch regulated data, but it is only one part of the control environment. For broader control mapping, NIST’s guidance on access, auditability, and configuration management is the right baseline, and the NIST SP 800-53 Rev 5 Security and Privacy Controls is the clearest reference point for translating this into enforceable safeguards.
These controls tend to break down when collaboration tools are adopted by departments faster than security teams can standardise settings, because local admin choices and shadow workflows quickly outrun central policy.
Common Variations and Edge Cases
Tighter collaboration controls often increase friction for clinicians and care coordinators, requiring organisations to balance usability against the need to keep PHI out of informal channels. That tradeoff is real, especially in telehealth, remote rounds, care coordination, and patient support teams where speed matters.
Best practice is evolving for newer features such as AI meeting summaries, auto-captioning, and message assistants. There is no universal standard for this yet, but current guidance suggests treating these features as separate data-processing paths that may expand retention, sharing, and exposure risk. If PHI enters an AI-generated transcript or summary, the organisation still owns the downstream risk, including access scope and retention. This is where agentic workflows and AI-assisted productivity tools can create hidden governance gaps, particularly if they are enabled without a privacy review.
Edge cases also matter when chat is used for internal escalation, patient handoffs, or urgent clinical communication. Short-lived messages can still be reportable if they contain PHI, and deleted content may still exist in logs, backups, or exports. The same caution applies to recordings shared outside the original meeting context. For threat-informed teams, the risk is not only accidental disclosure but also misuse of collaboration channels as an entry point for social engineering or account compromise, a pattern increasingly visible in reports such as Anthropic — first AI-orchestrated cyber espionage campaign report.
When PHI exposure occurs in a platform that was never formally governed for healthcare use, accountability typically fails at the boundary between policy and daily workflow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight define accountability for third-party collaboration risk. |
| NIST SP 800-53 Rev 5 | AC-3 | Access enforcement is central to preventing PHI exposure in meetings and chat. |
Assign named owners for platform risk, approvals, monitoring, and remediation.
