Data Protection Agreement: What It Is and When You Need One

If a third party touches personal data on your behalf, you almost certainly need a data protection agreement with them. It is not optional paperwork or a nice-to-have: Article 28(1) of the General Data Protection Regulation (GDPR) makes a written contract a precondition for using any processor at all. This guide explains what a data protection agreement must contain, who signs it, and how to get it in place without hiring a law firm for every vendor. It is educational rather than legal advice, so check with a qualified attorney for anything specific to your business.

What Is a Data Protection Agreement?

A data protection agreement is a binding contract between a data controller and a data processor that sets out how the processor may handle personal data on the controller's behalf. It defines the subject matter, duration, purpose, and scope of the processing, and it imposes a fixed set of obligations on the processor drawn from Article 28(3) of the GDPR.

You will see the same document called several things. Data protection agreement, data processing agreement, DPA, and controller to processor agreement all refer to the same instrument. The GDPR itself uses none of those labels. Article 28(3) simply says processing by a processor "shall be governed by a contract or other legal act under Union or Member State law."

Two points get lost in the naming confusion:

• A data protection agreement is a contract between two businesses. It is not a document your website visitors ever see.
• It is separate from your public-facing disclosures. Your privacy policy tells users what you do with their data. Your DPA tells your vendor what they are allowed to do with it.

When You Need a Data Protection Agreement

The trigger is simple. If another organization processes personal data on your instructions and for your purposes, you need a DPA with them. Article 4(8) defines a processor as anyone who processes personal data on behalf of the controller.

In a typical small business, that captures far more vendors than people expect:

• Web hosting and cloud infrastructure (AWS, Google Cloud, Railway, Vercel)
• Email service providers and marketing platforms (Mailchimp, Resend, Klaviyo)
• Analytics and product telemetry tools
• CRM and helpdesk software (HubSpot, Zendesk, Intercom)
• Payment and billing platforms, where they act as processors rather than controllers
• Backup, logging, and error monitoring services (Sentry, Datadog)
• Freelancers and agencies with access to your customer database

You do not need a DPA when the other party decides its own purposes and means for the processing. Your accountant, your bank, your insurer, and most regulators are independent controllers. A tax adviser processing your employee payroll data does so under professional obligations, not your instructions, so a controller to controller arrangement applies instead of an Article 28 contract.

The awkward middle ground is joint controllership under Article 26. If you and a partner genuinely decide the purposes together, for example a co-branded webinar where both parties independently market to the registrants, you need a joint controller arrangement rather than a DPA. The European Data Protection Board's Guidelines 07/2020 on the concepts of controller and processor is the reference to work through if the roles are unclear.

What a Data Protection Agreement Must Contain

Article 28(3) sets out eight mandatory obligations. A contract missing any of them is not compliant, even if it is titled "Data Protection Agreement" and runs to 20 pages. Check every vendor document against this list:

1. Documented instructions only. The processor may only process personal data on the controller's documented instructions, including for international transfers, unless required to do otherwise by law (Article 28(3)(a)).
2. Confidentiality commitments. Everyone authorized to process the data must be bound by confidentiality, either contractually or by statutory duty (Article 28(3)(b)).
3. Security measures. The processor must implement the technical and organizational measures required by Article 32, which names pseudonymization, encryption, resilience, and regular testing (Article 28(3)(c)).
4. Sub-processor controls. The processor must not engage another processor without prior specific or general written authorization, and must flow the same obligations down (Articles 28(2) and 28(3)(d)).
5. Assistance with data subject rights. The processor must help the controller respond to access, erasure, portability, and objection requests under Chapter III (Article 28(3)(e)).
6. Assistance with breaches and assessments. The processor must support the controller's obligations under Articles 32 to 36, which covers breach notification and data protection impact assessments (Article 28(3)(f)).
7. Deletion or return at the end. At the controller's choice, the processor must delete or return all personal data when the service ends, and delete existing copies unless retention is legally required (Article 28(3)(g)).
8. Audit and information rights. The processor must make available all information needed to demonstrate compliance and allow audits or inspections (Article 28(3)(h)).

Alongside those eight, Article 28(3) requires the contract to state four descriptive facts: the subject matter and duration of the processing, the nature and purpose, the type of personal data, and the categories of data subjects. These usually live in an annex or schedule at the back of the agreement rather than in the body.

The Annex Is the Part People Skip

The obligations in the body of a data protection agreement are broadly standard across vendors. The annex is where the specifics live, and it is the part most often left blank or filled with placeholder text. If your DPA annex says "personal data as determined by Customer," it fails the Article 28(3) requirement to specify the type of data and categories of data subjects.

