LegalFree
Data Processing Agreement Review Checklist
River reads the DPA against your own retention windows, incident timings and system list, then names every commitment the company cannot actually keep.
Every DPA checklist walks the same eight obligations and asks whether the contract mentions them. That check passes on paper and tells you nothing, because a clause can be present, well drafted and impossible for your company to perform. River reads the agreement the other way around. Each commitment is put next to the retention window, the incident timing or the system count that would have to be true for the promise to hold, and the difference between them is the finding.
The output is an obligation register by data category, one row per commitment, carrying the clause, the measured capability and the gap. Some of those gaps are already false the moment the pen moves. A thirty-day deletion promise against a warehouse holding twenty-four months is wrong on the day of signature, whatever happens afterwards. Others only bite once something occurs, which is a different conversation with a different owner, and the register keeps the two apart.
Privacy counsel and whoever owns the vendor form both run this, usually before a renewal or after an engineering change moved a retention setting nobody logged. It reads a DPA the way a register keyed to the date somebody has to act reads a master agreement, and the positions it settles go into the playbook the next reviewer works from. What comes back is not a redline. It is the list of promises somebody would have to change a system to keep.
Present is not the same as performable
Article 28 is a list of eight things the contract has to stipulate, and only one of them is about security. The processor must delete or return all the personal data at the end of the service and delete existing copies, assist with requests from data subjects, and allow for and contribute to audits. Every checklist on the subject confirms those clauses exist. None asks whether the backups expire inside the window the deletion clause has just promised.
The most regulated version of this contract already admits the problem. A business associate agreement has to require return or destruction of all protected health information at termination. The rule then says what to do when that is not feasible: extend the protections of the contract to what stays and limit further use to the purposes that make return or destruction impossible. A DPA drafted from a checklist carries no such valve. It promises deletion, and the backup schedule keeps running.
Breach clocks are where drafting and operations diverge fastest. The regulation gives the processor no fixed number: it notifies the controller without undue delay after becoming aware, while the controller's own clock runs to seventy-two hours. Vendor forms routinely promise twenty-four. Vantry Health measured 3.1 hours from alert to triage and 27.5 more to confirmed scope, so a clock that starts at the alert is 6.6 hours late on the median incident before anyone has done anything wrong.
How it works
Hand over both sides
The agreement or your own vendor form, plus what your systems and subprocessors actually do.
Commitments get listed
Each promise is pulled out with its clause and the data categories it reaches.
Capabilities get measured
Retention windows, incident timings and system coverage are read from what you supplied.
The gaps get numbers
Each mismatch comes back with the difference, in days, hours or systems, and an owner.
What you get
- One row per commitment, carrying the clause and the capability that has to support it
- Retention promises checked against the backup window and the warehouse, not the policy
- Breach clocks measured against your own time from first alert to confirmed scope
- Deletion requests costed across every system holding the category, including those without an API
- Gaps split into the ones already false at signature and the ones waiting on an event
- Audit rights multiplied by the customer count, so the grant carries a headcount
Common questions
We are signing the customer's paper. Does this still help?
That is the harder direction and the more useful run. On your own form you can change the sentence. On theirs you have to know precisely which clauses you would be signing falsely, so the redline is short, specific and defensible. A vague objection to a deletion clause loses. A measured retention window with a proposed substitute usually does not.
What counts as your data map?
Whatever you actually have, and it is usually less than people expect. A system inventory, retention settings, the subprocessor list, and any incident timings you have recorded is enough for a first pass. Where a number is missing, the row says so rather than assuming one, because an invented capability is worse than an acknowledged blank.
Is this legal advice about GDPR compliance?
No. It compares what a document says against what you told it your systems do, and shows the arithmetic. Whether a gap is a compliance problem, a commercial risk or a rounding error is a judgment your counsel makes. What changes is that the judgment is made on measured facts rather than on how the clause reads.
Our engineering setup changes constantly. Does the review go stale?
It does, and that is the point of keeping the register rather than the memo. Each row names the system and the setting it depends on, so a retention change on one pipeline shows which signed commitments it just touched. Re-run it at renewal, or whenever somebody changes a number the register cites.
How is this different from a clause-by-clause playbook?
A playbook tells you the position to take. This tells you which positions you can hold. They work together: once a gap is settled the language belongs in your standard positions, and the wider commercial review of the same vendor is a separate pass over term, liability and termination.
What about the negotiation itself?
That is the next job and a different one. Once you know which commitments are real, the exchange of markups has its own failure mode, which is a change accepted quietly across versions. Comparing what came back against what you sent catches the clause that moved while everyone argued about the security annex.
Does it handle the security annex?
Yes, and the annex is where the false promises concentrate. Encryption modes, key custody, logging retention and access review frequency are all specific claims about specific systems. Each one is checked against the system list the same way as the clauses, and an annex item you cannot evidence comes back as a gap rather than as a formatting note.
Data Processing Agreement Review Checklist
Fill in the form and your workspace opens with the work already underway.