What Is a Data Processing Agreement, and When Do You Actually Need One?

A data processing agreement is the contract that GDPR Article 28(3) requires whenever one organisation processes personal data on behalf of another. It has to be in writing, including electronic form, it has to be binding, and it has to set out eight specific subjects lettered (a) to (h). The reference source here is the European Data Protection Board's Guidelines 07/2020 on the concepts of controller and processor, version 2.1, adopted 7 July 2021 with minor corrections in September 2022. The contrarian line comes straight from the guidelines' own executive summary: the processing agreement "should not, however, merely restate the provisions of the GDPR" but should include "more specific, concrete information as to how the requirements will be met and which level of security is required." Most DPAs in circulation do exactly the thing the regulator says is not enough.

The EDPB is the body of EU data protection supervisory authorities. It sells nothing, and it is used here in preference to law-firm summaries or vendor templates, both of which have a commercial reason to make the exercise look either simpler or scarier than it is.

Below: what a DPA is for, the description of the processing, the eight subjects, sub-processor mechanics, what a DPA is not, and the clause that can silently convert your vendor into a controller.

Key takeaways

• The obligation attaches to the relationship, not the size of the company. If personal data is processed on your behalf and the GDPR applies, the contract is required.
• Eight mandatory subjects in Article 28(3), plus a description of the processing that the EDPB says must be specific rather than generic.
• Non-written agreements cannot satisfy Article 28, in the EDPB's words, regardless of how thorough or effective they are.
• A DPA is not a transfer mechanism. The EDPB separates Article 28 clauses from the Article 46(2) clauses used for third-country transfers.
• A processor that goes beyond the controller's instructions can become a controller for that processing, which changes who is liable.

What a DPA is for, and why the form requirement is strict

The EDPB's framing is that a controller "must only use processors providing sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of the GDPR," and that any processing by a processor "must be governed by a contract or other legal act which shall be in writing, including in electronic form, and be binding."

Paragraph 101 then closes the obvious loophole: "non-written agreements (regardless of how thorough or effective they are) cannot be considered sufficient to meet the requirements laid down by Article 28 GDPR." The EDPB recommends including the necessary signatures so the contract's existence is demonstrable, and notes in a footnote that a controller-processor relationship may still be held to exist without a written agreement, though that "would imply a violation of Article 28(3)." The absence of a DPA does not make you not a controller. It makes you a controller in breach.

Diligence is also continuing rather than one-off. The obligation "does not end at the moment where the controller and processor conclude a contract," and the controller should at appropriate intervals verify the processor's guarantees, including through audits and inspections where appropriate. The same muscle as a vendor review programme, covered from the buyer's side in our vendor risk management program guide.

The description of the processing, and why generic wording fails

Before the eight lettered obligations, Article 28(3) requires the contract to describe the processing itself. The EDPB's paragraph 114 reads that as setting out six things, and what makes the section useful rather than boilerplate is how specific it insists each one must be.

• Subject-matter needs "enough specifications so that it is clear what the main object of the processing is." The EDPB's example is video surveillance of people entering and leaving a high-security facility.
• Duration should give the exact period or the criteria used to determine it, and a footnote adds that this is not necessarily the duration of the agreement.
• Nature and purpose should be "as comprehensive as possible," specifically so external parties such as supervisory authorities can understand the content and the risks of what was entrusted.
• Type of personal data is where most templates fail. The EDPB says it "would not be adequate merely to specify that it is 'personal data pursuant to Article 4(1) GDPR' or 'special categories of personal data pursuant to Article 9'." For special categories it wants the types named, giving health records or trade union membership as examples.
• Categories of data subjects should be equally specific: visitors, employees, delivery services.
• Obligations and rights of the controller, including providing the data, documenting instructions, supervising the processing, and conducting audits and inspections.

If your standard DPA describes the data as "personal data as defined in the GDPR," the regulator's published interpretation says that is not adequate. It is the most common defect we see in agreements that otherwise look professionally drafted.

The eight subjects, in the order they bite

The lettered obligations, with what the EDPB says each requires in practice:

