Vendors and processors: do we need a DPA, a transfer tool, or both?
What GDPR expects for each vendor that touches EU personal data: an Article 28 processing agreement, a Chapter V transfer tool, or both, and how that paperwork actually gets signed in practice.
The short answer
For a processor in the US (or any other country without an EU adequacy decision): both. For a processor inside the EU/EEA: a data processing agreement only. And in practice, both jobs usually arrive in one packet the vendor already wrote, so the work is mostly diligence, not drafting.
| Where the processor sits | Processing agreement (Article 28)? | Transfer tool (Chapter V)? |
|---|---|---|
| EU/EEA | Yes | No: no transfer happens |
| Adequacy country (UK, Switzerland, Japan, others) | Yes | Yes, but adequacy is the tool; nothing to sign |
| US or other third country | Yes | Yes: the vendor’s DPF listing, or SCCs |
Processing and transfers are separate obligations
Every transfer is processing, but most processing is not a transfer. GDPR regulates all processing it covers, wherever it happens; the transfer rules in Chapter V add an extra requirement for one specific move, handing data to a different organization outside the EU/EEA. Walking a US retailer’s data flows makes the split concrete:
| What happens | Processing? | Restricted transfer? |
|---|---|---|
| EU customer submits data on your site | Yes | No: the customer is a data subject, not an exporter |
| You store and use that data in your own US systems | Yes | No: no second organization involved |
| You share it with a processor inside the EU | Yes | No: the receiver is inside the EU/EEA |
| You hand it to a US vendor (email, analytics, logistics, hosting) | Yes | Yes: both obligations apply to this hop |
The first two rows still carry the full GDPR program (notices, rights, security), just no transfer tool. See Is data entered on our site by an EU visitor a transfer? for why.
Why a third-country processor needs both
The two documents do different jobs, and one does not substitute for the other:
- The data processing agreement (DPA) is required by Article 28 for any processor handling data on your behalf, in the EU or anywhere else. It binds the vendor to process only on your instructions, keep the data secure, help with individual rights requests, and flow the same duties down to subprocessors.
- The transfer tool covers the border hop: the vendor’s Data Privacy Framework (DPF) listing, or standard contractual clauses (SCCs). See Choosing a GDPR transfer tool for picking between them.
A DPA alone covers the relationship but not the hop; a transfer tool alone covers the hop but not the Article 28 duties. If the US party is not your processor at all but an independent controller (a partner using the data for its own purposes), the DPA drops away, but the transfer still needs a tool, typically the controller-to-controller SCC module or the partner’s DPF listing.
How this shakes out in practice
The good news for small and mid-size companies: you rarely draft or negotiate any of this, because the market converged on vendors shipping the whole packet inside their standard terms.
- Major vendors bake it in. AWS is the canonical example: its service terms (section 1.14) automatically incorporate a DPA and the 2021 SCCs, which self-activate whenever GDPR applies to your use and data lands in a non-adequate country (background on AWS’s GDPR center). Google (Cloud Data Processing Addendum), Microsoft (Products and Services DPA), Stripe (DPA), and most SaaS vendors above a certain size do the same, and many also hold DPF certifications. Accepting their terms is the signature; the European Commission’s SCC questions and answers confirm SCCs can be executed by incorporation into a broader contract.
- A compliance page is not a contract. “We are GDPR compliant” on a vendor’s website satisfies nothing by itself. The DPA and SCCs must be part of the agreement you are actually on. Usually they are, via incorporation, but confirming that is the diligence step.
- There is no such thing as custom SCCs. The clause text is legally unmodifiable; only the annexes (parties, data categories, security measures) get filled in. That cuts negotiation both ways: large vendors will not discuss them because they do not need to, and small vendors will usually countersign a filled-in copy of the Commission’s template because there is nothing to review beyond the annexes.
- The real red flag is a vendor with no DPA and no privacy terms at all. The realistic options there are documented risk acceptance or switching vendors.
What to actually do
- Inventory which vendors receive personal data from people in the EU, UK, or Switzerland.
- For each, locate the DPA and confirm it is incorporated into the agreement you are on (terms of service version, order form, or signed copy). Note which SCC module applies.
- Check the DPF list for each US vendor and whether the listing covers the data types you send.
- Record the evidence in your vendor register or records of processing: DPA version and date, SCC module, DPF status.
What enforcement targets
Regulators have penalized the absence of any mechanism, not imperfect paperwork. The best-known case is the Dutch regulator’s 290 million euro fine against Uber, issued after Uber dropped SCCs on EU-to-US flows without a replacement tool in place (the fine is under appeal, but the shape of the risk is clear). A company relying on a vendor’s standard incorporated DPA and SCCs, with the trail recorded, is in a very different position from one with no mechanism at all.
Published August 12, 2026.