DPA & GDPR: what is a data processing agreement and when does your startup need one?
You use HubSpot, Brevo, Stripe, Google Workspace, Notion and five more tools. All of them process data belonging to your customers or employees. Do you have a signed agreement with each one? If the answer is no — or you're not sure — you've been non-compliant with the GDPR from day one. This article explains what a DPA is, when you need one, what it must include, and the most common mistakes startups make.
Key takeaways
- Any external vendor processing personal data on your behalf is a Data Processor. You need a DPA with them, mandatory under Art. 28 GDPR.
- Most SaaS tools offer their own DPA — but you need to activate or sign it, and verify it's compliant.
- US-based SaaS tools add another layer: international data transfers. "They have servers in Ireland" is not always enough.
- Missing DPAs can lead to fines of up to €10 million or 2% of global annual turnover (Art. 83.4 GDPR).
Do I need a DPA with my vendor? Quick reference
| Situation | Is a data processing agreement required? |
|---|---|
| Web hosting (AWS, Google Cloud, Hetzner…) | Usually yes |
| CRM with customer data (HubSpot, Salesforce…) | Yes |
| Email marketing platform (Brevo, Mailchimp…) | Yes |
| Stripe or other payment gateway | Depends on the role the provider assumes |
| Google Analytics / Meta Ads | Check configuration and provider's role |
| Notary, bank or external advisor acting autonomously | Usually not acting as a processor |
What is a DPA and why does GDPR require it?
The GDPR (Regulation (EU) 2016/679) establishes in Article 28 that when an organisation — the Data Controller — engages a third party to process personal data on its behalf, it must enter into a binding contract with that third party: the Data Processing Agreement (DPA).
This is not bureaucratic paperwork. It's the mechanism ensuring your vendor processes your users' data according to your instructions — not their own — and assumes the responsibilities and security measures GDPR requires.
Practical example: Your startup uses Brevo to send onboarding emails to users. Brevo accesses those users' names and emails to deliver the emails. You decide what data is sent and for what purpose: you're the Controller. Brevo executes the processing following your instructions: they're the Processor. Without a signed DPA, that relationship has no legal cover under GDPR.
Controller vs Processor: the distinction that changes everything
| Data Controller (Art. 4(7) GDPR) | Data Processor (Art. 4(8) GDPR) | |
|---|---|---|
| Who? | Your company (the startup) | The SaaS vendor (HubSpot, Stripe, Notion…) |
| What do they decide? | Purpose and means of processing | How to technically execute it, per your instructions |
| Who is accountable to users? | You, primarily | Also, directly to the supervisory authority (Art. 82 GDPR) |
| Contract needed? | Yes: the DPA (Art. 28 GDPR) | Yes: the same DPA |
The 8 clauses every DPA must include (Art. 28.3 GDPR)
Processing only on documented instructions — The processor may only process data for the purposes you define (Art. 28.3.a).
Confidentiality of personnel — Authorised persons must be bound by confidentiality obligations (Art. 28.3.b).
Security measures (Art. 32 GDPR) — Encryption, pseudonymisation, resilience, and other appropriate technical and organisational measures (Art. 28.3.c).
Sub-processors require prior authorisation — General or specific prior consent is needed before onboarding sub-processors (Art. 28.3.d and 28.4).
Assistance with data subject rights — Help responding to access, erasure, portability, and other requests (Art. 28.3.e).
Assistance with security obligations — Including breach notifications and DPIAs where applicable (Art. 28.3.f).
Return or deletion of data at termination — At the end of the relationship, data must be returned or securely deleted (Art. 28.3.g).
Audit rights — You must be able to audit compliance, directly or via an authorised auditor. Certifications (ISO 27001, SOC 2) are acceptable substitutes if agreed in the DPA (Art. 28.3.h).
International transfers: the US SaaS risk
Most SaaS tools popular with startups are US companies: Google, Microsoft, Slack, Notion, Stripe, HubSpot, Intercom, Zoom, AWS. When your European users' data travels to US servers (or can be accessed from there), it's an international data transfer subject to Arts. 44-49 GDPR. Not every transfer automatically requires SCCs — the correct order to check is:
- Check whether an adequacy decision exists for the destination country (Art. 45 GDPR). The European Commission has recognised countries such as Switzerland, Japan, Canada and the UK as adequate. No general adequacy decision exists for the US.
- EU-US Data Privacy Framework (DPF) — Decision (EU) 2023/1795: if the US vendor is DPF-certified, transfers are lawful without additional SCCs. Note: the DPF's validity remains subject to political and judicial scrutiny — monitor its evolution.
- Standard Contractual Clauses (SCCs) — Decision (EU) 2021/914: when the above mechanisms don't apply, SCCs are the most common tool. Must be accompanied by a Transfer Impact Assessment (TIA) assessing whether the destination country's law adequately protects the data.
Why "servers in Ireland" isn't always enough: Data stored in Europe can still be remotely accessed by staff of a US parent company. US FISA 702 and other surveillance laws allow the US government to require access to data controlled by any company under US jurisdiction, regardless of server location. This is why SCCs must be accompanied by a TIA addressing this specific risk.
Frequently asked questions about DPA & GDPR
Do I need a DPA even if I only have 10 customers?
Yes. GDPR does not set volume thresholds for Art. 28 obligations. From the moment a third party processes personal data on your behalf — even for a handful of users — you need a DPA. Micro-enterprises have some exemptions (e.g., the Art. 30.5 records exemption) but not from the DPA requirement.
What is the difference between a DPA and Standard Contractual Clauses (SCCs)?
They are distinct instruments, though often confused. The DPA governs the Controller-Processor relationship under GDPR (Art. 28). SCCs are the mechanism for legalising the international transfer of that data to a country without an adequacy decision (Art. 46.2.c GDPR). Many DPAs with US providers integrate both: the DPA includes the SCCs as an annex or module.
Can I use the provider's standard DPA or do I need to negotiate a custom one?
It depends on your negotiating position and the vendor's profile. For large SaaS providers (Google, Microsoft, HubSpot, Stripe), the standard DPA is legally valid and practically non-negotiable — you configure your settings via the admin panel, not through contract negotiation. For smaller vendors or particularly sensitive processing (health data, financial data, children's data), it is advisable to negotiate a custom DPA that better covers your specific exposure.
What if my vendor refuses to sign a DPA?
If a vendor refuses to sign a DPA or doesn't offer one, you should not use that service to process your users' personal data. Using a vendor without a DPA is a breach of Art. 28 GDPR for which you, as the Controller, are responsible. In practice, any serious software vendor today has a DPA available. If they don't, it's a red flag about their compliance maturity.
How often should I review my DPAs?
At least annually, and whenever: (1) you add a new vendor to your stack, (2) an existing vendor changes their terms or sub-processor list, (3) the applicable regulation changes (as happened with Privacy Shield invalidation in 2020 or the EU-US DPF adoption in 2023), or (4) you introduce new data categories or processing purposes.
Is your website's privacy policy up to date?
Just as important as your DPAs is what you tell your users in your privacy policy. Both documents must be consistent: if you use Google Analytics and don't mention it in your privacy policy, you have a double compliance gap. We explain what each legal text must include in our article on mandatory legal texts for your website.
If you need us to audit your GDPR compliance or draft DPAs with your vendors, see our GDPR advisory for startups.