EU sales and compliance teams ask two questions about Gong that are related but distinct: whether Gong is secure as a platform, and whether using Gong is compliant under GDPR and EU data protection law. A signed DPA is necessary for GDPR compliance, but it does not fully answer the security question, because security for EU data extends beyond breach events to which jurisdiction can legally access the data. This page covers both: the security posture, the structural risks from US infrastructure and the CLOUD Act, and the full DPA checklist an EU controller needs to run.
Did Gong have a security breach?
Gong has disclosed security incidents over its history, as most SaaS platforms processing significant volumes of business data eventually do. The more significant and persistent concern for EU organizations, however, is not point-in-time breach events but the structural exposure that applies to all US-controlled vendors regardless of their security practices: the US CLOUD Act. Under the CLOUD Act, US authorities can compel a US-headquartered company to produce data it holds, wherever those servers physically sit. A DPA between you and Gong cannot contract that reach away, because the reach comes from statute, not contract. This structural access risk exists independently of whether Gong has ever experienced a breach. Even a flawless security record does not change the jurisdiction Gong answers to.
Is Gong safe for EU customer data?
The answer depends on which dimension of safety you are evaluating. As a platform, Gong applies enterprise-grade security controls, holds security certifications, and undergoes third-party audits. As a US-headquartered vendor processing EU personal data, it carries inherent exposure that security controls cannot eliminate: its infrastructure and corporate nexus sit within reach of US legal process. An EU organization using Gong to record sales calls with EU data subjects is transferring personal data to a US-controlled processor, relying on a transfer mechanism (typically the EU-US Data Privacy Framework) that has already been struck down twice in its prior iterations, and accepting residual CLOUD Act risk that its DPA cannot resolve. These are structural characteristics of Gong's architecture, not criticisms of its security team. They define what EU safety actually means in this context.
What do Gong's sub-processors mean for EU GDPR compliance?
Gong, like every large SaaS vendor, uses sub-processors: third-party companies that handle some part of the data processing on its behalf. Under GDPR Article 28, each sub-processor must be disclosed, must operate under terms that flow the same obligations down the chain, and the controller has the right to object to new sub-processors. For an EU controller using Gong, the practical question is where each sub-processor physically runs and whether any of them sits within reach of US or other non-EU legal process. A sub-processor list that looks manageable at a glance can still route audio capture, transcription, or AI analysis through infrastructure that adds transfer exposure. Reviewing the current Gong sub-processor list, not just the DPA itself, is part of your compliance due diligence.
Do you need a DPA with Gong?
Yes. Under Article 28 GDPR, any controller that engages a processor to handle personal data must have a written contract governing that processing. When your organization uses Gong to record, transcribe, and analyze conversations, you are the data controller and Gong is your data processor. That relationship triggers the Article 28 requirement automatically. No compliant Gong deployment skips the DPA.
Call recordings and transcripts are unambiguously personal data. They contain identifiable voices, names, job titles, email addresses, and often commercial detail about individuals on both sides of the call. Because those data subjects include people located in the EU, GDPR applies to the processing. A Gong DPA is therefore the baseline document. The question worth spending time on is not whether you need it, but what it does and does not cover once it is in place.
What a Data Processing Agreement actually covers
A DPA sets the Article 28 rules between controller and processor. It is a contract about how the processor must handle data, not a certificate that the processing is lawful.
Data Processing Agreement (DPA) is the written contract required by Article 28 GDPR whenever a controller uses a processor. It binds the processor to purpose limitation (process only on the controller's documented instructions), appropriate security measures, controlled terms for engaging sub-processors, deletion or return of data at contract end, audit and inspection rights, assistance with data subject requests, and breach notification. It does not establish a lawful basis for the processing, and it does not change which jurisdiction can compel the data.
That last point is the one procurement teams miss most often. A DPA is a promise between two private parties about how they will behave. It obliges Gong to keep your data confidential, to notify you of incidents, and to delete data when you leave. What it cannot do is override the law Gong is subject to. If a government with authority over Gong compels disclosure, the confidentiality clause in your DPA yields to that order. The contract governs conduct. It does not govern jurisdiction. Keeping those two ideas separate is the point of reading a Gong DPA carefully rather than treating the signature as the finish line.
Gong's sub-processors and where processing happens
Gong is a US-headquartered company, and its processing and storage have historically touched US infrastructure. For an EU controller, that raises two questions the DPA alone does not answer: who else handles the data, and where does the handling physically occur. The answer to the first is Gong's sub-processor list. The answer to the second requires locating where audio capture, transcription, and AI analysis actually run.
Under Article 28, a processor can only engage sub-processors on terms that flow the same obligations down the chain, and the controller has the right to know who they are. Gong publishes a sub-processor list, and reviewing the current version is part of your due diligence, not an optional extra. Each sub-processor is another party with access to some slice of your call data, and each one has its own location and its own legal exposure. A DPA that looks tidy at the top level can still route audio or transcription through infrastructure you did not expect.
This is where the distinction between residency and sovereignty matters. Residency is where the data physically sits. Sovereignty is which jurisdiction can compel it. A vendor can offer EU residency for storage while its US parent, its US employees, or a US sub-processor still sits within reach of US legal process. Reading the sub-processor list and mapping where each stage of processing runs is how an EU controller tells the difference between a residency claim and genuine sovereignty. For the broader breakdown of how this plays out across a full Gong deployment, see our analysis of Gong, EU data sovereignty, and GDPR.
The CLOUD Act reaches past the DPA
A US-controlled processor can be compelled under the US CLOUD Act to produce data it holds, regardless of where the servers physically sit. A DPA cannot contract that reach away, because a private contract between a controller and a processor does not bind a government or override the law the processor operates under.
The mechanics are direct. The CLOUD Act lets US authorities compel a US company to hand over data within its possession or control, even when that data lives on servers outside the United States. Gong, as a US company, is subject to it. If a valid order arrives, Gong must comply, and the confidentiality provisions of your DPA do not provide a lawful ground to refuse. Orders can also carry non-disclosure obligations, so the controller may never learn that access occurred. No clause you negotiate into a Gong DPA changes this, because the reach comes from statute, not contract. For how this statute interacts with EU data protection, see our explainer on the CLOUD Act and EU data sovereignty for AI.
The transfer mechanism you are relying on
Every EU-US data flow needs a lawful transfer mechanism, and the one most US vendors rely on today is the EU-US Data Privacy Framework, usually backed by Standard Contractual Clauses. When you sign a Gong DPA that moves EU personal data to US infrastructure, this is the legal basis carrying that transfer. It is worth knowing how stable that basis actually is.
The Data Privacy Framework is the third attempt at a durable transatlantic transfer basis. Safe Harbor was struck down by the Court of Justice of the EU in 2015. Its successor, Privacy Shield, was struck down in 2020 in the Schrems II judgment. The DPF is the replacement, and it too is under active legal challenge. A compliance posture built on the DPF alone therefore carries standing risk: if the framework is invalidated during your contract term, as its two predecessors were, any transfers relying on it become retroactively exposed and you must fall back to SCCs and a fresh transfer assessment. That is not a reason to panic, but it is a reason to name the mechanism explicitly in your records and to monitor its status rather than assume it is settled.
Your Gong DPA checklist
Before you sign or renew a Gong DPA, an EU controller should work through the following. Each item is something the DPA either establishes, points to, or fails to address, and each one is your responsibility to verify.
- Signed Article 28 DPA in place. Confirm an executed DPA exists that names the parties, the subject-matter and duration, the nature and purpose of processing, the categories of personal data, and the categories of data subjects.
- Current sub-processor list reviewed. Pull Gong's latest published sub-processor list, confirm the DPA gives you notice of changes, and record who each sub-processor is and what they touch.
- Where processing physically runs. Locate where audio capture, transcription, and AI analysis actually execute. Distinguish storage residency from processing location, since they can differ.
- Transfer mechanism named. Identify the mechanism carrying any EU-US transfer, typically the Data Privacy Framework plus SCCs, and record it in your own documentation.
- Retention and deletion terms. Verify how long recordings and transcripts are kept and confirm the DPA commits Gong to delete or return the data at contract end.
- Breach-notification SLA. Check the timeframe within which Gong must notify you of a security incident, and confirm it aligns with your own GDPR notification duties.
- Audit rights. Confirm the DPA grants you meaningful audit and inspection rights over the processing carried out on your behalf.
- Whether a US parent can be compelled. Assess whether Gong, its US parent, or a US sub-processor can be compelled under US law such as the CLOUD Act, because that exposure sits outside anything the DPA can promise.
A DPA backed by jurisdiction, not just paper
The theme across every item above is that a DPA is only as strong as the jurisdiction behind it. With a US-controlled provider, you can negotiate excellent contract terms and still carry residual transfer risk, sub-processor exposure, and CLOUD Act reach that no clause resolves. That is the structural gap between a well-drafted paper and genuine control over your data.
A sovereign meeting assistant closes that gap by keeping audio capture, transcription, storage, and AI analysis under EU jurisdiction, so the DPA is backed by where the data actually lives rather than by a contract alone. When there is no US parent, no US-hosted processing, and no US sub-processor in the chain, there is no CLOUD Act order to answer and no transfer mechanism to monitor. The DPA still matters, but it is reinforced by jurisdiction instead of being asked to carry the whole load. Numi is a sovereign meeting assistant built on exactly that principle. For a wider view of the EU-native options in this category, see our guide to Gong alternatives for the DACH region in 2026.