DPA is one of those acronyms that sounds like it belongs to a legal department you do not have. The underlying idea is straightforward: if you hand somebody else data about your customers, there should be a written agreement about what they may do with it.
For most vendors in a small company's stack, obtaining one is not a negotiation. It is finding a page in their documentation and accepting it.
This is not legal advice. What follows is the practical shape of the task. Requirements differ by jurisdiction and by what data you hold, and anything significant is worth a conversation with someone qualified where you operate.
Controller and processor, briefly
Two roles, and the distinction determines who needs what.
The controller decides why and how personal data is processed. For your customers' data, that is you.
The processor handles data on the controller's instructions. Your email provider, your hosting company, your support desk. They act on your behalf and are not supposed to decide independently what to do with it.
A DPA is the contract between those two roles. Its central purpose is to constrain the processor: it may use the data to deliver the service you bought, and not for anything else.
You may also sit on the other side of it. If you sell to businesses, your customers are controllers and you are their processor, which means they will ask you for a DPA. Having your own ready is worth more than it costs.
What a DPA actually contains
Six things, in most templates:
- Purpose and scope. What the data may be used for, which is delivering the service and nothing beyond it.
- Categories of data and people. What kinds of personal data, about whom.
- Security measures. What the processor commits to technically and organisationally.
- Subprocessors. Whether they may use others, and whether you get notice or a right to object.
- Assistance with data subject rights. What happens when one of your customers asks for their data or asks for it deleted.
- Return or deletion at the end. What happens to the data when you stop being a customer.
The two most often skimmed are the ones worth reading. The subprocessor clause tells you whether your data can reach parties you have never evaluated. The deletion clause tells you whether cancelling actually removes anything, and the answer is sometimes "after ninety days in backups", which is reasonable and worth knowing.
Which of your vendors need one
Work from your vendor list, using the data column. Three groups fall out.
Definitely. Anything processing customer personal data: hosting and databases, email delivery, support desk, CRM, analytics that identifies individuals, payment processing, and any AI or automation tool you send customer content to.
That last category deserves explicit attention because it is new, it is growing, and it is easy to adopt informally. A tool summarising support conversations is processing customer personal data whatever else it is.
Probably. Employee data: payroll, HR systems, recruitment tools. Still personal data, still processed on your behalf.
Probably not. Tools touching no personal data at all: a code linter, a design tool with no customer content, infrastructure monitoring that sees only metrics. Note the reasoning in the register rather than leaving the row blank, so the next person does not have to work it out again.
Getting them signed
Most vendors have solved this for you. The usual routes, in order of how often they apply:
- Accept in the account settings. Many providers have a compliance or legal section where you tick a box and download a countersigned copy. Search their help centre for "DPA".
- Their published template. A PDF you sign and return. A countersigned copy comes back.
- Included in their standard terms. Some vendors incorporate DPA terms by reference in the agreement you already accepted. Download that document and file it as your evidence.
- Ask support. For smaller vendors, an email asking whether they have a data processing agreement usually gets one. If the question confuses them, that is itself information.
Keep the signed copies somewhere you can find them. A folder, dated, one file per vendor. When a customer asks whether you have DPAs with your subprocessors, the answer should be a list and not an afternoon of searching inboxes.
Where the data goes, and why it matters
One clause is worth reading properly rather than skimming: where processing happens.
If your customers are in one jurisdiction and your vendor processes their data in another, that arrangement usually needs a legal basis of its own. Standard contractual clauses are the common mechanism, and most established vendors incorporate them into their DPA so the question is already answered.
What you need from this is narrower than the full legal picture. You need to know, for each vendor handling personal data, where it is processed, so that you can answer the question when a customer asks and so that you notice if a vendor changes it.
Many vendors let you choose a processing region at setup, and the default is frequently not the one your customers would expect. Choosing deliberately at adoption is far easier than migrating later, and it is a one-line note in your register that saves an awkward conversation.
If you sell into regulated sectors or to public bodies, expect this to be asked in detail. Having the answer already recorded per vendor turns a research task into a lookup.
Your own subprocessor list
If you sell to businesses, your customers will eventually ask who you share their data with. A published subprocessor page answers that once instead of repeatedly.
It is a short page: vendor name, what they do, and where they process. Many DPAs also require you to notify customers before adding a new subprocessor, so the page usually carries a way to subscribe to changes.
This is also a quiet sales asset. A prospect's security reviewer finding a current subprocessor page forms a different impression from one who has to ask for it.
When a vendor will not sign
It happens, usually with smaller tools that have not been asked before.
Do not leave the row blank. Write down the position and the decision: what data they hold, what you asked, what they said, and what you decided. Sometimes the honest answer is that the exposure is small and you accept it, with a named owner and a review date. Sometimes it is that the data is too sensitive and you replace the vendor.
Either is defensible. What is not defensible is a register with unexplained gaps in it, because that reads as a question nobody looked at.
The practical version
Sort your vendor list by the data column. For each vendor touching personal data, spend ten minutes finding their DPA and accepting it. Most will take two minutes; a handful will need an email.
A morning usually closes eighty per cent of the gap, and the remaining rows are the ones worth thinking about properly.