What a Data Processing Agreement Actually Does
A data processing agreement (DPA) is a legally binding contract between a data controller and a data processor. If your website uses Google Analytics, a live chat widget, an email marketing platform, or any other third-party service that handles visitor data on your behalf, you are the controller and that vendor is your processor.
Article 28 of the GDPR makes this contract mandatory. Operating without one is not a grey area - it is a direct breach of the regulation, and data protection authorities across Europe have issued fines for exactly this failure.
The DPA defines what the processor can do with the data, how long they can keep it, and what security measures they must have in place. It also sets out obligations around sub-processors, data breaches, and data subject rights.
When You Need a DPA (and When You Do Not)
You need a DPA whenever a third party processes personal data on your instructions. This covers analytics providers, advertising platforms, CRM tools, hosting companies, and payment processors that handle customer records beyond what is strictly necessary for the transaction.
You do not need a DPA when the other party is a joint controller or an independent controller in its own right. A social media platform where users voluntarily share data, for example, typically acts as an independent controller for that data - not as your processor.
The distinction matters. Getting the relationship wrong means applying the wrong legal framework, which can undermine your entire compliance position. The core principles of GDPR data processing apply regardless, but the contractual requirements differ.
The Eight Mandatory Clauses Under Article 28(3)
Article 28(3) of the GDPR specifies eight topics that every DPA must address. Missing even one can render the agreement non-compliant.
| Clause | What It Must Cover | Practical Example |
|---|---|---|
| Processing instructions | Processor acts only on documented instructions from the controller | Analytics vendor processes page view data solely for reporting purposes you define |
| Confidentiality | All persons processing data are bound by confidentiality obligations | Vendor staff sign NDAs or are under statutory duty of confidentiality |
| Security measures | Appropriate technical and organisational measures under Article 32 | Encryption at rest and in transit, access controls, regular penetration testing |
| Sub-processor rules | No sub-processor engagement without prior written authorisation | Your email platform must notify you before using a new cloud hosting provider |
| Data subject rights | Processor assists the controller in responding to data subject requests | Vendor provides export or deletion tools for individual user records |
| Breach notification | Processor notifies controller without undue delay after becoming aware of a breach | Vendor alerts you within hours, not weeks, enabling your 72-hour notification obligation |
| Deletion or return | At the end of the service, processor deletes or returns all personal data | When you cancel an analytics subscription, the vendor purges your visitor data |
| Audit rights | Controller can audit or inspect the processor's compliance | You have the right to request SOC 2 reports or conduct on-site audits |
Each clause should be specific to your actual processing activities. A generic, copy-paste DPA that does not reflect the reality of the data flows between you and your vendor is unlikely to satisfy a regulator during an investigation.
Handling Sub-Processors Properly
Sub-processors are one of the trickiest parts of DPA management. Your analytics vendor might use Amazon Web Services for hosting, a CDN provider for delivery, and a separate company for customer support tooling. Each of these is a sub-processor, and under Article 28(2), you must either give specific authorisation for each one or provide general written authorisation with a right to object when changes occur.
Most SaaS vendors use the general authorisation model. They maintain a public list of sub-processors and notify customers before adding new ones. Your DPA should specify the notification period - 30 days is common - and your right to object or terminate if the new sub-processor is unacceptable.
The processor must impose the same data protection obligations on every sub-processor through a written contract. If that sub-processor fails to meet its obligations, the original processor remains fully liable to you.
Standard Contractual Clauses for International Transfers
When your processor is based outside the European Economic Area, the DPA alone is not enough. You also need a valid transfer mechanism. The most widely used option is the European Commission's Standard Contractual Clauses (SCCs), adopted in June 2021.
The current SCCs come in four modules. For a controller-to-processor relationship, Module 2 applies. These clauses must be incorporated into or appended to your DPA - they cannot simply be referenced in passing.
A Transfer Impact Assessment (TIA) should accompany the SCCs. This documents whether the laws of the recipient country offer adequate protection and whether supplementary measures (such as encryption or pseudonymisation) are needed. The Dutch DPA's EUR 290 million fine against Uber in 2024 for transferring driver data to the United States without adequate safeguards underscored how seriously regulators treat cross-border data transfers.
Common Mistakes That Trigger Enforcement
The most frequent error is simply not having a DPA at all. Many website owners assume that signing up for a SaaS product and ticking a terms-of-service box is sufficient. It is not. A DPA is a separate contractual requirement.
Other common failures include:
- Using outdated DPA templates that reference the old 2010 SCCs instead of the 2021 version
- Failing to list all sub-processors or failing to update the list when vendors change their infrastructure
- Including audit rights on paper but making them practically impossible to exercise
- Not specifying the subject matter, duration, nature, and purpose of processing - the four descriptors Article 28(3) requires
- Omitting breach notification timelines, leaving the processor with no contractual deadline to inform you
Regulators have shown they will look beyond the document itself. If your DPA says one thing but your actual data processing practices say another, the agreement offers little protection.
Step-by-Step: Drafting Your DPA
Step 1: Map Your Vendors
Start by listing every third-party service that touches personal data from your website. This includes analytics, advertising pixels, live chat widgets, form processors, hosting providers, and email platforms. A cookie audit is a practical starting point, since it reveals which third parties receive data through your site.
Step 2: Classify Each Relationship
Determine whether each vendor is a processor, a joint controller, or an independent controller. This classification drives the type of agreement you need.
Step 3: Check Existing DPAs
Many large vendors - Google, Meta, HubSpot, Hotjar - already offer standard DPAs. Review these carefully. Check that they cover all eight Article 28(3) requirements and that the sub-processor list is current.
Step 4: Draft Custom Clauses Where Needed
For smaller vendors or bespoke services, you may need to draft the DPA yourself. Use the European Commission's SCCs as a foundation and add annexes specifying the categories of data subjects, types of personal data, and processing operations.
Step 5: Negotiate and Sign
DPAs are negotiable. If a vendor's standard terms do not include adequate audit rights or breach notification timelines, push back. A vendor unwilling to sign a compliant DPA is a vendor you should reconsider using.
Step 6: Maintain and Review
DPAs are not set-and-forget documents. Review them annually or whenever you change the scope of data you share with a vendor. Keep signed copies as part of your records of processing activities.
DPAs and Your Cookie Compliance Stack
Your cookie consent management platform, analytics tools, and advertising scripts all involve data processors. The DPA you hold with each vendor should align with what your cookie banner tells visitors.
If your privacy policy states that analytics data is processed within the EEA, but your analytics vendor's sub-processor list includes servers in the United States, there is a gap. Your vendor risk assessment process should catch these inconsistencies before a regulator does.
Conducting regular scheduled cookie scans helps identify new third-party scripts that may appear on your site without a corresponding DPA in place.
Frequently Asked Questions
Do I need a data processing agreement for every cookie on my website?
Not for every cookie, but for every third-party service that processes personal data on your behalf. If a cookie is set by a vendor who acts as your processor - such as an analytics or marketing platform - you need a DPA with that vendor.
Can I use a free DPA template from the internet?
Free templates can serve as a starting point, but they must be customised to reflect your specific processing activities, data categories, and vendor relationships. A generic template that does not match your actual data flows is unlikely to satisfy Article 28 requirements.
What happens if my vendor refuses to sign a data processing agreement?
Under GDPR Article 28(1), you may only use processors that provide sufficient guarantees. If a vendor refuses to sign a compliant DPA, continuing to share personal data with them puts you in breach of the regulation. Consider finding an alternative provider.
How often should I review my data processing agreements?
At minimum, review your DPAs annually. You should also review them whenever you change the type of data shared, when the vendor updates its sub-processor list, or when relevant legislation changes.
Is a data processing agreement the same as a privacy policy?
No. A privacy policy is a public-facing document that tells your visitors how you handle their data. A DPA is a private contract between you and your data processor governing how that processor handles data on your behalf.
Do standard contractual clauses replace a data processing agreement?
No. SCCs address international data transfers specifically. You still need a DPA covering all Article 28(3) requirements. In practice, SCCs are often appended to or incorporated within the DPA as an additional module.
Take Control of Your Cookie Compliance
If you are not sure which cookies your site sets, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
