Guide

DPAs and Standard Contractual Clauses: How They Work Together for International Transfers

A DPA and Standard Contractual Clauses solve different problems and are both often needed for the same vendor relationship. Here's how they fit together when personal data leaves the EU.

Published August 16, 2026·Last updated August 16, 2026

It’s a common point of confusion: a signed DPA feels like it should cover a vendor relationship completely, but if that vendor processes EU personal data outside the EU/EEA, GDPR requires an additional layer, a valid international transfer mechanism, most commonly Standard Contractual Clauses (SCCs).

What each document actually does

  • The DPA governs the controller-processor relationship itself: what the vendor can do with the data, what security and confidentiality commitments apply, sub-processor terms, assistance obligations. It answers “what is this vendor allowed to do with our data.”
  • SCCs govern the specific problem of moving personal data to a country the EU hasn’t deemed to have “adequate” data protection, most notably including transfers to the US outside a specific adequacy mechanism. They answer “is it legal for this data to leave the EU/EEA at all.”

You can have a complete, well-drafted DPA with a vendor and still be non-compliant if that vendor processes the data in, say, a US data center, without a valid transfer mechanism layered on top.

How they’re typically packaged

Most established vendors bundle SCCs directly into their DPA, either as an attached module you accept alongside the main DPA, or a checkbox during the DPA acceptance flow that adds SCC terms for transfers outside the EU/EEA. If a vendor’s DPA doesn’t mention international transfers at all, and the vendor processes data outside the EU/EEA, that’s a real gap worth raising, not a minor omission.

What to check

  1. Does the vendor process or store data outside the EU/EEA? Check their infrastructure/data residency documentation, not just assume based on where the company is headquartered.
  2. If yes, does their DPA include SCCs or reference another valid transfer mechanism? The EU-US Data Privacy Framework is one alternative for transfers to US companies that have self-certified under it, worth checking specifically rather than assuming SCCs are the only option.
  3. Do the SCCs cover the actual transfer scenario? SCCs come in different modules (controller-to-processor, processor-to-processor, etc.), the version attached should match your actual relationship with the vendor.
  4. Is there a data residency option if international transfer is a dealbreaker? Some vendors, particularly larger EU-headquartered ones, offer EU-only data residency as a paid or default option, worth asking about if minimizing transfer risk matters for your specific business.
Our recommendation

CookieYes

If your visitor base is EU-heavy, ask any vendor in your stack, including your consent platform, where the data actually lives and what transfer mechanism applies if it leaves the EU. CookieYes documents this as part of its standard DPA and data processing terms.

Try CookieYes

Why this got more complicated, not less

The 2020 Schrems II decision invalidated the previous EU-US transfer framework (Privacy Shield) and raised the bar for what SCCs alone can guarantee, adding an expectation of “supplementary measures” in some cases. The current EU-US Data Privacy Framework addresses some of this for certified US companies, but the underlying principle holds: a DPA alone was never enough for a cross-border relationship, and treating it as sufficient is one of the more consequential gaps we see in vendor due diligence.

The bottom line

Think of the DPA and SCCs as answering two different questions that both need a “yes”: is the vendor’s use of the data properly governed, and is it legal for the data to be where it’s being processed. A DPA alone answers the first question, not the second.

This guide is educational and not legal advice. For your specific vendor relationships and data transfer arrangements, consult a privacy attorney.