You're a Processor. Now What?
If you run a B2B SaaS product — a CRM, analytics platform, HR tool, customer support software, payment processor, or practically any business software — you are almost certainly a data processor under GDPR Article 4(8). Your customers are the data controllers; you process personal data on their behalf.
This triggers Article 28, which sets out mandatory requirements for how processors must operate. These aren't suggestions — they're legally required terms that must appear in every controller-processor relationship, either in a standalone Data Processing Agreement (DPA) or in relevant contractual provisions.
The Controller-Processor Distinction
| Role | Definition | Typical SaaS Example | Key Obligations |
|---|---|---|---|
| Controller | Determines the purposes and means of processing | Your customer (the company using your SaaS) | Legal basis, transparency, data subject rights, DPIA |
| Processor | Processes personal data on behalf of the controller | You (the SaaS provider) | Art. 28 DPA, act only on instructions, sub-processor rules, breach notification |
| Sub-processor | Processor engaged by the processor | Your infrastructure providers (AWS, Sentry, OpenAI) | Same Art. 28 obligations as if you were the controller |
Note: you may also be a controller for some personal data you process — for example, employee data, prospective customer data in your CRM, or analytics data you collect for your own purposes (product improvement, A/B testing). For that data, Art. 28 doesn't apply — but you need your own legal basis under Art. 6.
Article 28(3): The Mandatory DPA Terms
Every controller-processor relationship must be covered by a binding contract (the DPA) that includes, at minimum, all of the following (Art. 28(3)(a)–(h)):
- (a) Process only on documented instructions — You can only process personal data when and how your customer instructs you to. You can't use their customers' data for your own purposes (training AI models, analytics, benchmarking) without their instruction — unless you obtain a separate legal basis.
- (b) Confidentiality of authorised personnel — Staff who access personal data must be bound by confidentiality (employment contract, NDA, or statutory obligation).
- (c) Implement appropriate technical and organisational measures — The TOMs required by Art. 32 (encryption, access controls, pseudonymisation, testing) must be agreed in the DPA. Annex II of the DPA typically lists these.
- (d) Sub-processor obligations — You must obtain prior written authorisation (general or specific) from the controller before engaging sub-processors. Your sub-processors must be subject to the same Art. 28 obligations. You remain fully liable to your customer for sub-processor failures. (More on this below.)
- (e) Assist the controller with data subject rights — When your customer's end-users exercise their rights (access, erasure, portability), you must help the controller respond. This typically means building admin APIs or support processes to export or delete specific user data on request.
- (f) Assist the controller with Art. 32–36 obligations — Help with security measures, DPIA, breach notification, and consultation with supervisory authorities. In practice: notify the controller of breaches within timeframes in your DPA (typically 24–72 hours); assist with DPIAs if your processing is high-risk.
- (g) Delete or return data on termination — When the contract ends, you must delete or return all personal data. Give your customers a clear offboarding procedure — data export, then deletion within a defined timeframe.
- (h) Audit cooperation — You must allow the controller (or its mandated auditor) to conduct audits and inspections. In practice: most SaaS companies satisfy this with a SOC 2 Type 2 report, ISO 27001 certificate, or a questionnaire-based assessment — rather than on-site inspections. Build this into your DPA language.
Sub-processors: The Most Commonly Missed Obligation
Article 28(2) and 28(4) require:
- You must get prior written authorisation from your customer before adding sub-processors (Art. 28(2))
- Sub-processor contracts must impose the same data protection obligations as in the controller-processor DPA (Art. 28(4))
- You remain fully liable to your customer if a sub-processor fails to meet its obligations
Two models for sub-processor authorisation:
- General authorisation: Your DPA authorises a list of sub-processors and gives the controller a right to object to additions. You notify customers of new sub-processors in advance (typically 14–30 days) and let them object before the change takes effect.
- Specific authorisation: Each sub-processor must be individually approved by the customer. This is operationally burdensome and unusual for SaaS.
The practical solution: publish a public sub-processor list, link to it in your DPA, and use the general authorisation model with a change notification mechanism (email list or changelog page).
Which vendors are your sub-processors? Any service that processes personal data on your behalf — not just infrastructure. This includes:
- Cloud infrastructure (AWS, GCP, Azure) — yes, these are sub-processors for customer data stored on them
- Error tracking (Sentry, Datadog) — if error payloads contain personal data (email addresses, user IDs)
- Customer support (Intercom, Zendesk) — processes your customers' end-user data
- Email delivery (SendGrid, Postmark) — processes email addresses
- AI providers (OpenAI, Anthropic) — if you send personal data to their APIs
- Analytics (Mixpanel, Segment) — if they receive personal data
If a vendor only processes data about you (not about your customers' end-users) — like your CRM, accounting software, or HR system — they're not a sub-processor for Art. 28 purposes. They're a controller or processor in your own data supply chain.
Article 28(3)(c): Technical and Organisational Measures (TOMs)
TOMs are the security controls you commit to in your DPA. They should be specific, not generic boilerplate. A strong TOMs annex covers:
| Category | Specific Measures |
|---|---|
| Encryption | AES-256 at rest, TLS 1.2+ in transit, key management process |
| Access controls | RBAC, least privilege, MFA on all admin access, quarterly access reviews |
| Pseudonymisation | User data stored with internal IDs; email/name not in logs |
| Availability | Uptime SLA, backup frequency, recovery time objective (RTO) |
| Testing | Annual penetration test, continuous vulnerability scanning |
| Personnel | Background checks, GDPR training, confidentiality agreements |
| Incident response | IRP with <24h internal escalation, 24–72h breach notification to controller |
Breach Notification Under Art. 28(f)
As a processor, your breach notification obligation runs to your controller (customer), not to the supervisory authority. The controller notifies the DPA within 72 hours. Your job is to notify your customer in time for them to meet their 72-hour obligation.
Best practice: commit to notifying customers within 24–48 hours of becoming aware of a personal data breach. Your DPA and Incident Response Plan should both specify this timeline.
Generate Your GDPR DPA
The ComplyKit GDPR Data Processing Agreement Generator creates a complete Art. 28 DPA including all mandatory provisions: processor obligations (a)–(h), Annex I (subject matter, purposes, data types, data subjects), Annex II (TOMs), and Annex III (sub-processor table).
Other tools you'll need:
- Sub-Processor List Generator — public list with 40+ pre-loaded vendors, transfer mechanisms, and DPA links
- Information Security Policy — documents your TOMs internally
- Incident Response Plan — includes GDPR 72-hour breach notification procedures
- Privacy Policy — if you're also a controller for your own data
⚠️ This guide is for informational purposes and does not constitute legal advice. GDPR compliance should be reviewed by qualified data protection legal counsel for your specific business context.