A Data Processing Agreement is the contract that governs how a vendor processes personal data on behalf of its customer. It is the operational document Article 28 of the GDPR demands. It sits underneath the MSA and gets re-pointed every time a vendor's posture changes.
Every defensible DPA covers the same load-bearing items. It identifies the categories of personal data and data subjects in scope. It pins down the purpose and duration of the processing. It commits the processor to act only on documented instructions from the controller. It spells out the security measures, the notification mechanism for data breaches, and the procedures for data-subject requests. It addresses cross-border transfers, including the legal mechanism the parties rely on (Standard Contractual Clauses, the UK addendum, an adequacy decision, or some combination). And it lays out how the relationship ends: return of data, deletion timelines, audit rights.
The recurring drafting trap is treating the DPA as boilerplate. Vendors paste in a generic template, customers sign without checking the sub-processor list it points to, and six months later a regulator or a procurement audit asks for evidence that the named sub-processors are still the ones in use. The DPA is the artifact that gets pulled in those moments. It needs to be accurate, current, and defensible at audit.
For SaaS vendors, a clean DPA on the website that buyers can review pre-contract is one of the highest-leverage moves available. It removes a friction point in enterprise procurement and signals that the vendor takes its Article 28 obligations seriously enough to publish them.