Why does handling PHI in Zoom create compliance risk even when a BAA is in place?

Why This Matters for Security Teams

A BAA establishes contractual obligations, but it does not by itself stop PHI from being exposed through meeting invites, screen sharing, chat messages, recordings, or unsecured file transfers. For compliance teams, the risk is not only whether the platform is covered, but whether the organisation can prove it has governed how PHI is used in practice. That distinction aligns with the outcome-focused approach in the NIST Cybersecurity Framework 2.0, which expects organisations to manage risk through policy, control execution, and monitoring.

The common mistake is treating the BAA as a substitute for user behaviour controls. If clinicians, administrators, contractors, or support staff can freely disclose PHI in meetings without guardrails, then the organisation inherits exposure even when the vendor is contractually compliant. This is where identity and access governance matter: role-based restrictions, authenticated access, and audit trails determine whether PHI handling is constrained to authorised participants and approved workflows. In practice, many security teams encounter PHI leakage only after a meeting was recorded, shared, or misrouted rather than through intentional policy enforcement.

How It Works in Practice

Operational compliance depends on aligning the collaboration tool to privacy controls, not just legal terms. The starting point is to define what PHI is permitted in each workflow, who may disclose it, and which features are allowed. That usually means reviewing meeting access, waiting rooms, authentication settings, external participant controls, file sharing, chat retention, transcription, and recording. The control objective is to reduce both accidental disclosure and unauthorised access to content that may be stored or forwarded outside the intended audience.

Security teams should map the platform configuration to established control families in NIST SP 800-53 Rev 5 Security and Privacy Controls and the management system expectations in ISO/IEC 27001:2022 Information Security Management. In practice, that means:

• Restricting PHI discussions to authenticated users and approved groups.
• Limiting recording, transcript generation, and file transfer where not required.
• Applying retention rules so chat and recordings do not outlive business need.
• Logging access, invitations, configuration changes, and content sharing events.
• Training users on when PHI must not be placed in general-purpose collaboration channels.

Where organisations also use the platform for onboarding, customer support, or regulated disclosures, the governance model should include periodic review of user roles, meeting templates, and exception handling. Controls are most effective when they are enforced by default rather than left to individual discretion. These controls tend to break down when guest access, ad hoc screen sharing, and unmanaged recording are allowed in high-volume environments because the platform becomes a disclosure channel faster than reviewers can detect it.

Common Variations and Edge Cases

Tighter PHI controls often increase friction for clinical staff, support teams, and external collaborators, requiring organisations to balance confidentiality against operational speed. That tradeoff is real, and best practice is evolving around how much user flexibility is acceptable in different care or service scenarios. There is no universal standard for this yet, especially where remote consultations, cross-organisation care coordination, or third-party interpreters are involved.

One edge case is that a BAA may cover the vendor, but not the downstream risk created by administrators who can export content, configure integrations, or copy meeting artefacts into other systems. Another is that a platform can be configured securely, yet users may still disclose PHI verbally or in chat without realising it becomes part of a record. A mature programme therefore needs governance over content, not just infrastructure.

For organisations handling regulated personal data across mixed workflows, it is often helpful to pair privacy controls with security management practices from ISO/IEC 27002:2022 Information Security Controls. Where financial services, benefits administration, or identity verification processes intersect with PHI, accountability expectations may also overlap with the FATF Recommendations in relation to KYC and identity assurance, although that is context-dependent rather than universal. Current guidance suggests the safest operating model is to treat the platform as a controlled communication environment, not a trusted PHI repository by default.

Related resources from NHI Mgmt Group

• Why does PHI in SharePoint create compliance and breach risk even when access controls are in place?
• Why do collaboration platforms create compliance risk even with MFA in place?
• Why do non-human identities create compliance risk even when policies exist?
• Why do non-human identities create PCI compliance risk even when no human logs in?