What Is a DPA? GDPR DPA vs Standard Contractual Clauses for Data Protection
A DPA is the contract that tells a service provider how to handle personal data for you. Under GDPR, this usually means a Data Processing Agreement. It is not the same thing as Standard Contractual Clauses, or SCCs. A DPA controls the working relationship. SCCs help protect data when it moves outside the EU or EEA.
TLDR: Use a DPA when a vendor processes personal data for your business, such as names, emails, or user IDs. Use SCCs when that data is sent to a country without an EU adequacy decision, such as many transfers to the United States. Example: if your EU shop sends 12,000 customer emails to a US email platform each month, you likely need both a DPA and SCCs. One covers the job; the other covers the border crossing.
What does DPA mean?
DPA can mean two annoying things.
- Data Processing Agreement: a contract between a data controller and a data processor.
- Data Protection Authority: the government regulator that enforces privacy law.
In this article, we mean Data Processing Agreement.
Think of a DPA as the rulebook for a vendor. You hire a company to do something with personal data. Maybe it stores customer records. Maybe it sends marketing emails. Maybe it hosts your help desk. The DPA says what the vendor can and cannot do.
It is the privacy version of: “Here are the keys. Do not throw a party.”
Who signs a GDPR DPA?
A GDPR DPA is usually signed by two parties.
- Controller: the company that decides why and how personal data is used.
- Processor: the company that handles data for the controller.
Example time.
You run an online store. You decide to collect customer names, addresses, and emails. You are the controller.
You use a cloud CRM to store customer profiles. The CRM follows your instructions. It is the processor.
That means you need a DPA with the CRM vendor.
Honestly, it feels like every SaaS tool now has a “privacy paperwork” page hidden three clicks too deep. Still, get the DPA. It matters when someone asks where the data went.
What must a GDPR DPA include?
GDPR Article 28 gives the shopping list. The DPA must cover key points.
- What data is processed, such as emails, IP addresses, or order history.
- Why it is processed, such as hosting, analytics, billing, or support.
- How long it is processed.
- What security measures exist, such as encryption and access controls.
- Rules for sub processors, like cloud hosts or support tools.
- Help with data subject rights, such as deletion or access requests.
- Breach notice duties.
- Return or deletion of data when the service ends.
A good DPA is plain and clear. A bad one reads like a haunted printer wrote it at 2 a.m.
What are Standard Contractual Clauses?
Standard Contractual Clauses are legal terms approved by the European Commission. People call them SCCs because privacy law loves acronyms.
SCCs are used for international data transfers. They are most common when personal data leaves the EU or EEA and goes to a country without an EU adequacy decision.
They do not replace a DPA. They do a different job.
A DPA says: “Vendor, process this data only as instructed.”
SCCs say: “If this data crosses a border, keep GDPR-style protections attached to it.”
GDPR DPA vs SCCs: the simple difference
Here is the clean split.
| Item | GDPR DPA | SCCs |
|---|---|---|
| Main purpose | Controls how a processor handles personal data. | Protects personal data during certain international transfers. |
| Used when | You hire a vendor to process personal data. | Data moves outside the EU or EEA to some countries. |
| Based on | GDPR Article 28. | EU Commission approved clauses. |
| Can you edit it? | Yes, within GDPR rules. | Not much. The core text should stay intact. |
| Replaces the other? | No. | No. |
Do you need both?
Often, yes.
Say your Berlin startup uses a customer support platform based in California. You send customer names, emails, support tickets, and account IDs to that platform.
You need a DPA because the support platform processes data for you.
You may also need SCCs because the data goes from the EU to the US.
The catch is that signing SCCs is not always the end of the work. You may also need a transfer impact assessment. That means you check whether the data will stay protected in the destination country.
Yes, that sounds like homework. Because it is.
A quick coffee shop example
Imagine a small coffee chain in France.
It runs a loyalty app with 40,000 customers. It uses three tools:
- A French payment provider.
- A German hosting company.
- A US email marketing service.
The payment provider and host process personal data. So the coffee chain needs DPAs with them.
The US email service also processes personal data. So it needs a DPA too.
Since customer emails go to the US, the coffee chain likely needs SCCs with that email service as well.
Same data. Different legal jobs. Not fun, but manageable.
What should you check before signing?
Do not just click “accept” and hope. That plan ages badly.
Check these items first:
- Roles: Are you the controller? Is the vendor the processor?
- Data types: Does the contract name the right data?
- Purpose: Can the vendor use data only to provide the service?
- Security: Are controls listed clearly?
- Sub processors: Can you see who else gets the data?
- Breach timing: How fast must the vendor inform you?
- Deletion: What happens when you leave?
- Transfers: Does data leave the EU or EEA?
- SCCs: Are they included when needed?
Watch for fluffy phrases like “industry standard security.” That can mean a lot. Or very little. Ask for details. Encryption? Backups? Access logs? Staff training? Real answers beat shiny words.
Common mistakes
These mistakes show up a lot.
- Thinking a privacy policy is a DPA. It is not. A privacy policy talks to users. A DPA binds vendors.
- Using SCCs instead of a DPA. Wrong tool. Wrong drawer.
- Forgetting sub processors. Your vendor may use five other vendors.
- Ignoring transfers. Cloud tools can move data across regions.
- Signing old SCCs. Use the current EU version.
So, what should you do first?
Start with a data map. Keep it simple.
- List every vendor that touches personal data.
- Mark what data each vendor gets.
- Mark where the vendor stores or accesses it.
- Get a DPA for each processor.
- Add SCCs where transfers require them.
This does not need to be fancy. A spreadsheet works. If it takes 20 seconds to figure out where your help desk stores tickets, great. If it takes three days and four support emails, that vendor deserves extra scrutiny.
Bottom line: a GDPR DPA manages the vendor relationship. SCCs manage certain cross-border transfers. You may need one. You may need both. The smart move is to check the role, the data, and the destination before anyone touches personal information.
