Article 28 of the General Data Protection Regulation (GDPR) is the provision that turns a vendor relationship into a regulated one. Whenever a controller has personal data processed on its behalf, Article 28(3) requires a binding contract — in practice called a Data Processing Agreement (DPA) — that governs the processing and contains a defined set of commitments from the processor. The clause list is not a suggestion: each element is mandatory, and a missing element is a gap in the controller's own compliance, not just the vendor's.
A DPA is not the commercial agreement itself. It usually rides alongside the service contract as an annex or a separately executed document, and it must be in writing, which Article 28(9) confirms includes electronic form. Its job is narrow and important: to bind the processor to process personal data only within the boundaries the controller sets, and to make the protections of the GDPR enforceable through the contract chain.
This guide walks through what Article 28(3) actually requires, how sub-processing authorization works under Articles 28(2) and 28(4), where the European Commission's optional standard clauses fit, and the gaps that show up most often in vendor paper.
When a DPA is required
The trigger is the role split: one party determines the purposes and means of processing, and another processes on its behalf. If your organization is the controller and a vendor is your processor, an Article 28(3) contract is required before the processing starts. The obligation is bilateral in practice — controllers must impose the terms, and a diligent processor will not process without them — but the selection duty sits with the controller: under Article 28(1), controllers may use only processors that provide sufficient guarantees of appropriate technical and organizational measures.
Two boundary cases catch teams out. A vendor that processes no personal data at all needs no DPA. And a vendor that acts as an independent controller — deciding its own purposes for the data — needs a different kind of contract entirely, because handing it a processor's DPA misstates the relationship and leaves controller-to-controller questions unaddressed.
The mandatory clauses of Article 28(3)
Article 28(3) first requires the contract to record the basics of the processing: its subject matter and duration, the nature and purpose, the types of personal data, the categories of data subjects, and the obligations and rights of the controller. It then lists the commitments the processor must make. In condensed form, the processor must:
- Process personal data only on the controller's documented instructions, including for international transfers.
- Guarantee that persons authorized to process the data have committed to confidentiality or are under a statutory duty of it.
- Take all security measures required by Article 32.
- Respect the sub-processing conditions of Articles 28(2) and 28(4).
- Assist the controller, so far as possible, in responding to data subject rights requests.
- Assist the controller with its duties under Articles 32 to 36, covering security, breach notification, and impact assessments.
- Delete or return all personal data at the end of the services, unless Union or Member State law requires storage.
- Make available the information needed to demonstrate compliance, and allow for and contribute to audits and inspections.
Article 28(3) also adds a standing duty: the processor must immediately inform the controller if, in its view, an instruction infringes the GDPR or other Union or Member State data protection law. The full text of the provision is worth reading directly in the GDPR on EUR-Lex; the paraphrase above is a map, not a substitute.
Documented instructions and transfers
The instructions clause is the heart of the processor relationship: it is what keeps the vendor inside the controller's decisions. Instructions must be documented — typically the DPA itself plus the service's documented functionality — and they expressly cover transfers of personal data to third countries. A processor asked to move data outside the European Economic Area (EEA) needs the controller's instruction or a legal requirement to do so, which is why processing-location and transfer clauses belong with the instructions, not in a side letter.
Security and assistance duties
The Article 32 reference imports the GDPR's security standard into the contract: measures appropriate to the risk, considering the state of the art, costs, and the nature of the processing. The assistance clauses then make the processor an operational participant in the controller's duties — helping with data subject rights requests, feeding the controller what it needs to notify breaches within the deadlines of Articles 33 and 34, and supporting impact assessments and prior consultation under Articles 35 and 36. In negotiation, the substance of these clauses is usually less contested than their conditions: who pays, how fast, and through which channel.
Sub-processing, deletion, and audit
The remaining clauses carry the chain and the exit. The sub-processing commitment binds the processor to the authorization regime described below. The deletion-or-return clause decides what happens to the data when the relationship ends — and is only as good as its timelines and its treatment of backups. The audit clause is the controller's verification path: information on request, plus audits and inspections by the controller or a mandated auditor. What a workable audit clause looks like in practice is part of our DPA review checklist.
Sub-processing under Articles 28(2) and 28(4)
Article 28(2) prohibits the processor from engaging another processor — a subprocessor, in industry shorthand — without the controller's prior specific or general written authorization. Specific authorization means case-by-case approval. General authorization, the norm in software-as-a-service (SaaS), means the controller approves a described set of subprocessors up front; in exchange, the processor must inform the controller of intended additions or replacements and give it the opportunity to object. The notice mechanics and objection windows live in the DPA, which is why they differ so much between vendors — a topic we cover in depth in our article on sub-processor change notifications.
Article 28(4) completes the structure with flow-down: when the processor engages a subprocessor, it must impose the same data protection obligations it owes the controller onto that subprocessor by contract, and it remains fully liable to the controller if the subprocessor fails to perform. The chain is only as strong as its mirroring, which is why controllers reviewing a DPA should look for a clear statement that sub-processor contracts replicate the DPA's protections. For the wider context of how these chains form, see our explainer on what a subprocessor is.
The Commission's optional standard clauses
Article 28(7) empowers the European Commission to lay down standard contractual clauses for the matters in Article 28(3) and (4), and the Commission did so in Implementing Decision (EU) 2021/915. These clauses are a complete, pre-approved controller-processor contract: parties can adopt them, fill in the annexes describing the processing, the security measures, and the subprocessor list, and satisfy Article 28(3) without drafting from scratch. They are optional — most large vendors offer their own DPA instead — but they are a useful benchmark: if a vendor's DPA is materially thinner than the Commission's clauses on some point, that point deserves a question.
One distinction prevents a common mix-up: the Decision 2021/915 clauses govern the controller-processor relationship inside the contract. They are not the Standard Contractual Clauses (SCCs) for international transfers, which were adopted separately in Implementing Decision (EU) 2021/914 and serve as a transfer tool under Chapter V. A vendor relationship that involves a third-country transfer may need both instruments doing different jobs.
Common gaps in vendor paper
Most vendor DPAs cover the Article 28(3) list nominally. The gaps are usually in the conditions attached to each clause rather than in outright omissions.
- Sub-processor notice that is technically present but practically weak: changes announced only on a web page the customer must poll, or objection windows too short to run a real assessment.
- Audit rights reduced to reading the vendor's reports, with on-site or independent audit available only in circumstances that never quite occur.
- Assistance duties that exist but are chargeable, slow, or routed through support queues with no committed timelines.
- Deletion commitments without deadlines, without coverage of backups, or without a certification the controller can put in its records.
- Instructions defined so broadly that the vendor's own product decisions count as the controller's instructions.
- Precedence clauses under which the service terms override the DPA in conflict — quietly inverting the hierarchy the GDPR assumes.
- Subprocessor lists incorporated by reference to a URL, with no commitment about how changes to that page are communicated.
None of these gaps is exotic, and few are deal-breakers on their own. The point of a structured review is to find them before signature, price them into the risk decision, and document what was accepted and why.
Frequently asked questions
Do we need a DPA with every vendor?
You need one with every vendor that processes personal data on your behalf — that is what triggers Article 28(3). Vendors that never touch personal data need no DPA, and vendors that use data for their own purposes are controllers, which calls for controller-to-controller terms rather than a processor DPA. The practical first step is a data-flow answer, not a contract template: establish what data the vendor handles and in what role.
Can we just use the Commission's standard clauses from Decision 2021/915?
Yes, if both parties agree — they are designed to be adopted as-is, with the annexes completed to describe the actual processing, security measures, and authorized subprocessors. In practice, most SaaS vendors insist on their own DPA, so the clauses more often serve as a negotiation benchmark than as the signed text. Either way, filling the annexes accurately is where the real work lives; empty or generic annexes undermine the clauses' value.
Who signs the DPA with a subprocessor?
The processor does. Article 28(4) requires the processor to impose the same data protection obligations on its subprocessor through its own contract; the controller is normally not a party to that agreement. The controller's protections are the authorization right under Article 28(2), the flow-down requirement, and the rule that the initial processor remains fully liable to the controller for the subprocessor's performance.
What happens if processing runs without a DPA?
Processing by a processor without the Article 28(3) contract is an infringement by both parties of their respective obligations, and Article 83(4) places breaches of Article 28 in the fine category reaching up to 10 million euros or up to 2 percent of total worldwide annual turnover, whichever is higher. Beyond fines, the missing contract usually signals missing substance — no documented instructions, no agreed security baseline, no breach-notice route — which is the larger operational risk.
Where DPAFlow fits in
A DPA review is a snapshot; the relationship it governs keeps moving. DPAFlow monitors vendor DPA pages, subprocessor lists, and trust-center pages on a scheduled, recurring basis, detects changes, and preserves dated evidence — captured page text, diffs, and screenshots where available — so your team can tie what was signed to what the vendor's pages actually said over time, and export that history when a review or audit asks for it.
If your legal team runs vendor data protection reviews, the DPAFlow legal use case shows how monitored evidence supports the contract lifecycle.