DE Toolkit Compliance Verticals
Knowledge Base

Compliance Verticals

Compliance Verticals — Full Reference

This document is the authoritative reference for compliance requirements on deployments. For the sign-off process and CLI commands, see 08-compliance-requirements.md. This document provides the deeper “why” and context for each vertical.

HealthComm — HIPAA

What HIPAA covers in a UCaaS context

HIPAA’s Security Rule requires covered entities and business associates to implement safeguards for electronic Protected Health Information (ePHI). When a UCaaS platform handles calls, voicemails, or communications that include PHI (patient names, conditions, appointments, prescriptions), it becomes a system that processes ePHI.

Does every healthcare customer trigger HIPAA? Yes — if they receive any federal healthcare funding (Medicare, Medicaid), they are a covered entity and HIPAA applies. Most medical offices, hospitals, clinics, dental offices, and pharmacies are covered entities.

The BAA in detail

The Business Associate Agreement (BAA) is a contract between the customer (covered entity) and the UCaaS provider (business associate). The BAA requires the UCaaS provider to:

  • Implement appropriate administrative, physical, and technical safeguards to protect ePHI
  • Report any security incidents or breaches
  • Ensure subcontractors also sign BAAs
  • Return or destroy PHI upon contract termination

How to get the BAA:

  • RingCentral: Request HIPAA BAA tier during account setup; BAA is in the partner portal under “Legal Documents”
  • 8x8: HIPAA BAA available in X4 and higher tiers; contact account team
  • Net2Phone: BAA available — contact partner support
  • Webex Calling: BAA available — government/healthcare tier

Critical: The BAA must be executed BEFORE the customer uses the platform for any PHI-bearing calls. Configuring the platform and then getting the BAA later is a HIPAA violation.

Call recording in HIPAA environments

Call recording stores PHI. Requirements:

  • Recording storage must be encrypted at rest (verify in platform admin console)
  • Access to recordings must be restricted to authorized personnel only (role-based access)
  • Recording retention must comply with HIPAA’s 6-year record retention requirement
  • Recordings may not be accessed without authorization — audit logging must track who accessed what

Voicemail in HIPAA environments

Voicemail may contain PHI (a patient calling to leave their name and condition). Requirements:

  • Voicemail storage must be encrypted (covered by the BAA)
  • Voicemail-to-email should be configured to organization email only (not personal addresses)
  • Consider whether voicemail transcription is enabled — transcriptions are stored as text (also ePHI)

SecureVoice — PCI-DSS

What PCI-DSS covers in a UCaaS context

PCI-DSS (Payment Card Industry Data Security Standard) applies to any organization that processes, stores, or transmits cardholder data (CHD). The “phone system is in PCI scope” problem arises when customers speak their card numbers over the phone to an agent.

The goal: Remove the UCaaS system from PCI scope entirely, so it doesn’t need to be audited.

Three ways to de-scope the phone system

Method 1: DTMF suppression (preferred) The caller enters their card number via keypad. The UCaaS platform suppresses the DTMF tones in recordings (replaces them with silence or standard tones). The card number never appears in any recording or log. The phone system is de-scoped because no CHD passes through it in a usable form.

Configure DTMF suppression in the platform’s call recording settings. Not all platforms support it on all tiers — verify before proposing.

Method 2: Pause/resume recording The agent pauses the call recording before asking for card information and resumes after. Manual — relies on agent compliance. Less reliable than DTMF suppression but simpler to implement.

Method 3: Out-of-band payment capture The agent tells the customer: “I’ll send you a secure payment link — please complete the payment there.” The card number never goes through the voice channel at all. This is the cleanest solution but requires a payment link system.

QSA involvement

Most PCI customers have a Qualified Security Assessor (QSA) who conducts their annual PCI audit. The QSA must review and approve the UCaaS architecture as part of the audit. Engage the QSA early (during Stage 3) so there are no last-minute surprises.

What the QSA needs from you:

  • Diagram of the UCaaS architecture showing call flows
  • Explanation of how card data is handled (DTMF suppression, pause/resume, or out-of-band)
  • Evidence of encryption for call recordings
  • Access controls for recording playback

