Data Processing Agreements: What to Ask Vendors Before You Sign

A data processing agreement (DPA) is the contract that governs how a vendor handles personal data on your behalf.

Before signing with any vendor, ask about:

• data storage location
• sub-processors
• breach notification timelines
• AI training practices
• audit rights, and
• deletion procedures.

Requirements differ under GDPR, UK GDPR, and US state privacy laws, and each jurisdiction requires specific contractual language.

Why your vendor's DPA is a compliance document and a risk signal

Signing a contract with a software vendor is routine. But uploading recordings, sharing customer data, or connecting a meeting intelligence tool to your calendar carries different stakes.

From a legal standpoint, the moment personal data moves to a third-party processor, you are still on the hook for what happens to it.

That is the core principle behind DPA requirements: the data controller (the organization that determines the purpose and means of processing) remains liable for the processor's conduct.

In Europe

Under GDPR Article 28, that liability is structural. A well-drafted DPA documents that the relationship was properly governed. A poorly drafted DPA, or the absence of one, leaves that liability unallocated.

The enforcement numbers make this concrete. According to the DLA Piper GDPR Fines and Data Breach Survey (January 2026), cumulative GDPR fines since May 2018 have reached €7.1 billion, with approximately €1.2 billion issued in 2025 alone.

The same survey recorded a 22% year-on-year increase in breach notifications, from 363 to 443 per day, the first time average daily notifications have topped 400 since GDPR came into force.

In the United States

In the US, CCPA/CPRA penalties can reach $7,988 per intentional violation, per the CPPA's CPI-adjusted thresholds.

US organizations often assume DPAs are a European requirement. They are not.

CCPA/CPRA requires written service provider contracts that specifically prohibit selling the data, disclosing it further, or combining it with personal information the vendor has collected on its own

Colorado, Virginia, Connecticut, and other states with active privacy laws require similar agreements. The legal term differs; the substance is the same.

Before you ask anything: Understand what kind of processing relationship you're in

In a controller-processor relationship, you determine the purpose and means of processing and the vendor acts on your instructions. A standard DPA per GDPR Article 28 governs this. It’s the arrangement that applies to most SaaS tools.

On the other hand, in a controller-to-controller relationship, the vendor processes data for its own independent purposes. If a vendor is building products, running analytics, or training AI models on your data, it may be acting as a controller for those activities even when it simultaneously acts as a processor for others.

In that case, a standard processor DPA does not cover the vendor's controller activities. If the DPA does not distinguish between the two roles explicitly, the agreement has a structural weakness that no amount of negotiation on breach timelines or sub-processor lists will fix.

Before sending the questions below, confirm: what role is this vendor playing, and does the DPA reflect the actual relationship?

The questions to ask your vendor, and what a good answer looks like

These are criteria for evaluating whether a DPA is genuinely protective. A vendor's ability to answer them quickly and specifically indicates whether compliance infrastructure exists or was assembled retroactively.

1. Where is my data stored and processed?

Data residency determines which legal framework governs your data and whether international transfer mechanisms are required.

For EU and UK organizations, transferring data to a country without an adequacy decision requires Standard Contractual Clauses (SCCs) for EU transfers, or the UK International Data Transfer Agreement (UK IDTA) for transfers from the UK.

These are not interchangeable.

📌 A critical nuance: Server location and legal entity jurisdiction are two different things. A US-headquartered vendor with EU data centers is still subject to the US CLOUD Act, which can compel data production regardless of where the data physically sits.

Ask specifically whether the vendor's legal entity is incorporated within the EU or EEA, not just where the servers are.

For US vendors, verify whether the vendor participates in the EU-US Data Privacy Framework, upheld by the EU General Court in September 2025. A CJEU appeal (Case C-703/25 P) remains pending as of mid-2026, so organizations relying on the DPF should maintain SCCs as a parallel safeguard.

✅ Green flag: EU-incorporated entity with EU-only data centers, or a US vendor with active DPF certification and SCCs.

❌ Red flag: "Global infrastructure" with no jurisdiction specifics, or inability to confirm the legal entity's country of incorporation.

2. Who are your sub-processors, and how are they controlled?

Sub-processors are the third parties your vendor relies on to deliver its service.

Under GDPR Article 28, they must be subject to the same data protection obligations as the primary processor. Under CPRA, explicit flow-down requirements apply as well.

Ask whether the vendor maintains a current, publicly accessible sub-processor list; how and when customers are notified of new sub-processors; and how long customers have to object.

✅ Green flag: Public sub-processor list with a notification subscription and a 30-day objection window.

❌ Red flag: Blanket pre-approval of all current and future sub-processors with no notification obligation.

3. Will you use my data to train AI models?

Many AI vendors reserve the right to use customer data to improve their models. That right often does not appear in the DPA; it lives in the terms of service, under language as innocuous as "to improve our services."

The distinction is important: a privacy policy can change unilaterally. A DPA clause cannot. A product setting is not a contract.