Fill it in properly: "email address, hashed password, IP address, billing address" beats "contact details." The same information feeds your Article 30 records of processing activities, so the work is not wasted.

Sub-processors and the Chain of Responsibility

Every modern SaaS vendor uses sub-processors. Your email platform runs on AWS, uses a CDN, and sends transactional messages through another provider. Article 28(4) requires the original processor to impose the same data protection obligations on each sub-processor, and it keeps the original processor fully liable to you if the sub-processor fails.

Two authorization models exist under Article 28(2), and your DPA must pick one:

• Specific authorization. You approve each sub-processor individually before it is engaged. Rare outside heavily regulated sectors because it does not scale.
• General authorization. You approve the current list and the processor commits to notifying you of additions or replacements, giving you the chance to object. This is what almost every commercial DPA uses.

When you accept general authorization, the notice period and objection mechanism matter. A clause offering 10 days' notice with no right to terminate is weak. Look for at least 30 days and a right to exit the contract without penalty if you reasonably object. Ask for the vendor's public sub-processor list and subscribe to its change notifications, since your obligation to keep records current does not pause because the vendor changed suppliers quietly.

Data Protection Agreements and International Transfers

A data protection agreement satisfies Article 28. It does not, by itself, legalize sending data outside the European Economic Area. Chapter V of the GDPR (Articles 44 to 49) is a separate hurdle, and after the Court of Justice's Schrems II ruling in 2020 it is one regulators actively police.

Your options for a transfer mechanism:

• Adequacy decision. The Commission has recognized the UK, Switzerland, Japan, South Korea, and others. The EU-US Data Privacy Framework adequacy decision of July 2023 covers US organizations that self-certify under the framework, so check whether your vendor is actually on the Data Privacy Framework list rather than assuming.
• Standard Contractual Clauses. The 2021 SCCs adopted in Implementing Decision (EU) 2021/914 come in four modules. Controller to processor is Module Two, which is what a typical vendor relationship uses.
• Binding corporate rules. Only practical for large corporate groups moving data internally, as covered in the guide on binding corporate rules.

Where you rely on the SCCs, you also need a transfer impact assessment documenting whether the destination country's laws undermine the clauses. For UK transfers, the International Data Transfer Agreement or the UK Addendum to the EU SCCs applies instead. Most mature vendors attach the SCCs as an annex to their standard data protection agreement so one signature covers both Article 28 and Chapter V.

Data Protection Agreement vs Privacy Policy

These two documents get conflated constantly, and mixing them up creates real gaps. They serve different audiences under different articles of the GDPR.

	Data protection agreement	Privacy policy
Legal basis	Article 28(3)	Articles 13 and 14
Audience	Your vendor or your business customer	Data subjects (your users)
Form	Signed contract between two parties	Public notice on your website
Content	Processing instructions, security, audits, deletion	Data collected, purposes, legal bases, rights
Consequence of omission	Article 83(4) fine tier, up to 10M EUR or 2 percent	Article 83(5) fine tier, up to 20M EUR or 4 percent

You need both. Publishing an accurate privacy policy that lists your processor categories does not replace the contract, and signing a DPA with every vendor does not tell your users anything. Note that transparency failures sit in the higher fine tier under Article 83(5)(b), so a missing privacy notice is treated more severely than a missing processor contract.

Contract Requirements Under Other Privacy Laws

GDPR is the strictest, but it is not the only regime with a vendor contract mandate. If you sell into multiple markets, one agreement usually carries all of them with jurisdiction-specific addenda.

• California. Section 1798.100(d) of the California Consumer Privacy Act (CCPA), as amended by the CPRA, requires a written contract with any service provider, contractor, or third party. It must specify the limited business purpose, prohibit selling or sharing the data, prohibit retention or use outside the direct business relationship, and grant the business the right to take reasonable steps to stop unauthorized use. The CCPA service provider addendum guide covers the specific wording.
• United Kingdom. UK GDPR Article 28 mirrors the EU text almost word for word, enforced by the Information Commissioner's Office.
• Brazil. The LGPD requires controllers to ensure operators process data under instructions, with joint liability under Article 42.
• Singapore, Canada, Australia. The PDPA, PIPEDA, and Australian Privacy Principle 8 all impose accountability for data handed to third parties, generally through contractual safeguards rather than a prescribed clause list.

Practical approach: draft against Article 28(3) because it is the most demanding, then bolt on a CCPA addendum with the service provider language. That combination covers most cross-border SaaS businesses.

