Do you need a DPA with every vendor? Sort your list into three groups first.

An engineer on your team adds error monitoring on a Tuesday afternoon. Install the package, paste a key, deploy. By the evening the tool is collecting stack traces, and some of those traces carry the request that caused the crash, including the email address of whoever was signed in when it broke.

That vendor is now handling your users' personal data for you. GDPR wants a written contract in place before that starts. Nobody raised a purchase order, nobody sent anything to legal, and the vendor's name is missing from the sub-processor list you publish, the one the next enterprise buyer will ask you to stand behind.

Somewhere else in the same company, a signed data processing agreement sits in a folder with the firm that audits the books, which takes nobody's instructions on how to audit and decides for itself what it needs to collect and how long to keep it.

So, do you need a data processing agreement with every vendor? No. You need one with the vendors that are your processors. Working out which ones those are is a different exercise from collecting signatures, and doing it tells you which of the signatures you already have mean anything.

Which vendors does GDPR require a contract with?

The ones acting on your instructions. Article 28(3) requires that any processing carried out by a processor is governed by a contract between you and them. It has to be in writing, and electronic form counts, so the processing terms you accepted with a click at signup can be that contract, provided they cover what Article 28(3) lists 1.

What triggers the duty is the role. It does not depend on how much you pay them, how big they are, or whether personal data was the point of the purchase. If they handle personal data on your behalf, you need the contract. If they do not, Article 28 has nothing to say about them, and a DPA is the wrong document to be chasing.

How do you tell a processor from a vendor that decides for itself?

Ask who determines the purposes and the means. That phrase comes from GDPR's definition of a controller: the party that determines why personal data is processed and how. A processor handles the data on the controller's behalf, and takes its purposes from you rather than setting its own 1.

What each party does settles the role. The European Data Protection Board, the EU body whose guidance national data protection regulators work from, puts the consequence plainly: if one party in fact decides why and how personal data are processed, that party is a controller even if a contract says it is a processor 1.

Sending a vendor your DPA template does not make them your processor, and signing someone else's does not stop you being a controller.

The gap between what the contract says and what the vendor does also opens where the data handling is incidental to the service. Not every supplier that touches personal data while delivering a service is a processor. Where the service is not specifically aimed at processing personal data, or where that processing is not a key element of what you are buying, the supplier may be determining the purposes and means itself, and is then a separate controller rather than your processor 1. An accountant, a law firm, and a payment provider running its own fraud and anti-money-laundering checks all tend to land here. They hold data about your users or your staff, and they decide for themselves what to do with it, under obligations of their own that you cannot instruct away.

What are the three groups, and what does each one need?

Sort by what is being done with the data, not by company name. The role attaches to a processing activity, so the same vendor can hold two of them at once: a payment provider is your processor for the charge you told it to make, and a controller in its own right for the fraud and anti-money-laundering checks it runs on top of it. My advice is to let a vendor appear on two rows rather than force it onto one.

Processors get the Article 28(3) contract. Most of your infrastructure sits here: hosting, the managed database, email delivery, background job runners, a product analytics tool that reports only to you, and the model API behind an AI feature when it handles your inputs on your instructions and nothing else.

Being a processor does not mean deciding nothing. Practical implementation choices, such as which software to run and the detailed security measures, can be left to the processor 1, so your host picking its own storage layout does not promote it to a controller. What stays with you is the purpose, and the scope that follows from it: which data, for how long, and who gets access.

Separate controllers do not get a DPA, and handing them one records a relationship that is not there. What you owe instead is a lawful basis for disclosing the data at all, and an account of that disclosure in your privacy policy. GDPR asks for the recipients or the categories of recipients, and the EDPB's position is that this should be as specific and concrete as you can make it, with named recipients generally the most useful thing a reader can be given 2.