Ask specifically whether the DPA includes an explicit contractual prohibition on using customer content (recordings, transcripts, summaries) to train, fine-tune, or improve AI models, and whether this prohibition is the default or requires a customer opt-out.

✅ Green flag: Explicit, binding contractual prohibition on AI training, with no carve-outs.

❌ Red flag: Training prohibition exists only as a product setting; no mention of AI training in the DPA at all.

4. What security certifications do you hold, and can you document them?

GDPR Article 32 requires processors to implement technical and organizational measures (TOMs) appropriate to the risk.

Broad DPA language like "commercially reasonable security practices" is not sufficient; the agreement should name specific controls.

Certifications are the fastest proxy. Request a current SOC 2 Type II report (not Type I, and not one older than 12 months). Confirm encryption standards are specified in the DPA (AES-256 in transit and at rest).

✅ Green flag: Current SOC 2 Type II report available under NDA; encryption standards named in the DPA.

❌ Red flag: Certifications mentioned in marketing but not documentable; only a SOC 2 Type I report available.

5. How quickly will you notify me of a data breach?

GDPR Article 33 requires controllers to notify supervisory authorities within 72 hours of becoming aware of a breach.

Since that clock starts when the controller learns of it, a slow processor eats directly into the controller's response window. UK GDPR mirrors this rule.

The DPA must specify a maximum notification window, not just describe notification as "prompt" or "without undue delay." Both phrases are legally meaningful but operationally vague.

✅ Green flag: DPA specifies notification no later than 72 hours from discovery, with a named escalation contact.

❌ Red flag: "Promptly" or "without undue delay" with no specific timeframe; breach defined narrowly in ways that exclude incidents you would that would matter to you.

6. What are my audit rights, and how do I exercise them?

GDPR Article 28 gives controllers the right to audit processors and access all information necessary to demonstrate compliance.

In practice, the right to request a current SOC 2 Type II report is the operative mechanism.

Ask whether the DPA explicitly accepts a third-party audit report as satisfying this obligation, specifies a notice period (30 days is standard), and extends any audit right to sub-processors.

✅ Green flag: SOC 2 Type II accepted as audit satisfaction; 30-day notice period specified; some mechanism for sub-processor compliance verification.

❌ Red flag: Vague audit right; a public webpage cited as satisfying the obligation; no sub-processor audit mechanism.

7. How and when will my data be deleted?

The DPA should specify a retention schedule, the events that trigger deletion, and whether the vendor provides written certification of deletion on termination.

Ask whether deletion covers all copies (including backups and sub-processor copies) and whether anonymized derivatives are retained after the relationship ends.

✅ Green flag: Defined retention schedule; deletion within 30 days of termination; written certification available; scope covers backups.

❌ Red flag: Retention governed by the vendor's privacy policy rather than the DPA; no deletion certification provided.

8. Which jurisdictions does your DPA cover?

A DPA written for GDPR compliance does not automatically satisfy UK GDPR obligations.

Post-Brexit, the UK operates a separate regime and the UK IDTA (not EU SCCs) is the required mechanism for international transfers from the UK.

For US organizations under CCPA, the DPA must explicitly prohibit the vendor from selling, retaining, or disclosing personal information for any purpose beyond the contracted service.

✅ Green flag: GDPR, UK GDPR, and CCPA/CPRA named explicitly; UK IDTA included for UK transfers; CCPA addendum with specific enumerated prohibitions.

❌ Red flag: "Applicable data protection laws" catch-all with no jurisdiction-specific mechanisms; no reference to the UK as a distinct jurisdiction.

The vendor DPA checklist at a glance

What to do when a vendor's DPA doesn't measure up?

A DPA that fails some of these criteria is not automatically a vendor you cannot work with; but it is a vendor you must negotiate with before signing.

Enterprise-tier DPA provisions are generally negotiable: sub-processor notification windows, deletion timelines, jurisdiction scope, and AI training prohibition language are all commonly modified.

If a vendor's standard contract has no DPA at all, request one explicitly during onboarding. US-based SaaS vendors often provide it as a separate data processing addendum on request.

A vendor who cannot produce one, or who treats the request as unusual, is signaling that compliance is not embedded in how they operate. That’s a material vendor risk, independent of their product quality.

What a compliant DPA looks like in practice

Audio and meeting intelligence tools present a sharper version of the DPA problem than most software categories.

Recordings contain speaker voices, meeting content, and conversation data: all personal data that warrants careful handling. The DPA governing that relationship needs to reflect the sensitivity of what is being processed.

📌 Here's what that looks like in practice for HappyScribe:

HappyScribe's data center sits within the European Union. It's a Tier IV facility, certified to PCI DSS and ISO 27001 standards. Servers are physically separated from other tenants.

The company holds SOC 2 Type II certification, with details available through its Trust Center. Role-based access control is available on all accounts. Employees sign NDAs as a condition of employment, limiting internal access to customer content.