12 Article 28 clauses: GDPR DPA requirements for privacy teams

Yes: when an organization outsources processing of personal data to a third party, Article 28 of the GDPR requires a written data processing agreement, and that agreement must cover the scope of processing, processor obligations, security measures, sub-processor rules, breach handling, data return or deletion, and audit rights. This article converts that legal text into a working checklist, with sample phrasing for each clause.

---

TL;DR:

• Clear roles must be established, as controllers need a signed DPA before assigning processing tasks, while processors must flow obligations down to sub-processors.
• DPAs must include specific clauses on data scope, purpose, data types, controller rights, instructions, confidentiality, security, sub-processors, breach handling, and end-of-contract data return or deletion.
• Vendors should be evaluated against this checklist, with evidence like ISO 27001 or SOC 2 reports, and flagged risks or gaps must be escalated before signing.
• Sub-processor relationships are best managed with explicit approval rights, requiring notice periods and flow-down of Article 28 obligations.
• Security measures in DPAs must specify concrete controls like encryption, access controls, and regular testing, with breach notices typically mandated within 48 to 72 hours.

---

Table of Contents

• Who actually needs a gdpr DPA requirements checklist
• The Article 28(3) clauses your DPA cannot skip
• A practical checklist and sample clause phrasing
• Sub-processor authorization: specific approval versus general consent
• Security, breach response, and what happens when the contract ends
• International transfers and where SCCs fit into the DPA
• How privacy teams turn this checklist into a repeatable review
• Prioritize the vendors that can actually hurt you
• Sources
• FAQ

Who actually needs a gdpr DPA requirements checklist

If your company decides why and how personal data gets processed, you're a controller. If a vendor processes that data on your instructions, that vendor is a processor. A payroll platform, a customer support tool, an analytics provider like Matomo, a cloud hosting service: all of these are processors the moment they touch personal data on your behalf.

The obligation runs one direction first: controllers must have a signed DPA in place before handing data to any processor. But processors carry weight too. They're required to enter into the agreement and to flow the same obligations down to any sub-processor they use.

A few situations trip people up:

• Joint controllers (two companies jointly deciding processing purposes) need an Article 26 arrangement, not a standard DPA.
• Processor-only vendors with no independent decision-making power over data still need a DPA, even if the relationship feels informal.
• Free-tier or trial software counts too. If personal data flows through it, the DPA requirement doesn't pause for a pilot.

Before you sign anything, confirm which role each party plays. Getting that wrong reshapes every clause that follows.

The Article 28(3) clauses your DPA cannot skip

Article 28(3) lists specific items a processing contract "shall stipulate." Treat this as your baseline, not a suggestion.

1. Subject matter and duration of processing. State what the processor does with the data and for how long. Vague phrasing like "as needed for services" fails here; name the activity (payment processing, email delivery, ticket support).
2. Nature and purpose of processing. Describe the actual operations: storage, analytics, transmission. Purpose creep is the most common gap. If the vendor later uses data for a new purpose, the DPA should require your written approval first.
3. Type of personal data and categories of data subjects. List data types (names, IP addresses, health data) and who they belong to (employees, customers, site visitors). This scope statement anchors every downstream obligation.
4. The controller's obligations and rights. Your right to issue instructions, audit, and terminate must be explicit, not implied.
5. Processing only on documented instructions. The processor cannot decide on its own to use data differently. The ICO's guidance treats this as the clause most often written too loosely.
6. Confidentiality commitments covering everyone with data access, including contractors.
7. Appropriate security measures, tied to Article 32 (covered in detail below).
8. Sub-processor rules, addressed separately in the sub-processor section of this guide.
9. Assistance with data subject rights requests (access, deletion, portability).
10. Breach notification duties, with a clear timeline.
11. Deletion or return of data at contract end.
12. Audit and inspection rights for the controller.

Pro Tip: Watch for DPAs that copy Article 28 headings but leave the substance thin, "processor shall implement appropriate security" with no named controls, or "processor shall assist controller" with no timeline attached. A heading is not a commitment.

A practical checklist and sample clause phrasing

Reviewing a vendor DPA works best as a repeatable routine, not a fresh legal analysis every time. Five steps cover most cases:

• Intake: log the vendor, the data types involved, and a rough risk tier (low, medium, high).
• Clause mapping: check the draft against the Article 28(3) list above, item by item.
• Evidence request: ask for a current ISO 27001 certificate or a recent SOC 2 report rather than taking security claims at face value.
• Risk flagging: note anything that shifts liability onto you or leaves obligations undefined.
• Approval or escalation: route high-risk gaps to legal or security leadership before signing.

Vendor-drafted DPAs often arrive with boilerplate worth pushing back on: liability caps set too low relative to the data at stake, broad "processor may engage any sub-processor" language with no notice requirement, or deletion clauses that say data will be "removed" without a timeline or method.

