GDPR Data Processing Agreement (DPA) Guide: Article 28 Requirements (2025)
Every SaaS company with EU customers must execute a Data Processing Agreement under Article 28 GDPR before processing EU personal data on the customer's behalf. Missing or deficient DPAs are among the most common GDPR violations discovered in supervisory authority investigations — and among the most common blockers in EU enterprise sales cycles. This guide covers the 12 mandatory DPA terms, sub-processor chain management, SCC integration, and what enterprise customers will actually push back on.
Controller vs. Processor: Getting the GDPR Roles Right
The most consequential determination in any GDPR compliance analysis is whether your company is a controller or a processor for a given processing activity — because it determines your obligations, your liability exposure, and what agreements you need.
| Role | Definition | Typical SaaS example | Max fine |
|---|---|---|---|
| Controller | Determines purposes and means of processing | Your customer using your SaaS for their CRM | €20M / 4% global turnover |
| Processor | Processes data on behalf of and under instruction of a controller | Your SaaS product storing/analyzing customer's user data | €10M / 2% global turnover |
| Joint Controller | Two+ entities jointly determine purposes and means | API integration where both companies decide how data is used | €20M / 4% global turnover |
| Sub-processor | Processor engaged by another processor | AWS storing data for your SaaS product | €10M / 2% global turnover |
Many SaaS companies are simultaneously controllers (for their own employee and marketing data) and processors (for their customers' data). Each role requires different agreements, different compliance programs, and different responses to data subject requests. A company in the processor role cannot use its customers' data for its own purposes (analytics, product improvement, training AI models) without becoming a joint controller — which requires an additional agreement under Article 26 GDPR.
The Standard DPA Structure: What Goes in Each Section
A standard GDPR-compliant DPA typically has the following structure:
- Definitions: Align terms with GDPR Article 4 (personal data, processing, controller, processor, data subject, supervisory authority, etc.).
- Scope and instructions: Processor processes only on documented controller instructions. Instructions can be delivered via the services agreement or subsequent written communications. Emergency deviation protocol for legal obligations.
- Data security (Article 32): Technical and organizational measures — typically in Annex II. Reference to specific encryption standards, access control frameworks, vulnerability management, and incident response procedures.
- Sub-processors (Article 28(2)): Authorization model (specific vs. general), sub-processor list URL, notification period, objection rights, and imposition of GDPR-equivalent obligations.
- Data subject rights: Processor assists controller in responding to Article 15-22 requests (access, erasure, rectification, restriction, portability, objection, no automated decision-making).
- Breach notification: Processor notifies controller within X hours of becoming aware of a personal data breach, with content of notice specified (nature, categories, approximate numbers of data subjects and records, consequences, mitigation measures).
- DPIAs and prior consultation: Processor assists controller with data protection impact assessments (Article 35) and prior consultation (Article 36) for high-risk processing.
- Deletion or return: Timeline, format, scope (including backups), and written certification.
- Audit rights: Frequency, notice requirements, scope limitations, cost allocation, and alternative compliance certification mechanism (SOC 2, ISO 27001).
- International transfers (Chapter V): SCCs incorporated as schedule, applicable modules identified, Annex I (parties and processing description) and Annex II (security measures) completed.
Contract Risk — $97
Review Your DPA for Missing Article 28 Terms in 60 Seconds
DPAs signed with customers and with sub-processors frequently omit mandatory Article 28 terms, contain incomplete SCC modules, or use vague Annex II security descriptions that fail supervisory authority scrutiny. BizLegal AI scans your Data Processing Agreement for missing mandatory terms, incomplete SCC schedules, insufficient sub-processor provisions, and security measure annexes that don't meet EDPB adequacy standards.
Scan Your Data Processing Agreement →Frequently Asked Questions
When is a Data Processing Agreement legally required under GDPR?
Article 28 GDPR requires a written contract (a Data Processing Agreement, or DPA) whenever a controller engages a processor to process personal data on its behalf. A "processor" is any entity that processes personal data on behalf of a controller — where the controller determines the purposes and means of processing, and the processor acts only on the controller's instructions. In SaaS, the typical structure is: your customer (a business with EU customers or employees) is the controller, and your SaaS product is the processor. Your SaaS product handles personal data (customer records, employee data, user behavior) on behalf of your customer. A DPA is required. If you refuse to sign a DPA with EU enterprise customers, they cannot lawfully use your product under GDPR. This is why enterprise sales cycles in EU markets require DPA negotiation as a precondition to contract signing. The controller-processor distinction also matters for GDPR fines: controllers bear primary liability for GDPR violations, but processors can face direct enforcement for failing to implement appropriate technical and organizational measures, or for acting outside the controller's instructions. The GDPR's most common SaaS misconception is that a processor is not liable — processors face up to €10M or 2% of global annual turnover per violation under Article 83(4), and up to €20M or 4% for systematic violations.
What are the 12 mandatory terms that every GDPR DPA must include?
Article 28(3) GDPR specifies that a DPA must contain at minimum the following terms, and supervisory authority guidance (including the European Data Protection Board) has further elaborated on their substance: (1) Subject-matter and duration: What personal data is processed, for what purpose, and for how long. Duration must be bounded — indefinite processing is not permitted. (2) Nature and purpose of processing: The specific processing activities (collection, storage, analysis, transmission) and the business purpose they serve. (3) Type of personal data: Categories of data processed (contact details, financial data, health data, behavioral data, etc.). Special categories (health, biometric, racial, etc.) require explicit identification and additional safeguards. (4) Categories of data subjects: Who the personal data relates to (your customer's end users, employees, leads, etc.). (5) Obligations and rights of the controller: The DPA must set out the controller's right to issue instructions and the processor's obligation to act only on those instructions. (6) Confidentiality: Processor must ensure that all personnel with access to personal data are subject to binding confidentiality obligations. (7) Security measures (Article 32): Processor must implement appropriate technical and organizational measures — typically described by reference to encryption, access controls, incident response procedures, and security testing. The DPA should specify or reference an Annex listing these measures. (8) Sub-processors: Processor must obtain prior written authorization from the controller before engaging sub-processors, and must impose GDPR-equivalent obligations on all sub-processors. (9) Data subject rights: Processor must assist the controller in fulfilling data subject requests (access, erasure, rectification, portability). (10) Deletion or return on termination: At the end of the processing relationship, the processor must delete or return all personal data, including copies. (11) Audits: Processor must allow for and contribute to audits and inspections, including by the controller or a third-party auditor. (12) Prior consultation: Processor must assist the controller with prior consultation obligations to supervisory authorities for high-risk processing (Article 36).
How should a SaaS DPA handle sub-processors?
Article 28(2) GDPR requires processors to obtain prior written authorization from the controller before engaging sub-processors — entities to whom the processor delegates some or all of its processing. For SaaS companies, sub-processors include cloud infrastructure providers (AWS, GCP, Azure), databases, analytics platforms, email delivery services, CDNs, monitoring tools, and any other service that processes personal data as part of delivering the SaaS product. There are two authorization models used in practice: (1) Specific authorization: The DPA lists every sub-processor by name and requires the controller to consent to each one before the processor can engage them. This is burdensome for SaaS companies with many sub-processors (common for large enterprise customers to demand this). (2) General authorization: The DPA authorizes a class of sub-processors and requires the processor to notify the controller before engaging new sub-processors, with a right for the controller to object. This is the model used by most SaaS companies (including AWS, Google Workspace, and Salesforce in their standard DPAs). The processor must maintain a current list of sub-processors and make it available to controllers. Under Article 28(4), the processor must impose GDPR-equivalent obligations on all sub-processors via written contracts — the processor remains fully liable to the controller for sub-processor GDPR violations. Standard approach in SaaS DPAs: include a publicly accessible sub-processor page (URL), commit to X days' notice before adding sub-processors, and grant controllers a right to object within X days. If the controller objects and the processor cannot reasonably avoid using that sub-processor, either party may terminate the portion of the service affected.
How do Standard Contractual Clauses (SCCs) interact with DPAs for international transfers?
When EU personal data is transferred to a third country without an adequacy decision from the European Commission (most transfers to the US, India, and elsewhere outside the EU/EEA/adequacy-listed countries), a transfer mechanism must be in place under Chapter V GDPR. The EU Standard Contractual Clauses (SCCs) are the most widely used mechanism. Critically, SCCs are not a standalone DPA — they are an addendum to the DPA, or the DPA may incorporate SCCs directly. The 2021 EU SCCs (effective since June 2021, mandatory since December 2022) replaced the prior 2001/2004/2010 SCCs. The new SCCs include four modules: Module 1 (Controller-to-Controller), Module 2 (Controller-to-Processor), Module 3 (Processor-to-Controller), Module 4 (Processor-to-Processor). For a standard SaaS arrangement: your customer (EU controller) transferring data to your SaaS (non-EU processor) requires Module 2 SCCs. Your SaaS engaging a non-EU sub-processor (e.g., an AWS region outside the EEA) requires Module 3 SCCs. Practical integration: SaaS DPAs typically include SCCs as Annex III or Schedule C, with the applicable module and optional clauses selected. Annex I specifies the parties, the data transferred, and the processing purposes. Annex II specifies technical and organizational security measures. The SCCs must be executed by the actual legal entities involved — "covering" international transfers at a group level without executed SCCs for each entity is a common compliance error flagged in supervisory authority enforcement.
What DPA terms do enterprise customers typically push back on?
Enterprise legal teams negotiating SaaS DPAs commonly push back on the following standard processor-favorable provisions: (1) Sub-processor notification period: Processors typically offer 10-30 days' notice before adding sub-processors. Enterprise customers push for 60-90 days and a harder right to object. (2) Security measure specificity: A generic Annex II citing "encryption, access controls, and penetration testing" without specifics is often insufficient for enterprise security reviews. Customers push for specific encryption standards (AES-256 at rest, TLS 1.3 in transit), SOC 2 Type II or ISO 27001 certification requirements, and breach notification timelines shorter than the 72-hour legal minimum. (3) Audit rights: Standard DPAs allow audits "on reasonable notice" with the processor's cooperation. Enterprise customers sometimes demand on-site audit rights or the ability to conduct audits without prior notice (significant operational risk for the processor). A reasonable compromise: right to audit with 30 days' notice, limited to information security controls, and the cost borne by the requesting party for third-party assessments. (4) Data breach notification timeline: Article 33 requires notification to the supervisory authority within 72 hours. Enterprise customers frequently demand processor-to-controller notification timelines shorter than 72 hours (24-48 hours is common), to give themselves time to investigate before the 72-hour clock runs. (5) Deletion scope: Customers push for deletion of all copies, including backup copies, with written certification within 30 days of termination. Ensure your data deletion and backup rotation schedule can actually support this commitment. (6) Jurisdiction and governing law: EU customers prefer EU governing law; US SaaS companies prefer US or UK law. This is often negotiated by carving out the SCCs (which must be governed by EU law) while allowing the rest of the DPA to be governed by another jurisdiction.
What happens if your SaaS company processes personal data without a valid DPA?
Processing personal data without a compliant Article 28 DPA is a violation of GDPR on the part of both the controller (for failing to ensure a DPA is in place) and the processor (for processing without the required written contract). Enforcement consequences: Under Article 83(4) GDPR, violations of Article 28 (processor obligations, including DPA requirements) are subject to administrative fines up to €10 million or 2% of total worldwide annual turnover (whichever is higher). Supervisory authority enforcement of Article 28 DPA violations: the Irish DPC, which supervises most major US tech companies' EU operations, has cited absent or deficient DPAs in multiple enforcement investigations. Notable examples include Meta's various enforcement actions and numerous fines issued to smaller SaaS companies for inadequate or missing DPAs in GDPR investigations following data subject complaints. Beyond direct fines: a data breach without a valid DPA removes one of the key due diligence defenses a processor might otherwise assert. Without a DPA, the processor cannot demonstrate that processing occurred under controller instructions, making it harder to avoid direct liability for the breach. Contractual exposure: most enterprise SaaS agreements include representations and warranties about GDPR compliance. An absent DPA constitutes a breach of those warranties, triggering indemnification and potentially contract termination. From a business perspective: many enterprise customers in the EU now require DPA execution before commercial agreements take effect. Failure to have a readily negotiatable DPA stalls enterprise sales cycles, particularly in Germany, France, the Netherlands, and Nordics where legal teams routinely request DPAs as part of security and privacy due diligence.