Reviewing a Vendor's DPA: Red Flags Before You Sign
Most vendor DPAs get accepted without a real read-through. Here are the specific red flags worth actually stopping on before you click accept.
Most people accept a vendor’s DPA the same way they accept terms of service, by scrolling to the bottom and clicking through. That’s usually fine for well-established vendors with standard templates, but a few specific red flags are worth actually stopping to read for, since they’re the ones most likely to create real liability later.
Red flag 1: no DPA available at all
If a vendor processes personal data on your behalf and doesn’t have a DPA available, published or on request, that’s the most basic and most serious gap. Ask directly, and treat “we don’t have one but can look into it” as a real signal about how seriously the vendor takes this, not just an administrative gap.
Red flag 2: vague sub-processor language
“We may use third-party service providers to help deliver our services” with no list, no notification mechanism, and no flow-down obligations is a common pattern in weaker DPAs. See our sub-processor guide for what a real clause should include.
Red flag 3: no end-of-contract data deletion commitment
If the DPA doesn’t specify what happens to your data when the relationship ends, deletion within a defined window, or return of data on request, you have no contractual basis for insisting the vendor actually get rid of it. This is one of the most frequently missing provisions we’ve seen.
Red flag 4: broad, undefined processing purposes
A DPA that lets the vendor process data for open-ended purposes (“to improve our services and other business purposes”) rather than the specific purposes tied to the contracted service is a sign the vendor may be using your data more broadly than you’d assume, for example, training models or building aggregate products.
Red flag 5: no security specifics
“We maintain appropriate technical and organizational measures” with zero further detail, no reference to encryption, access controls, a SOC 2 report, or an ISO 27001 certification, is thin. Reputable vendors usually have specific security documentation to reference or link to.
Red flag 6: liability terms that don’t match the risk
Some vendor contracts cap total liability at a token amount (a few months’ fees) regardless of the sensitivity of the data involved. That’s not unusual for low-risk relationships, but worth noticing specifically if the vendor handles sensitive categories of data.
CookieYes
Run this same checklist against your consent platform's own DPA, since it's a processor of your visitor data too. CookieYes publishes a standard DPA with defined sub-processor terms and deletion commitments as part of its documentation, worth using as a reference point for what a reasonably complete DPA looks like.
What to actually do when you spot one
Not every red flag is a dealbreaker. For a low-risk, low-data-volume vendor, documenting the gap and moving on with a lower-priority follow-up is often proportionate. For a vendor handling sensitive or high-volume personal data, raise it directly, ask if a more complete version exists, request the specific missing provision, or consider whether the relationship is worth the residual risk.
The bottom line
A DPA existing isn’t the same as a DPA being adequate. These six patterns are the ones most likely to turn “we have a signed DPA” into a real gap if a request, audit, or incident ever tests it.
This guide is educational and not legal advice. For your specific vendor contracts, consult a privacy attorney.