GDPR Data Processing Agreements: A Complete Guide
Comprehensive guide to GDPR Data Processing Agreements covering Article 28 mandatory clauses, sub-processor management, audit rights, data deletion obligations, Standard Contractual Clauses for international transfers, and common DPA mistakes to avoid.
- 1
A DPA is legally required whenever a controller engages a processor to process personal data. Failure to have one in place is an independently enforceable GDPR violation with significant fine exposure.
- 2
Article 28(3) mandates specific clauses covering instructions, confidentiality, security measures, sub-processors, data subject rights assistance, deletion/return, and audit rights. All must be present and substantive.
- 3
Sub-processor management requires ongoing vigilance: maintain a sub-processor register, review change notifications, and ensure back-to-back contractual obligations flow through the entire chain.
- 4
For international transfers, use the 2021 SCCs (Module 2 for controller-to-processor) with a Transfer Impact Assessment and supplementary measures as required by Schrems II.
- 5
Common mistakes — missing DPAs, generic descriptions, ignored sub-processor changes, unexercised audit rights, and neglected data deletion — are all enforceable violations. Proactive DPA management is essential.
1. What Is a Data Processing Agreement and When Is It Required?
Article 28(3) of the GDPR requires that processing by a processor on behalf of a controller be governed by a contract or other legal act that sets out specific terms. This contract is commonly known as a Data Processing Agreement (DPA), Data Processing Addendum, or Data Processing Terms. The DPA is not optional — it is a legal requirement that applies whenever a controller engages a processor to process personal data on its behalf. Failure to have a DPA in place is an independently enforceable GDPR violation, and DPAs across Europe have issued significant fines for organisations that processed personal data through third parties without adequate contractual arrangements.
The obligation arises in any controller-processor relationship. Common scenarios requiring DPAs include: cloud service providers (IaaS, PaaS, SaaS) that process personal data on behalf of the customer, payroll and HR service providers, customer support platform providers, email marketing services, analytics and tracking services, IT managed service providers, backup and disaster recovery services, and any other third party that processes personal data under the controller's instructions. The key test is whether the third party processes personal data on behalf of and under the instructions of the controller — if so, they are a processor, and a DPA is required.
It is critical to correctly identify the roles in each data relationship. A third party that determines the purposes and means of processing is a controller, not a processor — and the relationship requires a different contractual arrangement (data sharing or joint controllership under Article 26, not Article 28). A party that processes data only under the controller's instructions is a processor. Misidentifying roles leads to incorrect contractual arrangements, which in turn leads to GDPR compliance gaps. Conduct a role assessment for each third-party data relationship and document the determination before selecting the appropriate contractual framework.
Do not rely on general terms of service or non-disclosure agreements as substitutes for a DPA. Article 28(3) requires specific mandatory clauses that general commercial contracts do not contain. A DPA must be a distinct document or a clearly identifiable section of the service agreement.
2. Mandatory Clauses Under Article 28(3)
Article 28(3) specifies the minimum content that every DPA must include. The processor must process personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or international organisation (unless required to do so by EU or Member State law). The DPA must require the processor to ensure that persons authorised to process personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality.
The DPA must require the processor to take all measures required pursuant to Article 32 — the security of processing obligation. This is where ISO 27001 certification becomes directly relevant: a processor with ISO 27001 certification can reference its ISMS and certification as evidence of appropriate technical and organisational measures. The DPA should describe the security measures at a sufficient level of detail for the controller to assess their adequacy, or reference a security policy or certification that provides this detail. The DPA must also address the processor's use of sub-processors: the processor must not engage another processor without prior specific or general written authorisation of the controller. Where general written authorisation is given, the processor must inform the controller of any intended changes and give the controller the opportunity to object.
Additional mandatory clauses require the processor to: assist the controller in fulfilling data subject rights requests (Articles 15-22), assist the controller in ensuring compliance with Articles 32-36 (security, breach notification, DPIAs, and prior consultation), delete or return all personal data to the controller after the end of the provision of services and delete existing copies unless EU or Member State law requires storage, and make available to the controller all information necessary to demonstrate compliance with Article 28 and allow for and contribute to audits conducted by the controller or another auditor mandated by the controller. Each of these clauses must be present and substantive — not merely referenced in passing.
3. Sub-Processor Management
Sub-processor management is one of the most operationally complex aspects of DPA compliance. Article 28(2) requires that the processor must not engage another processor (a sub-processor) without prior specific or general written authorisation from the controller. In practice, most SaaS providers use general authorisation with a notification mechanism: the DPA lists current sub-processors and requires the processor to notify the controller of any intended changes, giving the controller a reasonable period to object. If the controller objects, the DPA should specify the resolution mechanism — typically either the processor must not use the proposed sub-processor or the controller may terminate the affected services.
The processor must impose the same data protection obligations on the sub-processor as are set out in the DPA between the controller and processor, in particular providing sufficient guarantees to implement appropriate technical and organisational measures (Article 28(4)). This is known as the back-to-back requirement — the sub-processor contract must mirror the DPA obligations. Where the sub-processor fails to fulfil its data protection obligations, the initial processor remains fully liable to the controller for the performance of the sub-processor's obligations.
As a controller, establish a sub-processor management process: maintain a register of all sub-processors used by each of your processors, review sub-processor notifications when received and assess the new sub-processor's adequacy (location, security measures, certifications), exercise objection rights where a proposed sub-processor does not meet your data protection requirements, and periodically verify that the processor's current sub-processor list matches reality. As a processor, maintain an accurate and current sub-processor list, implement a notification mechanism that meets the agreed notice period, ensure all sub-processor contracts contain back-to-back DPA obligations, and monitor sub-processor compliance. Sub-processor chains can be deep in modern SaaS environments — a processor may use a cloud infrastructure provider, which uses a CDN, which uses a DDoS protection service, each of which may process personal data. Map these chains and ensure contractual coverage extends throughout.
Many SaaS providers publish their sub-processor list on a public webpage with an RSS or email notification mechanism for changes. Subscribe to these notifications for all processors in your vendor registry and route them to your data protection team for timely review.
4. Audit Rights and Data Deletion Obligations
Article 28(3)(h) requires the processor to make available to the controller all information necessary to demonstrate compliance with Article 28, and to allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. This audit right is mandatory and cannot be waived. In practice, the exercise of audit rights varies: some controllers conduct on-site audits of their processors, others rely on third-party audit reports (SOC 2, ISO 27001 certification), and others use security questionnaires supplemented by the right to conduct audits if concerns arise.
Negotiate audit provisions carefully. The DPA should specify: the notice period required before an audit (typically 30-60 days for planned audits, shorter for cause-based audits), the scope of the audit (systems, processes, and documentation relevant to the processing), any cost allocation (some processors charge for audit support beyond a certain frequency), confidentiality obligations on the auditor, and the process for sharing and responding to audit findings. Many large SaaS processors offer a standardised audit programme — sharing their SOC 2 Type II report or ISO 27001 certificate as the primary audit mechanism, with the right to conduct additional audits if the standard reports do not adequately address the controller's concerns.
Data deletion obligations under Article 28(3)(g) require the processor to, at the choice of the controller, delete or return all personal data after the end of the provision of services, and delete existing copies unless EU or Member State law requires storage. This obligation is operationally significant: when a service contract ends, all personal data processed under that contract must be deleted or returned within a defined period. The DPA should specify: the timeline for deletion or return after service termination (typically 30-90 days), the format for data return (structured, machine-readable format consistent with Article 20 portability requirements where applicable), the certification of deletion (many organisations require a written confirmation that all data has been deleted, including backups), and any exceptions for data that must be retained under applicable law. Test your deletion procedures before they are needed — discovering that your processor cannot isolate and delete your data during an actual service termination is too late.
5. Standard Contractual Clauses for International Transfers
Where a processor or sub-processor is located outside the European Economic Area (EEA) and no adequacy decision covers the destination country, the DPA must incorporate an appropriate transfer mechanism. Standard Contractual Clauses (SCCs) adopted by the European Commission are the most widely used mechanism. The current SCCs (Commission Implementing Decision (EU) 2021/914) were adopted on 4 June 2021 and are mandatory for new contracts — the previous 2001/2004/2010 SCCs are no longer valid. The 2021 SCCs use a modular structure with four modules covering different transfer scenarios: Module 1 (controller to controller), Module 2 (controller to processor), Module 3 (processor to processor), and Module 4 (processor to controller).
For controller-to-processor transfers (the most common DPA scenario), Module 2 applies. The SCCs must be incorporated into or annexed to the DPA without modification of the core clauses — the European Commission decision permits customisation only in the annexes (Annex I: description of transfer, Annex II: technical and organisational measures, Annex III: sub-processor list) and in optional clauses explicitly marked as such. Do not amend the substantive SCC clauses; this invalidates them as a valid transfer mechanism. Complete the annexes thoroughly and accurately — Annex II should describe the processor's actual security measures in sufficient detail to demonstrate adequacy.
Following the CJEU's Schrems II ruling (Case C-311/18, 16 July 2020), SCCs alone may not be sufficient. The data exporter must conduct a Transfer Impact Assessment (TIA) evaluating whether the laws of the destination country provide adequate protection for personal data, particularly regarding government access. The EDPB's Recommendations 01/2020 provide a six-step methodology for this assessment. Where the TIA identifies risks, supplementary measures — technical (encryption, pseudonymisation), contractual (additional commitments from the importer), or organisational (access control, auditing) — must be implemented. Document the TIA and supplementary measures alongside the SCCs. This documentation is critical evidence in DPA enforcement proceedings and must be maintained and updated when the legal landscape in the destination country changes.
The 2021 SCCs are the only valid Standard Contractual Clauses for new data transfer arrangements. If your existing DPAs reference the old 2001/2004/2010 SCCs, they must be updated. Contracts using outdated SCCs do not provide a valid transfer mechanism under GDPR.
6. Common DPA Mistakes and How to Avoid Them
The most pervasive mistake is the missing DPA: organisations engage processors — SaaS tools, cloud infrastructure, marketing platforms, analytics services — without putting a DPA in place. This often happens when procurement bypasses the legal or data protection team, when shadow IT introduces new tools without formal onboarding, or when existing vendor relationships predate GDPR and DPAs were never retroactively established. Conduct a comprehensive processor inventory at least annually, cross-referencing procurement records, finance records (recurring payments to service providers), and IT systems inventories to identify processor relationships that may lack DPA coverage.
Another common mistake is the template DPA that is signed but not tailored. A DPA must accurately describe the processing activities: the subject matter and duration of processing, the nature and purpose of processing, the types of personal data, and the categories of data subjects. Generic descriptions such as 'the processor processes personal data for the purposes of providing the services' are insufficient — they do not enable the controller to assess whether the processing is appropriate, nor do they provide the processor with clear boundaries on what processing is authorised. Invest the time to accurately complete Schedule/Annex details for each DPA.
Failing to manage sub-processor changes is a third common mistake. Controllers sign the DPA, file it, and never review sub-processor notifications. When the processor adds a new sub-processor in a jurisdiction with inadequate data protection, or engages a sub-processor that has previously been the subject of DPA enforcement action, the controller remains unaware and exposed. Fourth, neglecting to exercise or even review audit rights: controllers accept SOC 2 reports or ISO 27001 certificates at face value without assessing whether their scope covers the relevant processing activities. Fifth, ignoring data deletion at contract termination: when switching vendors, controllers focus on migrating data to the new provider but fail to ensure the departing provider deletes all personal data within the contracted timeframe. Each of these mistakes has been the subject of DPA enforcement action — none are theoretical risks.
Maintain a DPA register alongside your Records of Processing Activities (RoPA). For each processor, record: the DPA execution date, the processing activities covered, the sub-processor list review date, the last audit or certification review date, and the contract renewal or termination date. This register is your operational tool for proactive DPA management.
7. DPA Negotiation Best Practices
When negotiating DPAs with processors, adopt a risk-proportionate approach. For high-volume or high-sensitivity processing (e.g., cloud infrastructure hosting customer databases, HR processing outsourcing, health data processing), negotiate aggressively on security measures, audit rights, breach notification timelines, sub-processor approval mechanisms, and data deletion procedures. For lower-risk processing (e.g., a marketing analytics tool processing pseudonymised website visitor data), a standardised DPA with reasonable terms may be acceptable without extensive negotiation.
Key negotiation points include breach notification timelines: GDPR requires the processor to notify the controller 'without undue delay' after becoming aware of a breach, but does not specify an exact timeline. Best practice is to negotiate a specific notification window — 24-48 hours is common and provides the controller sufficient time to assess and meet the 72-hour DPA notification deadline. Audit rights should include the ability to conduct or commission audits at least annually, with shorter-notice audits triggered by a breach or compliance concern. Data deletion timelines should be 30 days or less after service termination, with written certification of deletion. Sub-processor change notification should provide at least 30 days' notice with a meaningful objection right.
For international transfers, negotiate the incorporation of SCCs with specific supplementary measures rather than leaving transfer mechanisms undefined. Where the processor insists on its standard DPA terms (common with large SaaS providers), assess whether the standard terms meet GDPR requirements and document your assessment. Where specific clauses fall short — for example, a breach notification timeline of 'within a reasonable time' rather than a specific window — document the risk and implement compensating measures (e.g., enhanced monitoring of the processor's security status). Never sign a DPA without reading it, never accept terms that explicitly contradict GDPR requirements (e.g., terms that waive audit rights), and always ensure the DPA is executed before processing begins — not retroactively after the processor has already received personal data.
Who is responsible for providing the DPA — the controller or the processor?
The controller bears the legal obligation to ensure that a DPA is in place (Article 28(3)). In practice, many processors (particularly SaaS providers) offer their own standard DPA, which the controller must review and accept or negotiate. If the processor does not provide a DPA, the controller must provide one. Either way, the controller is responsible for ensuring that the DPA meets GDPR requirements — signing a processor's standard terms without review does not absolve the controller of liability if those terms are inadequate.
Can we use the European Commission's Standard Contractual Clauses as our DPA?
The 2021 SCCs (Decision 2021/914) can serve as the DPA for international transfers — Module 2 (controller to processor) includes all Article 28(3) required clauses alongside the transfer safeguards. However, SCCs are specifically designed for international transfers. For processing that remains within the EEA, a standalone DPA is needed — the SCCs are not intended for intra-EEA processing. For cross-border processing, the SCCs can function as a combined DPA and transfer mechanism, provided the annexes are completed accurately.
How often should DPAs be reviewed and updated?
Review DPAs at least annually and whenever a significant change occurs: change in processing activities, change in sub-processors, change in data categories or volumes, change in transfer destinations, expiry of the service contract, or new regulatory guidance affecting DPA requirements. The annual review should verify that the DPA accurately reflects current processing activities, that sub-processor lists are current, that security measures described in the DPA remain accurate, and that transfer mechanisms (if applicable) remain valid. Schedule DPA reviews alongside your RoPA update cycle for efficiency.
What happens if a processor refuses to sign a DPA?
If a processor refuses to enter into a DPA that meets GDPR Article 28 requirements, you cannot lawfully engage that processor for personal data processing. This is non-negotiable — Article 28(1) requires controllers to use only processors providing sufficient guarantees, and Article 28(3) requires the contractual arrangement. You must either negotiate until the processor agrees to adequate DPA terms, find an alternative processor that will sign a compliant DPA, or restructure the arrangement so that personal data is not shared with the third party (e.g., by anonymising data before transfer). Using a processor without a DPA exposes the controller to enforcement action and fines.
Do DPAs need to cover all GDPR requirements or just Article 28?
Article 28(3) specifies the minimum mandatory content for DPAs. However, a well-drafted DPA should also address: GDPR breach notification assistance (Articles 33-34), DPIA cooperation (Article 35), details of technical and organisational measures (Article 32), and any applicable international transfer provisions (Articles 44-50). Additionally, the DPA should include practical operational provisions such as incident response contact details, escalation procedures, data return formats, and contract termination procedures. The Article 28(3) mandatory clauses are the legal minimum — comprehensive DPAs go further to ensure operational compliance.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.