· Yair Knijn
A DPA register for your SaaS stack: tracking the agreements you already signed
Search for any SaaS product's name plus "data processing agreement" and you will find the document — HubSpot has one, Hootsuite has one, every vendor with EU customers has one. That is not the hard part. The hard part is the aggregate: a mid-sized company runs dozens of SaaS tools, each processing some personal data, each under its own DPA, each of which the vendor updates on its own schedule. Signing was a moment; staying on top of what you signed is an operating task most organisations have quietly skipped.
What a DPA actually pins down
GDPR Article 28(3) requires a contract whenever a processor handles personal data on a controller's behalf, and it prescribes the content: the subject matter and duration of processing, its nature and purpose, the types of personal data and categories of data subjects, documented-instructions-only processing, confidentiality commitments, security measures under Article 32, the subprocessor regime, assistance with data subject rights and breach obligations, deletion or return of data at the end of the relationship, and audit rights. Modern SaaS DPAs also carry the international transfer mechanism — standard contractual clauses or an adequacy arrangement — and, critically, a subprocessor list that the vendor may change with a notice period.
Each of those clauses is a live commitment with your name on one side. When a customer, supervisory authority, or auditor asks "where does this data go and under what terms", the DPAs are the answer — if you can find them and they are current.
Why the folder of PDFs fails
Three things move after signature. Vendors revise their DPA terms — usually by posting a new version and deeming continued use as acceptance, which means the document in your folder is no longer the document in force. Subprocessor lists change on notice windows of often 30 days, within which you hold an objection right that expires whether or not anyone read the email. And your own usage drifts: the tool that processed only names at purchase now holds support tickets full of customer data, so the data categories in the signed DPA no longer describe reality. A static archive captures none of this. We wrote about the signature-day snapshot problem in the DPA signed once and never revisited, and about what happens when a subprocessor change breaks a promise you made downstream in the data residency claim the subprocessor broke.
What the register records
A working DPA register is a table with an owner, not a folder. Per vendor: the DPA version and date actually in force, a link to the vendor's canonical DPA and subprocessor pages, the categories of personal data and data subjects processed (as used today, not as guessed at purchase), the transfer mechanism relied on, the subprocessor-change notice period and where those notices arrive, deletion and return terms with any retention carve-outs, and the date someone last reviewed all of the above. The review cadence matters more than the schema — annually per vendor as a floor, plus event-driven reviews whenever a subprocessor notice lands or the tool's use changes.
The register also has a second life: it is most of the processor section of your Article 30 records of processing, it feeds vendor risk reviews, and under DORA-adjacent scrutiny it overlaps heavily with the ICT third-party register — a shape we covered in maintaining DORA registers of information under Article 28. One dataset, three obligations, which is precisely the argument for maintaining it properly once instead of reconstructing it three times under deadline.
Review the legal specifics with your data protection officer or legal counsel — a register is an operating record, not legal advice. And if you are evaluating vendors: ours is at spot-suite.com/dpa, subprocessors and all, which is exactly the transparency you should demand from every processor in your stack.