How to Put a Data Protection Agreement in Place

Getting agreements signed across a vendor stack is a project, not a single task. Work through it in order:

1. Inventory your processors. List every service that touches personal data. A compliance scan of your own site surfaces the third-party scripts and trackers you forgot about, which is often where the surprises are. Cross-reference against your billing statements and your Article 30 records of processing activities.
2. Find the existing agreement. Most major vendors publish a standard DPA that is either incorporated into their terms automatically or available through a self-service form in account settings. Check before you draft anything.
3. Review it against Article 28(3). Walk the eight-point list above. Flag anything missing, especially audit rights, deletion terms, and the sub-processor objection mechanism.
4. Check the transfer annex. Confirm the SCCs are attached with the right module selected, or that the vendor is on the Data Privacy Framework list.
5. Complete the annex. Specify the actual data categories, data subjects, and retention period. Do not accept placeholders.
6. Sign and store centrally. Keep every executed DPA in one place with a renewal or review date. Article 5(2) accountability means you have to be able to produce them on request.
7. Re-review annually or on change. New vendor, new data type, new region, or a change to the vendor's sub-processor list all trigger a fresh look.

For agencies and SaaS companies, the direction reverses: you are the processor and your clients want a DPA from you. Publishing your own standard agreement, as covered in the guides on DPAs for SaaS vendors and GDPR DPAs for agencies, removes friction from every enterprise deal. TermsBox scans your site to identify which third-party services are actually loading, which is the fastest way to build the processor inventory that step one requires.

Common Data Protection Agreement Mistakes

These are the failures that turn up repeatedly in regulator decisions and due diligence reviews:

• Relying on a mention in the terms of service. A sentence saying "we comply with GDPR" is not an Article 28 contract. The eight obligations must be present.
• Signing without completing the annex. An agreement with an empty processing description fails the specificity requirement in Article 28(3).
• Ignoring the sub-processor list. General authorization only works if you actually read the notifications and can object.
• Treating a DPA as a security guarantee. The contract obliges the processor to implement Article 32 measures. It does not verify that they did. Ask for the SOC 2 report or ISO 27001 certificate.
• Forgetting the exit. Article 28(3)(g) gives you a choice between deletion and return. Decide which one you want before the relationship ends, not after.
• Missing the breach clock. Article 33(2) requires processors to notify the controller "without undue delay." Your DPA should convert that into a hard number, ideally 24 to 48 hours, because your own Article 33(1) deadline to the supervisory authority is 72 hours from awareness.
• Never revisiting it. A DPA signed in 2018 against the old 2010 SCCs is out of date. The 2021 SCCs replaced them, and the transition period ended in December 2022.

Frequently Asked Questions

What is the difference between a data protection agreement and a data processing agreement?

In practice they are the same document, and both are commonly abbreviated as DPA. The General Data Protection Regulation itself does not use either name, it simply requires a binding contract under Article 28(3), so vendors label it whichever way they prefer.

Do I need a data protection agreement with every vendor?

You need one with every vendor that processes personal data on your instructions, such as hosting providers, email platforms, analytics tools, and CRMs. You do not need one with a party that decides its own purposes for the data, like your accountant or a bank, because that relationship is controller to controller.

Who is responsible for providing the data protection agreement?

The controller is legally responsible for making sure a compliant contract exists under Article 28(1), but in practice most processors publish their own standard DPA and offer it for signature. Reviewing and accepting a vendor DPA satisfies the obligation as long as it contains every element required by Article 28(3).

What are the penalties for not having a data protection agreement?

Missing or inadequate Article 28 contracts fall into the lower GDPR fine tier under Article 83(4)(a), which allows up to 10 million EUR or 2 percent of global annual turnover, whichever is higher. Regulators including the Irish DPC and Spain's AEPD have issued fines and reprimands specifically for absent processor contracts.

Does a data protection agreement cover international data transfers on its own?

No. A DPA satisfies Article 28, but sending personal data outside the EEA also requires a separate transfer mechanism under Chapter V, usually the Standard Contractual Clauses adopted in Implementing Decision (EU) 2021/914 plus a transfer impact assessment. Many vendor DPAs attach the SCCs as an annex so both requirements are handled in one signature.

Do I need a data protection agreement under CCPA as well?

Yes, California law has its own contract requirement. Section 1798.100(d) of the CCPA requires a written contract with any service provider or contractor that restricts them to the specified business purpose and prohibits selling or retaining the data, so most vendors fold these terms into the same DPA used for GDPR.