If you’ve already confirmed you need a Data Processing Agreement (see Do You Need a Data Processing Agreement? if you haven’t), the next question is what actually has to be in it. GDPR Article 28(3) lists specific terms a DPA must contain, and a document missing them isn’t a valid DPA no matter what it’s titled. Here’s what each required clause needs to say, and why regulators check for it specifically rather than accepting a general promise to “handle data responsibly.”
Subject Matter, Duration, and Purpose
The DPA has to state, in concrete terms, what processing is happening: the categories of personal data involved (account details, payment information, usage logs), whose data it is (your customers, your employees, your customers’ end users), what the processor is allowed to do with it, and how long the arrangement runs. This isn’t boilerplate. It’s the boundary that determines whether a processor acting outside those terms is in breach of the contract or just doing something the DPA never authorized in the first place, and those are different legal problems with different remedies.
The Subprocessor List and Approval Mechanism
Almost no processor handles data entirely in-house. A payment processor might route fraud checks through a third-party fraud-detection vendor; an email platform might use a separate deliverability service. Each of those is a sub-processor, and Article 28(2) and 28(4) require the DPA to either name them upfront or set out a mechanism for adding new ones, typically advance written notice to the controller with a defined objection window (commonly 14 to 30 days) before a new sub-processor goes live.
A DPA that just says “processor may use sub-processors as needed” without a notice mechanism doesn’t satisfy this requirement. The controller has to retain some ability to know who is actually touching their data and to object before a new vendor is added, not find out after the fact.
Security Measures
The DPA should describe the technical and organizational measures in place: encryption in transit and at rest, access controls limiting which staff can reach the data, and confidentiality obligations for anyone with access. This ties back to Article 32’s general security requirement, but stating it inside the DPA itself, rather than pointing to a separate security page that can change without notice, gives the controller something contractually enforceable rather than a marketing claim.
Breach Notification Timelines
GDPR itself only requires a processor to notify the controller of a breach “without undue delay,” which is vague enough that a well-drafted DPA tightens it to a specific window, commonly 24 to 72 hours from when the processor becomes aware of the incident. That specificity matters because the controller has its own separate 72-hour clock to notify the supervisory authority once it becomes aware of a breach, under Article 33(1). If the processor’s own notice window eats most of that 72 hours, the controller is left scrambling to investigate and report in whatever time remains.
Audit Rights
The controller needs the ability to verify the processor is actually doing what the DPA says, and Article 28(3)(h) requires the DPA to grant that. In practice this happens two ways: a direct audit, where the controller (or someone they hire) inspects the processor’s systems and practices, or a third-party attestation report, most commonly a SOC 2 Type II report, that the processor makes available on request instead of hosting a bespoke audit.
Direct audit vs third-party attestation
| Direct audit | Third-party attestation | |
|---|---|---|
| Who performs it | Controller or a hired auditor | An independent accounting/audit firm |
| Typical frequency | As needed, often limited to once a year | Annual report, shared on request |
| Vendor effort | High: time per customer request | Lower: one report serves every customer |
| Common at | Enterprise, regulated industries | Most SaaS vendors with many customers |
Most established SaaS vendors offer the attestation route by default and reserve direct audits for large enterprise customers with specific compliance requirements. Either is valid under Article 28 as long as the DPA actually grants the right, rather than staying silent on it.
Retention and Deletion at Termination
The DPA has to state what happens to the data when the relationship ends: returned to the controller, deleted, or both, and on what timeline. “Delete data within a reasonable time” isn’t specific enough to be useful in a dispute; a concrete number, deletion within 30 or 90 days of termination, with confirmation provided to the controller, is what a well-drafted DPA states instead. This clause also needs to account for backups, since deleting production data doesn’t automatically purge encrypted backups that may persist for a separate retention period.
International Transfer Terms
If the processor (or one of its sub-processors) stores or processes data outside the EU/EEA, the DPA needs to name the legal mechanism that makes that transfer lawful, most commonly Standard Contractual Clauses. That’s a big enough topic to need its own treatment. See Standard Contractual Clauses vs a DPA for SaaS for how the two documents work together.
Putting It Together
A DPA missing any one of these terms is incomplete even if it’s labeled correctly and both parties sign it, and a one-line mention buried in a terms of service (“we may share data with service providers”) doesn’t substitute for a document a customer’s legal team can actually review clause by clause. Our DPA generator builds a document covering each Article 28 requirement based on your own vendor and sub-processor setup, so you’re starting from a document that already has each of these terms in place rather than checking for gaps after the fact.
