Only some. The test is whether the vendor processes personal data on your behalf, which makes them a processor under Article 28 and makes a contract mandatory. Vendors who never see personal data need nothing. Vendors who decide their own purposes are separate controllers and need something different. Sorting your supplier list into those groups takes an afternoon and removes most of the uncertainty.
This article covers the test itself, the four categories every vendor list splits into, the suppliers people wrongly include, the ones they wrongly leave out, and how far down the chain the obligation reaches.
The Test Is Processing On Your Behalf
Article 28(1) frames it plainly: where processing is to be carried out on behalf of a controller, the controller uses only processors providing sufficient guarantees. Article 28(3) then requires the relationship to be governed by a contract or other legal act containing a specific set of terms.
Two conditions have to hold. There must be personal data, and the vendor must be handling it for your purposes rather than their own. Spending money with a supplier is irrelevant. So is the size of the contract, and so is whether the vendor is a technology company.
The most useful reframing is to stop asking "is this a big enough vendor to need paperwork" and start asking "if this vendor did something unexpected with the data, would I be the one who had to explain it." Where the answer is yes, they are processing on your behalf. The canonical DPA guide covers what a DPA contains and sets out the controller, processor and joint-controller roles in the abstract. What follows here is the applied sorting exercise: the suppliers people wrongly include, the ones they wrongly leave out, and how to find the ones nobody registered.
The Four Categories Your Vendor List Splits Into
Processors. They hold or handle personal data for your purposes: hosting, email delivery, CRM, support desk, analytics, error tracking, payroll software, backup providers. Article 28 contract required.
Independent controllers. They receive personal data but decide their own purposes and carry their own obligations: your bank, your accountant, your auditor, your law firm, an insurer. No DPA — you are not instructing them, and asking them to sign one misdescribes what they do.
Joint controllers. You and the vendor genuinely determine purposes and means together. Rarer than it is invoked, and where it is real, Article 26 requires a transparent arrangement setting out respective responsibilities rather than an Article 28 contract. Co-marketing arrangements and some embedded-partner integrations land here.
No personal data. Your CDN serving static assets with no logs reaching you, a design tool holding no customer records, a monitoring service that only sees aggregate metrics. Nothing required, but check rather than assume — most of these do log something.
The categories are not stable over time. A tool that started as category four moves to category one the day someone enables a feature that ingests user identifiers.
Vendors People Wrongly Think Need One
The most common unnecessary request goes to professional services firms. Accountants, auditors and lawyers are independent controllers with their own regulatory duties; they will usually decline to sign a DPA and they are right to.
Banks and payment institutions are the same. A payment processor is often a controller for the transaction data it must retain under financial regulation, even where it is a processor for other parts of the flow, and the position is usually set out in their own terms rather than negotiable.
Landlords, cleaners, utility providers and recruiters that source candidates on their own account also sit outside. So does a vendor whose product genuinely never receives personal data — though that group is smaller than it looks, because "we only send anonymous events" usually turns out to mean pseudonymous ones.
The cost of getting this wrong is not just wasted effort. A DPA signed with a party who is not a processor creates a document that describes a relationship neither side is operating, and that is worse evidence than having correctly concluded none was needed.
Vendors People Wrongly Leave Out
The gaps are more consistent than the false positives, and they cluster in engineering and internal tooling.
Error tracking and session tools capture user identifiers and payload fragments. Internal chat carries customer data the moment support pastes a ticket into a channel. CI and repository providers hold whatever ends up in fixtures and build output. AI and LLM vendors process whatever you send them, which is frequently customer content. Transcription and meeting-notes tools record named individuals saying things. Freelancers and agencies are their own question, and whether a contractor needs a DPA turns on whether they work under your direct authority rather than on their invoice.
The pattern is that these tools are adopted by individual teams on a credit card, without procurement, and they never reach the vendor list. The most reliable way to find them is not a survey but the card statement and the SSO application list, checked against the register you think you have.
Then there is the origin of most of this work. The reason companies build a vendor register at all is usually that a customer asked, and the request typically arrives inside a security questionnaire — which is why understanding what a SIG questionnaire is and why one just landed tends to precede the vendor review rather than follow it.
How Far Down The Chain It Goes
Your obligation is with your direct processors. Their obligation is with theirs. Article 28(2) requires a processor not to engage another processor without your prior specific or general written authorisation, and Article 28(4) requires them to impose the same data protection obligations downstream, remaining fully liable to you if the sub-processor fails.
That is why a subprocessor list matters and why the notification mechanism in a DPA is worth reading. General authorisation with a notice period and a right to object is the standard arrangement, and the practical question is whether you actually receive and review those notices or whether they route to an unmonitored address.
You do not sign contracts with your processors' processors. You do need to know who they are, because your customers will ask, and because the transfer position of a sub-processor two levels down can be the thing that makes your own answer wrong.
Common Mistakes With Vendor DPAs
Sending a DPA to every supplier on the ledger. It burns credibility with vendors who correctly refuse, and it buries the ones that matter. Sort the list first, then send.
Assuming free tools do not count. A free tier processes personal data exactly like a paid one. Free plans are also where you are least likely to find acceptable Article 28 terms, which is a reason to check rather than a reason to skip.
Treating the vendor's published DPA as accepted by default. Most require a positive step — a form, a signature, or acceptance in account settings. An unaccepted published DPA governs nothing, and this is the most common finding in a vendor review.
Never revisiting the classification. Vendors change what they do. A tool that held no personal data at adoption may now ingest user identifiers because someone enabled an integration eighteen months later.
Recording the DPA but not the version or date. When a vendor updates their terms, you need to know which version you agreed to and when. A register entry that says "DPA signed" and nothing else cannot answer the question a buyer eventually asks.
FAQ
Does a vendor who only stores encrypted data still need a DPA?
Yes. Encrypted personal data is still personal data if anyone can decrypt it, and storage is a processing operation under Article 4(2). Encryption is a security measure that improves your position considerably — including under Article 34(3)(a) after a breach — but it does not take the vendor outside Article 28.
What about a vendor outside the UK or EEA?
They still need a DPA, and they need a transfer mechanism as well. Those are two separate requirements and satisfying one does not satisfy the other. Many vendor DPAs incorporate transfer clauses by reference, which is fine, but confirm rather than assume.
Do we need a DPA with our own customers?
Usually the reverse — in a typical B2B SaaS relationship your customer is the controller and you are the processor, so you provide the DPA and they accept it. Where you also process their end users' data for your own purposes, you are a controller for that part and it needs describing separately.
How do we find vendors nobody registered?
Three sources catch most of them: the company card statement, the SSO or identity provider's application list, and DNS or outbound traffic if you have visibility. Ask teams as well, but ask against a list rather than asking an open question, because people do not think of the free tools as vendors.
Closing Thought
The instinct to send a DPA to everyone comes from a reasonable place — it feels like the cautious option, and caution is usually right in compliance work. Here it is not, because the document is a description of a relationship rather than a shield. Signing one with your accountant does not protect you; it records a claim about how you work with them that neither of you is acting on, and that inaccuracy is the thing that reads badly later. The cautious option is actually the accurate one.
The work that makes this tractable is a vendor register somebody keeps current, with a classification and a contract status against each entry. ComplyDog hosts a compliance portal on your own domain with your DPA, an auto-updating subprocessor list, data subject request forms and a security page, and it can handle DPA signing through DocuSign or Dropbox Sign. It does not classify your suppliers or decide which ones are processors — that judgement is yours, and it is the part that takes the afternoon.
