What to actually check in a DPA before signing it

Most DPAs get signed unread. Someone in procurement confirms the document exists, checks the box, and moves on. That's understandable, they're long and repetitive, but it wastes the one moment you have leverage. A DPA checklist doesn't require a lawyer to apply: GDPR Article 28 dictates most of what has to be in the document, so reviewing one is mostly confirming eight specific clauses say what they must say, concretely rather than vaguely.

The eight clauses to check

• Roles: you are named the controller, the vendor the processor, and the DPA states the processor acts only on your documented instructions. If the vendor claims controller status over your recipient data, stop and ask why.
• Subject matter and duration: what data is processed (for email: recipient addresses, message content, event metadata) and for how long. "For the duration of the service" is fine; no duration at all is not.
• Data location and transfers: where processing happens, and the legal mechanism for any transfer outside the EEA. "EU by default" should be written down, not implied by the vendor's marketing site.
• Subprocessors: the vendor may only engage them under terms no less protective than the DPA itself, and you get advance notice of changes with a right to object. Check the notice period is a number (30 days is common), not "reasonable notice."
• Security measures: a concrete list (encryption in transit, access controls, audit logging), not "appropriate technical and organisational measures" restated without content.
• Deletion on termination: personal data is deleted or returned when the contract ends, on a stated timeline, except where law requires retention. Bonus if it references your configured retention settings rather than a vendor-chosen default.
• Breach notification: the processor notifies you without undue delay after becoming aware of a breach, with enough detail to meet your own 72-hour obligation to the supervisory authority.
• Audit rights: you can verify compliance, at minimum through documentation and third-party attestations. Full on-site audit rights are rare below enterprise contracts; documented evidence on request is the realistic floor.

Wording that should make you push back

Three patterns come up again and again. "Processor may transfer data as needed to provide the service" with no named mechanism: that's a blank cheque on residency. "Subprocessors may be updated from time to time" with no notice obligation: you'll find out about the new subprocessor when a customer asks you about it. And any security section that's shorter than the limitation-of-liability section: the vendor's lawyers spent their effort protecting the vendor, not your data.

How the checklist maps to Envello's DPA

We wrote about how Envello's DPA works in "How to get a signed DPA without a sales call": it's generated at signup on every plan, including free. Against this checklist, it names Envello as processor, scopes processing to email content and recipient metadata, commits to EU processing (AWS eu-central-1, Frankfurt) with no transfer outside the EEA in the ordinary course of the service, binds subprocessors to terms no less protective with 30 days' notice of changes, lists concrete security measures, and ties deletion on termination to your configured retention window of 7 to 365 days.

One honest gap: the current subprocessor list isn't published on the site, it's available on request. If your review process wants the list attached to the DPA, request both together rather than assuming they're bundled.

Ten minutes, once

A DPA review with this checklist takes about ten minutes per vendor, and you only redo it when the vendor issues a new version. That's cheap insurance for a document that, in a real incident or a real audit, is the first thing anyone asks to see.