Sample phrasing for breach notification: "Processor shall notify Controller without undue delay, including the nature, scope, and remediation steps taken." For deletion: "Upon termination, Processor shall delete or return all personal data within a reasonable timeframe and provide written certification of deletion upon request." Gdpr is a solid starting reference if you're building this language from scratch, and A DPA template and checklist is available that walks through the same clauses with editable wording.

Sub-processor authorization: specific approval versus general consent

Two models govern how processors bring in sub-processors, and picking the wrong one creates real friction later.

Specific authorization means the processor names each sub-processor and you approve individually. It gives you tighter control but slows down every vendor change and rarely scales past a handful of relationships.

General authorization lets the processor add sub-processors freely, as long as it notifies you and gives you a window to object. This is the more common approach for SaaS relationships, and it works fine as a default unless you're dealing with a high-risk processing activity, where specific approval is worth the friction.

• Require at least 14 to 30 days' notice before a new sub-processor goes live.
• Build in a genuine objection right, not just a notification formality.
• Confirm the processor flows down equivalent Article 28 obligations to every sub-processor and stays liable for their performance.

Security, breach response, and what happens when the contract ends

Article 32 sits alongside Article 28 and defines the technical bar. Expect the DPA to name concrete measures: encryption in transit and at rest, access controls, regular backups, and periodic resilience testing, not just a promise to "maintain security."

Breach notification language should specify a timeline (48 to 72 hours is standard practice), required content (scope, affected data categories, remediation steps), and an obligation to cooperate with your own regulatory notifications under Articles 33 and 34.

The processor also owes you operational support beyond incident response:

• Reasonable assistance with data subject access, deletion, and portability requests.
• Cooperation on Data Protection Impact Assessments under Article 35 when processing is high-risk.
• Audit rights that are actually usable, not theoretical: agree upfront on scope, frequency, and who pays.
• End-of-contract terms specifying deletion or return within a set timeframe, with written certification.

Pro Tip: Ask every high-risk vendor for their most recent third-party audit report before you finalize the DPA. A vendor that hesitates to share one is telling you something about their actual posture, regardless of what the contract says.

International transfers and where SCCs fit into the DPA

If a processor or sub-processor sits outside the jurisdiction covering your data, the DPA needs a transfer safeguard, most commonly the standard contractual clauses. SCCs come in modules depending on the roles involved (controller to processor, processor to processor, and so on), and picking the wrong module is a common drafting error.

The European Commission's Q&A on the new SCCs makes clear that Annexes must be completed accurately and that unauthorized edits to the clause text can invalidate the entire safeguard.

• Confirm which SCC module matches each party's actual role before attaching it.
• Fill in every Annex field (data categories, transfer purposes, technical measures) rather than leaving placeholders.
• Avoid rewriting SCC language to fit house style. Attach it as an addendum instead.

How privacy teams turn this checklist into a repeatable review

Most delays in DPA review come from manual clause hunting, not disagreement over terms. A workable process starts with intake: log the vendor, the data categories, and a risk tier the moment the contract lands. From there, run the draft against the Article 28 checklist rather than re-deriving it each time.

Contract review software that applies a standing playbook, flagging missing clauses, inconsistent redlines, and requesting ISO or SOC evidence automatically, cuts the review cycle from days to hours. Formable's AI contract review tool does this by checking incoming DPAs against saved playbooks and surfacing gaps before a human ever opens the document. Keep a version history and signed archive for every DPA. When a regulator or auditor asks who approved what and when, that record is what answers the question.

Prioritize the vendors that can actually hurt you

Most compliance teams try to review every DPA with the same intensity, and that's a mistake. A payroll processor handling sensitive employee data deserves far more scrutiny than a low-volume marketing tool that never touches personal data directly. Spend your audit hours where the risk actually sits.

The bigger failure mode isn't a bad clause, it's having no record of why you approved a vendor in the first place. Adopt one standard DPA template, track amendments in one place, and automate what you can. Six months from now, when someone asks for proof, you want an answer in seconds, not a scramble through email threads.

— Alex

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Art. 28 GDPR Processor
• What needs to be included in the contract? | ICO
• Gdpr
• European Commission’s Q&A on the New Standard Contractual Clauses | Mayer Brown

FAQ

Does the GDPR require a DPA?

Yes. Article 28(3) requires a written contract whenever a processor handles personal data on behalf of a controller, and it must include specific mandatory clauses covering scope, security, sub-processors, and deletion.

What are the 7 GDPR requirements?

There's no single official "7 requirements" list, but the core Article 28(3) obligations commonly grouped this way are: processing only on documented instructions, confidentiality, security measures, sub-processor management, assistance with data subject rights, breach notification, and deletion or return of data at contract end.

Is GDPR compliance mandatory in the USA?

GDPR applies to any organization, regardless of location, that processes personal data of individuals in the European Union or European Economic Area, so US companies serving those individuals must comply even without a physical EU presence.

What is GDPR and DPA?

The GDPR is the European Union's data protection regulation, and a DPA (data processing agreement) is the written contract it requires between a controller and a processor whenever personal data is processed on the controller's behalf.