A 40-page data processing agreement lands in your inbox on a deal worth a handful of seats, with a note from the buyer's legal team asking you to sign it as-is. It's tempting to forward it and lose a week, or skim it and say it looks fine.

You won't negotiate it. Legal will. What you can do is understand why the document exists and spot the clauses behind most data processing agreement questions, so the answers you give on calls don't contradict what legal signs later.

The DPA exists because of Article 28 of the GDPR (Regulation (EU) 2016/679 on EUR-Lex). When a processor handles personal data on a controller's behalf, Article 28(3) requires a binding contract covering specific terms. In a SaaS deal your company is usually the processor and the customer is the controller.

Whose paper

Many SaaS vendors publish a standard DPA and prefer customers sign that one, since each custom DPA has to be reviewed and tracked. Some legal teams accept the buyer's paper only above a certain deal size. Find out your company's policy before that 40-page document arrives, so you can tell the buyer on the call whether you'll review their version or send yours.

Subprocessors and the chain of liability

Your company doesn't process data alone. Your cloud host and your support tool touch customer data too, and so may other providers. Under Article 28(2), a processor needs the controller's prior specific or general written authorisation to engage another processor. With general authorisation, the processor has to inform the controller of intended changes and give them the chance to object. That's why vendors publish a subprocessor list and offer change notifications.

Article 28(4) adds the part buyers' lawyers focus on. The same data protection obligations in the DPA must be imposed on each subprocessor by contract, and if a subprocessor fails to meet them, the original processor remains fully liable to the controller. When a buyer asks "who's responsible if your hosting provider has a problem?", that's the answer the regulation gives: you are, towards them.

Keep your company's subprocessor list URL somewhere you can paste it in seconds.

Transfers and deletion

If any subprocessor sits outside the EEA, the DPA needs a transfer mechanism. Standard Contractual Clauses are the usual one; the European Commission issued modernised SCCs on 4 June 2021 (Commission SCC page). US vendors certified under the EU-US Data Privacy Framework may rely on that instead, as covered in our post on cloud vs on-prem buyer questions.

Article 28(3) also requires the processor, at the controller's choice, to delete or return personal data when the service ends, and to make available the information needed to demonstrate compliance, including allowing for audits. Buyers turn that into practical questions: can we export everything, in what format, and when is it gone from backups? Export is usually a product answer you can give. Audit requests are often satisfied with your SOC 2 report.

The breach-hours trap

This is the clause most likely to go wrong on a call. A buyer's DPA will often ask the processor to report any breach within 24 or 48 hours. Reps sometimes agree, thinking it matches the law.

It doesn't. Article 33 of the GDPR gives the controller 72 hours, where feasible, to notify the supervisory authority after becoming aware of a breach. The processor's duty is to notify the controller "without undue delay." The regulation sets no fixed number of hours for the processor at all. A 24- or 48-hour figure is the buyer trying to protect their own 72-hour deadline, which is reasonable, but it's a negotiated commitment your security team would have to meet every time. Say "we notify without undue delay, and our DPA sets out the process" and nothing more specific than that.