GCC High Compliance

If we are already in a GCC High tenant, does our existing phone system create a compliance gap?

An existing phone system running outside the GCC High boundary almost certainly creates a compliance gap. Legacy Private Branch Exchange (PBX) systems and commercial Voice over Internet Protocol (VoIP) services typically store call logs and metadata outside U.S. government-compliant data centers, lack FedRAMP High certification, and do not meet DFARS 7012 encryption requirements.

The gap matters because voice communications that carry or reference CUI fall under the same compliance requirements as email, file sharing, and other data flows. If your email and documents are protected within GCC High but your phone calls route through a non-compliant system, you have a hole in your compliance posture. Specific risks include call metadata stored in commercial data centers (potentially outside the U.S.), support personnel who are not screened U.S. citizens, lack of audit logging for ITAR-related communications, and encryption that does not meet DoD standards. Moving to Teams Phone through Direct Routing in GCC High closes this gap by bringing voice into the same compliant boundary as the rest of the Microsoft 365 workload. Organizations that delay this migration risk contract disqualification, DFARS enforcement actions, and security vulnerabilities from maintaining outdated infrastructure alongside a compliant tenant.

How does GCC High Teams calling handle call metadata and logs, and where is that data stored and who can access it?

All call metadata and logs generated within GCC High Teams calling are stored in FedRAMP High-compliant data centers located exclusively within the United States. Access to this data is restricted to screened U.S. personnel who have passed enhanced background checks, including U.S. citizenship verification and FBI fingerprint screening.

Signaling data is encrypted using Transport Layer Security (TLS), and media streams are encrypted using Secure Real-time Transport Protocol (SRTP) with AES encryption. Microsoft support personnel do not have standing access to GCC High production environments. Any staff requesting temporary access must pass the full background screening process, which includes seven-year employment and criminal history verification, Social Security Number validation, and checks against the Office of Foreign Assets Control (OFAC), Bureau of Industry and Security (BIS), and Defense Trade Controls debarred persons lists. Audit logs and tracking are available for ITAR-related communications, and organizations can configure retention policies within the GCC High boundary. The key distinction from commercial Teams is that no call data, metadata, or logs leave the U.S. sovereignty boundary, and no unscreened personnel can access the data at any point.

Is end-to-end encryption available for all calls in GCC High Teams, including PSTN calls to external numbers?

End-to-end encryption (E2EE) is available for Teams-to-Teams calls within the GCC High environment, but it is not available for PSTN calls to external phone numbers. This is a protocol-level limitation, not a GCC High-specific restriction.

When two GCC High Teams users call each other, the call can be encrypted end-to-end so that only the two participants can access the audio. When a call routes to an external phone number through the PSTN, the encryption chain breaks at the SBC gateway where the call transitions from the Teams digital environment to the traditional telephone network. The PSTN infrastructure does not support E2EE. Within the GCC High boundary, PSTN calls are still protected by TLS encryption on the signaling path and SRTP encryption on the media path between the Teams client and the SBC. The call travels through compliant, U.S.-only infrastructure up to the PSTN handoff point. Organizations that need fully encrypted voice communications for sensitive discussions should use Teams-to-Teams calls within the GCC High tenant rather than PSTN calls to external numbers.

How does Direct Routing for GCC High satisfy the voice communication requirements in DFARS 7012 and CMMC 2.0?

Direct Routing for GCC High satisfies DFARS 7012 and CMMC 2.0 voice requirements by routing all call traffic through FedRAMP High-authorized infrastructure, encrypting signaling and media, restricting data storage to U.S.-only facilities, and limiting access to screened U.S. personnel. These controls map directly to the NIST SP 800-171 requirements that both frameworks reference.

DFARS 252.204-7012 requires contractors to use cloud service providers that meet FedRAMP authorization for storing, processing, and transmitting covered defense information. GCC High holds FedRAMP High authorization, which satisfies this requirement for voice communications routed through Direct Routing. The 110 security controls in NIST SP 800-171, which CMMC Level 2 requires, include access control, audit and accountability, identification and authentication, and system and communications protection. Direct Routing in GCC High addresses these by enforcing role-based access through Microsoft Entra ID, maintaining audit logs of call activity, supporting multifactor authentication (including PIV and CAC cards), and encrypting all call traffic within the compliance boundary using TLS and SRTP. DFARS 7012 also requires contractors to flow these requirements down to subcontractors, which means subcontractors handling CUI in voice communications need the same level of compliant infrastructure.

What does dynamic E911 location routing look like when employees are working remotely in a GCC High Teams environment?

Dynamic E911 in a GCC High Teams environment detects a remote employee's physical location and routes emergency calls to the correct local Public Safety Answering Point (PSAP) with a dispatchable street address. This meets the requirements of RAY BAUM's Act and Kari's Law for accurate emergency location reporting.

For remote workers, the Teams client can detect location using the device's operating system location services (Windows or Mac), the connected Wi-Fi access point, or the Ethernet subnet. When an employee dials 911, Teams matches the detected network information to a pre-configured emergency address and routes the call to the appropriate PSAP with that address attached. If automatic detection fails (which can happen with VPN full-tunnel configurations that mask the local subnet), the system can prompt the user to manually enter their location, or it falls back to a statically defined emergency address in the user's profile. Administrators configure dynamic emergency calling through the Teams Admin Center by mapping network identifiers (subnets, Wi-Fi access points, Ethernet switches) to emergency addresses with geo codes. For Direct Routing in GCC High, the administrator must also configure the connection to an Emergency Routing Service (ERS) provider or set up Emergency Location Identification Number (ELIN) handling on the SBC. Emergency addresses older than two years must be re-created before they can be assigned to network identifiers.