GovConnect — FedRAMP

What FedRAMP means

The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide security authorization program for cloud services. Any cloud software used by US federal agencies (and often state agencies with federal funding) must be FedRAMP authorized.

FedRAMP authorizations are at three impact levels:

  • Low: For public, non-sensitive information
  • Moderate: Most federal systems — covers most UCaaS deployments
  • High: Highly sensitive national security systems

Most UCaaS deployments need FedRAMP Moderate.

The ATO process

Authorization to Operate (ATO) is the formal approval for an agency to operate a specific IT system. Adding a new UCaaS platform requires the agency’s ISSO (Information System Security Officer) to add it to the existing ATO or issue a new one.

Timeline: ATO updates can take 4–8 weeks or longer. This must be factored into the migration timeline for government customers. Do not plan a go-live date without confirming the ATO process has started.

US data residency

FedRAMP requires that all data remain within the continental United States. Verify with the platform:

  • All data centers are US-located
  • No offshore support personnel have access to federal customer data
  • No international subprocessors

RingCentral Government, Webex Government, and Zoom for Government all maintain US-only data residency for their Government Cloud tiers.

Separate tenants for government

This is critical: The Government Cloud platforms (RingCentral Government, Webex Government) are separate infrastructure from the commercial products. A government customer on standard RingCentral is NOT on a FedRAMP-authorized platform. You must specifically provision the Government Cloud tenant.

Contact your channel manager to confirm the correct provisioning path for government customers.

EduComm — FERPA

What FERPA covers in a UCaaS context

FERPA (Family Educational Rights and Privacy Act) protects the privacy of student education records at educational institutions that receive federal funding (virtually all public schools and most private schools and universities).

Does FERPA require the same technical controls as HIPAA? No. FERPA is primarily about data use restrictions rather than technical security controls. The key FERPA requirements for UCaaS are:

  • The platform provider cannot use student data for commercial purposes (marketing, selling data)
  • Student education records (including call data involving students) cannot be disclosed without consent
  • Parental consent is required for minors (K-12)

Practical FERPA requirements

Data Processing Agreement (DPA): All 6 of our standard platforms offer a DPA that explicitly prohibits marketing use of customer data. Verify the customer’s contract with the platform includes the DPA language.

Call recording with students: If any call recordings could contain student education records (e.g., a school counselor recording calls with students, or a financial aid office recording loan discussions), those recordings are FERPA-protected. Apply the same access controls as you would for HIPAA recordings.

K-12 parental consent: If calls involving minors are recorded, the institution needs a parental consent process. This is a policy decision for the customer — document that you’ve flagged it.

COPPA (bonus consideration): If the institution serves children under 13, COPPA (Children’s Online Privacy Protection Act) may also apply to any communication platform that collects data from or about children. Flag this for the customer’s compliance team — it’s outside your sign-off scope but should be noted.

FERPA vs. HIPAA

FERPA and HIPAA often co-apply in healthcare education settings (nursing schools, medical schools, dental schools with student clinics). In these cases, both verticals may apply. Flag to your manager — these require compliance counsel involvement, not just a DE sign-off.

Cross-vertical considerations

What to do when a customer spans multiple verticals

Example: A state health department (government + healthcare) — both FedRAMP and HIPAA may apply. Example: A university hospital (education + healthcare) — both FERPA and HIPAA may apply.

In these cases:

  1. Detect both verticals using compliance_checker.py
  2. Apply all requirements from both verticals
  3. Note the dual-vertical in HubSpot and Supabase
  4. Consult with manager — these deployments often require legal review beyond your sign-off

Compliance documentation at project close

For every regulated deployment (any vertical), produce a compliance summary document at migration close:

python3 execution/compliance_checker.py --migration-id <uuid> --check-status --json > compliance_report_<customer>_<date>.json

Provide this JSON to the customer’s compliance officer. It documents:

  • Which vertical was detected
  • Which requirements were signed off
  • Who signed off each requirement and when
  • The Splunk audit trail reference

This documentation protects both you and the customer if questions arise later.