Data Processing Addendums for Small Vendors: The Consent Clauses That Do the Work
Enterprise vendors arrive with a legal department and a DPA portal. The twenty person analytics tool, the niche booking widget, and the freelancer built plugin arrive with a terms link and good intentions.
Consent data flows to all of them alike: identifiers, choices, timestamps. If a regulator asks who processed that data and under what terms, 'they seemed trustworthy' is not a processing record.
The four clauses, in plain terms
Purpose limitation says the vendor processes personal data only on your documented instructions, which is what makes them a processor and not a second controller freelancing with your users' data. The sub processor clause lists who else they pass data to, cloud hosts, support tools, email relays, and obliges them to tell you before that list changes, because their sub processor is your disclosure problem.
Deletion at termination needs a number: data returned or deleted within a stated number of days after the contract ends, with written confirmation. Breach notice needs a number too, and it should be hours or a small number of days, because your own notification clock to regulators starts when you learn of the incident, and a vendor who sits on it for two weeks spends your deadline for you.
Right size the ask for small vendors
A two page addendum in plain language gets signed by small vendors. A thirty page enterprise document gets routed to a mailbox nobody reads. Cover the four clauses, confidentiality, basic security measures appropriate to the data, and cooperation with data subject requests, since opt out and deletion requests will involve their systems whether the contract says so or not.
If a vendor will not sign anything, the decision is a risk decision and should be recorded as one: what data they receive, minimized to the least the integration can run on, and who accepted the residual risk. Some tools are worth it. None are worth it undocumented.
Keep the register, not just the PDFs
DPAs in a folder nobody can search are compliance theater. Maintain a vendor register: vendor, data categories, purposes, DPA status and date, sub processor list checked on, deletion terms. When a consent record names a purpose, you should be able to walk from that purpose to every vendor that touched it, on one screen, without archaeology.
Related reading
These earlier guides cover connected questions in more depth: Global Privacy Control in Mobile Apps: The Signal Most Teams Forget, Data Processing Addendums for Small Vendors: The Consent Clauses That Do the Work, and Consent Receipts: What a Good One Should Contain.
Frequently asked questions
Do we need a DPA with every vendor that touches our site?
Any vendor processing personal data on your behalf needs one: analytics, consent tooling, chat, booking, email, and embedded tools that receive identifiers. Pure infrastructure with no personal data access is the narrow exception.
What if a small vendor refuses to sign our DPA but offers theirs?
Read theirs against the four clauses: purpose limitation, sub processors, deletion at termination, breach notice timing. A short vendor DPA that covers those beats no agreement. Gaps go in the risk register with a named owner.
How quickly must a vendor tell us about a breach?
Fast enough for you to meet your own duties, which in many regimes means you need their notice within days at most. Contracts commonly set 48 to 72 hours. An open ended 'without undue delay' from a tiny vendor is a prompt to test their incident contact before you need it.
What happens to consent data when we leave a vendor?
The DPA should say: return or deletion within a set period, with confirmation. That clause is why migration planning starts before cancellation; consent proof for the period they processed has to survive the relationship.