• (a) Documented instructions. The processor processes only on documented instructions. The EDPB recommends a procedure and template for issuing further instructions as an annex, and notes instructions can be given in any written form including email as long as records are kept. It extends the point to transfers: the contract "should specify the requirements for transfers to third countries or international organisations."
• (b) Confidentiality. Persons authorised to process the data must be committed to confidentiality or under a statutory obligation, and that commitment must be "appropriate," broad enough to cover all the personal data and the conditions of processing.
• (c) Article 32 security measures. Where the do-not-restate rule bites hardest. The contract "needs to include or reference information as to the security measures to be adopted, an obligation on the processor to obtain the controller's approval before making changes, and a regular review of the security measures," in enough detail for the controller to assess appropriateness under Article 32(1).
• (d) Sub-processors. Covered in its own section below.
• (e) Assistance with data subject rights. The processor assists the controller in responding to requests to exercise those rights.
• (f) Assistance with Articles 32 to 36. Security, breach notification and impact assessment obligations.
• (g) Deletion or return at the end. What happens to the data when the service ends.
• (h) Information and audits. Making available what is necessary to demonstrate compliance, and allowing for and contributing to audits.

The EDPB adds that "other relevant information may need to be included, depending on the context and the risks of the processing." Proportionality runs the other way too: there is no need to impose particularly stringent protections on a processor handling low-risk processing, and measures "should be tailored to the specific situation." All eight subjects must still be covered.

Sub-processors, and the flow-down that people forget

Paragraph 128 is precise. The agreement must specify that the processor may not engage another processor without the controller's prior written authorisation, and must state whether that authorisation is specific or general. Under a general authorisation the processor has to inform the controller of any change of sub-processors and give it the opportunity to object, and the EDPB stresses that the duty to inform "implies that the processor actively indicates or flags such changes toward the controller." A page on the vendor's website that customers are expected to monitor is a weaker reading of that than most vendors assume.

The flow-down is what gets dropped. When a processor engages another, a contract must impose "the same data protection obligations as those imposed on the original processor," and the EDPB names the Article 28(3)(h) audit obligation specifically as travelling down the chain. The processor remains liable to the controller for the sub-processor's compliance. If you publish a subprocessor list, the question a sophisticated customer asks is not whether the list exists but whether your contracts with those parties carry the terms your customer's DPA imposes on you.

Financial services regulation sets out a parallel, more detailed structure for ICT third parties; we covered it in DORA's contract requirements for vendors, and both regimes can apply to the same vendor.

What a DPA is not

Three confusions, each of which we have seen cost a deal or a review cycle.

A DPA is not a transfer mechanism. The EDPB is explicit that standard contractual clauses for the purposes of Article 28 "are not the same as standard contractual clauses referred to in Article 46(2)." The Article 28 set stipulates how the controller-processor obligations will be fulfilled; the Article 46(2) set provides safeguards for transferring personal data to a third country absent an adequacy decision. You can need both, and having one does not give you the other.

A DPA is not a BAA. The US healthcare equivalent arises under HIPAA and covers different obligations for different data with different enforcement. If you handle protected health information for a covered entity, the BAA question is separate and is not answered by a GDPR DPA.

A DPA is not necessarily a standalone document. The EDPB notes that a written contract under Article 28(3) "may be embedded in a broader contract." If the parties do adopt standard clauses, "the data protection clauses of their agreement must be the same as those of the SCCs," with the blanks filled in.

The clause that changes who is liable

The highest-consequence provision is one most commercial teams have never read. Under Article 28(10), a processor that processes data outside or beyond the controller's instructions, where that amounts to a decision determining the purposes and means of processing, "will be in breach of its obligations and will even be considered a controller in respect of that processing," in the EDPB's summary at paragraph 117.

That is what makes a "we use customer data to improve our models" clause a legal question rather than a product question. If a vendor decides on its own initiative what to do with data it holds on your behalf, the relationship for that activity is no longer processing on your instructions, both parties' obligations change, and so does who a supervisory authority talks to.

