Article 28 is the GDPR provision that governs the relationship between a data controller and a data processor. For a SaaS founder, this means two things: you need a signed Article 28 agreement (a Data Processing Agreement, or DPA) with every customer whose users' data you process, and you need one with every vendor who processes your customers' data on your behalf.
Missing DPAs is one of the most common GDPR failures in early-stage SaaS companies — and one of the first things enterprise procurement teams check.
What Article 28 Requires
Article 28 sets out binding requirements for contracts between controllers and processors. The contract must specify:
| Requirement | What it means |
|---|---|
| Subject matter and duration | What data is being processed and for how long |
| Nature and purpose | What the processor is doing with the data |
| Type of personal data | Categories of data being processed |
| Categories of data subjects | Who the data is about |
| Controller's obligations and rights | What instructions the processor must follow |
And the contract must stipulate that the processor will:
- Process data only on documented instructions from the controller
- Ensure that people authorised to process the data are bound by confidentiality
- Implement appropriate technical and organisational security measures (Article 32)
- Respect conditions for engaging sub-processors (see below)
- Assist the controller in complying with data subject rights
- Assist the controller with security obligations, breach notification, DPIAs, and prior consultation
- Delete or return all personal data at the end of the contract
- Provide all information necessary to demonstrate compliance
- Allow and contribute to audits by the controller or their appointed auditor
Who Needs a DPA
Your customers need a DPA with you
If your SaaS product processes personal data on behalf of your customers — their users' names, emails, behaviour data, files, messages — you are acting as a processor for each customer. Every customer relationship where personal data is processed needs a DPA.
This is standard in enterprise sales. If a customer's legal team asks "can you share your DPA?" and you don't have one, the deal stalls.
You need DPAs with your sub-processors
A sub-processor is any third party you engage to help you process your customers' data. Common examples:
| Vendor type | Example | Do they sub-process customer data? |
|---|---|---|
| Cloud infrastructure | AWS, GCP, Azure | Yes — they store the data |
| Email delivery | Postmark, SendGrid | Yes — if sending emails about customer user data |
| Analytics | Mixpanel, Amplitude | Yes — if ingesting customer user events |
| Support | Intercom, Zendesk | Yes — if customer conversations include user data |
| Error tracking | Sentry, Datadog | Yes — if error logs contain personal data |
| Payment | Stripe | Mostly controller-to-controller — they have their own obligations |
Article 28(2) requires that your sub-processors are bound by DPA terms that mirror your obligations to your customers. AWS, GCP, Stripe, and most major vendors provide standard DPAs available in their settings or legal portals. Download and execute them.
Sub-Processor Notification
Your DPA with customers must address sub-processors. You have two options:
Specific authorisation: List each sub-processor by name, and require customer approval before adding new ones.
General authorisation: Customers agree to your sub-processor use generally, but you must notify them of any new sub-processor with enough time for them to object.
Most SaaS companies use general authorisation with a 30-day advance notice period. Maintain a public sub-processor list (typically a webpage or DPA appendix) that you update when sub-processors change.
What a DPA Must Include: Template Structure
A compliant Article 28 DPA typically contains:
Section 1 — Definitions Define "controller," "processor," "personal data," "processing," "data subjects" consistently with GDPR.
Section 2 — Subject Matter Describe what the processor is doing: the nature of the SaaS service and the processing it involves.
Section 3 — Duration The processing lasts as long as the main service agreement, and data is deleted or returned within a specified period after termination.
Section 4 — Nature and Purpose What the processing achieves — e.g., hosting user accounts, storing documents, processing transactions.
Section 5 — Type of Data and Data Subjects Specify categories of data (names, emails, usage logs, etc.) and who the data subjects are (the controller's customers or employees).
Section 6 — Processor Obligations Enumerate the Article 28(3) obligations: instructions only, confidentiality, security, sub-processors, data subject rights assistance, breach assistance, deletion/return, audit rights.
Section 7 — Sub-processors List current sub-processors as an annex. Specify the notification procedure for new sub-processors.
Section 8 — International Transfers If data is transferred outside the EU/EEA, specify the transfer mechanism (Standard Contractual Clauses as a further annex).
Section 9 — Security Measures Annex specifying the technical and organisational measures (TOMs) the processor has in place.
Section 10 — Audit Rights How the controller can audit the processor's compliance — this is often satisfied by third-party certifications (ISO 27001, SOC 2) plus the right to request information.
Common DPA Mistakes
Using a DPA template you don't understand Many startups copy a DPA template without reading it. If your DPA commits you to obligations you cannot meet — 72-hour breach notification to the customer, unlimited liability, restrictive sub-processor lists — you have a problem.
Forgetting sub-processor DPAs Telling customers "we only share data with sub-processors bound by equivalent terms" only works if you've actually signed those DPAs. Most major vendors provide them online — get them executed and filed.
Not updating your sub-processor list Every time you add a new tool that touches customer data, your sub-processor list needs updating and customers need to be notified according to your DPA terms.
Not signing your own DPA Your DPA should be signed by an authorised signatory. An unsigned DPA sitting on a webpage is not a binding contract.
DPA in Enterprise Sales
Enterprise customers increasingly scrutinise DPAs during procurement. Common requests include:
- Audit rights that go beyond "request information" — some enterprises want the right to conduct on-site audits
- Data residency requirements — processing only within the EU/EEA or specific countries
- Breach notification timelines shorter than GDPR's 72-hour minimum — often 24 hours or "immediately"
- Specific sub-processor approval rights, not just general authorisation
- Unlimited liability for personal data breaches — which is a commercial negotiation, not a GDPR requirement
Know which of these you can accept and which you cannot before they come up in a deal.