Joint controllers are the group most likely to be misfiled, and the usual trigger is a marketing tag rather than infrastructure. Add a conversion pixel to your site and you are collecting visitor data together with the platform: you get your numbers, and the same collection feeds the platform's own advertising business. That is what separates it from the analytics tool in the processor row, which reports to you and nobody else. The EU's top court, the Court of Justice, reached that result for a site embedding Facebook's Like button: the site had a decisive influence over the visitor data the button collected and sent, and so determined the means of that collection jointly with Facebook 1. Meta's own business tools terms say as much: install the pixel and you have accepted a controller addendum naming you and Meta joint controllers for what it collects, and making it your job to tell your users. Article 26 asks for an arrangement saying who does what 1, and for a pixel that is the platform's terms you accepted at setup plus a line in your privacy policy naming the platform and what it receives. A DPA does not satisfy it, because it describes a relationship of instruction that neither of you is in. If you run tag manager, that is the box to open first.

Where a vendor keeps the data is a separate question with its own contract, usually the standard contractual clauses enterprise buyers ask about by name.

Which vendors get missed?

The ones that arrive as a package install rather than an invoice.

A vendor bought by a founder or an ops lead goes through something: a trial, a card, a renewal date, maybe a security questionnaire. A vendor added by an engineer goes through none of that. Error monitoring, session replay, log aggregation, feature flags, the support inbox, a CI pipeline restoring a production snapshot into a test environment, and the model API behind a new AI feature all handle real user data. Look twice at the model API: it is your processor only while the provider uses your inputs for nothing of its own, such as training, and that is a contract term to check rather than a default to assume.

You are expected to know all of them, not just the ones you remember. In its opinion on reliance on processors, the EDPB says controllers should have the identity of all processors and sub-processors readily available at all times, and that this applies regardless of the risk attached to the processing 2. Your processors' own subcontractors belong on the list too, though the contract with them is your processor's job, not yours. The place I would look first is whatever never had an invoice attached to it.

What if a vendor uses your data for its own ends?

Then it stops being your processor for that use, and your contract does not prevent it happening.

GDPR says a processor that goes beyond your instructions and starts determining its own purposes and means is considered a controller for that processing 1. The EDPB illustrates it with a marketing supplier engaged and named as a processor that then starts using its customer's database to build its own business.

That sets a useful limit on what a signature buys you. A DPA records what a vendor has promised to do. It does not report what the vendor is doing, so a supplier that quietly starts mining your data has broken the contract rather than been stopped by it. GDPR separately requires you to use only processors that give sufficient guarantees, and the EDPB treats that as something to verify at appropriate intervals rather than a box ticked once at signing 1. That applies to every processor, and you check hardest the ones holding the most personal data 2.

How do you build the list?

Open your cloud bill and your package manifest side by side, because between them they name more vendors than either does alone. For each activity, write down what the vendor receives and who set the purpose. That produces the three groups, and the groups tell you what to chase: a DPA for the processors, a lawful basis and a privacy policy entry for the separate controllers, and a written split of duties for anything genuinely joint. Put a date in the calendar to walk the list again, since the duty to check your processors is a standing one rather than a signing-day one. If I were doing this from scratch I would chase the processor contracts first, because a missing Article 28(3) contract is a requirement you have not met, while a thin privacy policy entry is a disclosure you can sharpen.

The harder half is keeping it true. The list is accurate on the day you make it and stops being accurate the next time somebody adds an SDK. Your published sub-processor list, the privacy policy naming your recipients, and the DPA you hand to customers all draw on that same vendor set, so one dependency added on a Tuesday can put three documents out of date at once.

Lawcel is a compliance platform that watches the pull requests and tickets where product change happens. My co-founder and I built it for this half of the problem. It keeps a record of your third parties: for each one, what data it receives, where it is based, and which of the three roles above it holds. When a change adds a vendor or alters what an existing one gets, Lawcel opens a case naming the documents that no longer match and proposing the edit, so the sort you did once is kept current as the code changes. If your vendor list is already out of date and you would rather not rebuild it by hand every quarter, that is the part we can take off you.

Do the sort either way. Grouped by role, that list tells you which signatures you are missing, what your privacy policy owes users about recipients, and what to hand over the first time an enterprise buyer runs procurement on you. Skip it and you are trusting that every vendor anyone has added is covered by a template somebody once signed.