The practical control is unglamorous: write the instructions down, keep them with the contract as the EDPB recommends, and read the vendor's secondary-use clauses before signing rather than during an incident. Adjacent territory is covered in our US state privacy laws guide, where several regimes impose overlapping obligations on the same processing.

The honest caveat: what a DPA does not buy you

A signed DPA allocates responsibility. It is not evidence that the processor does any of the things it promised, and the EDPB's own position that verification is a continuing obligation carried out through audits and inspections is an admission that paper alone proves nothing.

Two consequences. Papering a hundred vendors with a strong template while auditing none produces a compliant-looking file and no assurance; with limited capacity, a real review of the five processors handling your most sensitive data beats a signature drive across all hundred. And the DPA is usually not where the risk lives. The failure modes that hurt are a processor with no documented instruction about international transfers, a sub-processor change nobody flagged, and a security annex so generic that nobody can tell whether the vendor's practice has drifted. The last two are invisible to a checklist that asks only whether a DPA exists.

Against our own interest: for a small company using a handful of mainstream cloud services, the vendors' published DPAs are usually adequate. Read them, record which ones you accepted, and spend the budget elsewhere.

Where Top Floor fits

We are useful for the specificity the EDPB asks for and templates cannot supply: describing your actual processing operations, data types and data subject categories precisely enough that a supervisory authority reading the annex would understand what was entrusted, and writing a security annex that reflects the controls you really operate. That sits inside our GDPR practice. Where the same vendors fall under several regimes at once, the normal case for anyone selling into both the EU and the US, global privacy is the wider frame, and the vendor-review cadence usually ends up inside a running compliance programme rather than a project.

Nothing here is legal advice, and a DPA is a contract. Where the drafting carries genuine legal consequence the right answer involves counsel; our contribution is describing the processing and the controls accurately enough that counsel argues about the right things.

How to decide this week

Pull the list of every vendor that touches personal data on your behalf and check three columns. Is there a signed agreement in writing, including electronic form? Does its description of the processing name your actual data types and data subject categories, or does it point back at Article 4? Does it state whether sub-processor authorisation is specific or general, with a route by which you would hear about a change? Rank by data sensitivity, not alphabetically, and fix the top five. If a vendor's contract lets it use your data for its own purposes, that one goes first regardless of sensitivity, because it is where the roles may not be what your paperwork says.

Frequently asked questions

Do we need a DPA with every vendor?

You need one with every processor, meaning every vendor that processes personal data on your behalf and under your instructions, where the GDPR applies. You do not need one with an independent controller determining its own purposes and means, or with a vendor that never touches personal data. The classification question comes first and is not always obvious, because the EDPB treats controller and processor as functional concepts turning on the actual roles of the parties rather than on what the contract calls them.

Does a DPA have to be signed, or is clicking accept enough?

Article 28(3) requires the contract or other legal act to be in writing, including in electronic form, and binding. The EDPB states that non-written agreements cannot meet the requirement regardless of how thorough they are, and recommends including the necessary signatures in line with applicable contract law, specifically to avoid difficulty demonstrating the agreement is in force. Electronic execution is contemplated by the text; the practical test is whether you could later show a supervisory authority which version was agreed and when.

Is a DPA the same as standard contractual clauses?

No, and the distinction matters. The EDPB separates standard clauses used for Article 28 compliance, which stipulate how the controller and processor obligations will be fulfilled, from the clauses referred to in Article 46(2), which provide safeguards for transfers to a third country where there is no adequacy decision. A DPA governs the processing relationship; a transfer mechanism addresses where the data goes. There is also no obligation to use standard clauses for Article 28 at all, since a negotiated contract is equally viable if it covers the required elements.

What happens if a processor uses our data for its own purposes?

The roles change. The EDPB's reading of Article 28(10) is that a processor which processes data outside or beyond the controller's instructions, where that amounts to determining the purposes and means, is in breach of its obligations and will be considered a controller in respect of that processing. This is why secondary-use clauses in vendor terms deserve reading before signature: a vendor deciding on its own initiative to use data it holds for you is no longer acting purely as your processor for that activity, and both parties' obligations and exposure move as a result.