Data processing agreements – when do you need one, and what should it say?
A data processing agreement, or DPA, is required whenever your IT vendor handles personal data on your behalf – which happens as soon as they host or access systems containing such data. Under GDPR Article 28, the agreement must cover purpose, security, deletion, and sub-processors, among other things. Without it, both you and the vendor are breaking the rules.
As soon as a system contains data about people – customers, members, employees – and someone other than you handles that system, a data processing agreement, or DPA, comes into play. It’s not a formality to postpone: without the agreement, the processing itself is unlawful, and the responsibility falls on you as the buyer. At the same time, it’s no more complicated than understanding two things – when it’s needed and what it has to contain.
Where to draw the line: when is the agency handling data for you?
The starting point is the roles. You are the data controller: you’re the one who decides why and how the data is processed. The vendor becomes a data processor when they process the data on your behalf, according to your instructions, rather than for their own purposes.
In practice, that happens in two common situations:
- During hosting. If the vendor manages the hosting of a system containing personal data, they’re processing it on your behalf, even if they never actively look at it.
- During development with access to real data. A developer who gets access to the production environment to troubleshoot is processing real data, even if the purpose is just to fix a bug.
The reverse is also true: a vendor that builds solely against test data with no real records usually isn’t a processor. The key question, then, isn’t what the engagement description says, but who can actually see real personal data in practice. Map that out, and you’ll know whether the agreement is required.
The mandatory contract terms
A DPA isn’t free to draft however you like. GDPR Article 28 lists what it must contain, and the points are requirements, not wishes.
| Contract term | What it secures |
|---|---|
| Subject matter and purpose | Which data is processed, for how long, and why |
| Only on instruction | The processor acts only on your documented instructions |
| Security measures | Appropriate technical and organizational protection of the data |
| Confidentiality | Those handling the data are bound by confidentiality |
| Sub-processors | Terms for engaging subcontractors and your right to insight |
| Assistance with requests | Support for data subject rights, and for incidents |
| Deletion at the end of the engagement | The data is deleted or returned when the collaboration ends |
A common mistake is settling for a standard agreement without checking that all the points are actually covered and fit your specific processing. Read it as a checklist: if a point is missing, the agreement is incomplete, and the gap is your responsibility.
Sub-processors in the cloud chain
Almost no vendor gets by without its own subcontractors. The cloud platform the system runs on, a service for sending emails, a logging tool – each one that in turn handles your data becomes a sub-processor. The chain can get longer than you’d think.
You have the right to know which sub-processors are used and to object to new ones. The agreement should also ensure the vendor passes the same obligations down to its sub-processors – otherwise the protection leaks out at the end of the chain. Always ask for an up-to-date list of the sub-processors, not just a clause saying they may exist.
If a sub-processor sits outside the EU, the question of third-country transfer comes into play, which requires its own safeguards beyond the DPA. That’s a separate question, but it starts right here – with which sub-processors exist and where they’re located.
A scenario: the forgotten access
A company had a DPA with its hosting vendor and felt secure. During a review, it turned out that the development agency too, which formally only “built” the system, routinely got access to production data for troubleshooting – with no DPA at all. The processing had been going on for months with no legal basis.
The fix was simple once it was discovered, but the point is it would never have been caught if no one had asked who actually accessed real data. The role of processor follows from what happens in practice, not from what’s written on the invoice.
If you want to sort out which of your vendors are data processors and whether the agreements hold up, we at Weapp are glad to have that conversation – get in touch with a short description of your systems.
Frequently asked questions
When does our IT vendor become a data processor?
As soon as they process personal data on your behalf rather than their own. That happens when they host systems containing such data, or when developers get access to production data during their work. You remain the data controller and decide the purpose, but the vendor becomes a processor, and the processing then has to be regulated in a DPA.
Do you need a DPA even if the vendor only builds, and doesn't host?
It depends on whether they access real personal data. A vendor developing against test data with no real records usually doesn't need a DPA. But in practice, developers often get access to the production environment for troubleshooting, and then real data is being processed. Map out who can actually see what, and you'll know whether the agreement is required.
What must a DPA contain under Article 28?
Among other things: the subject matter and purpose of the processing, that the processor only acts on your instructions, appropriate security measures, confidentiality, handling of sub-processors, assistance with data subject requests and incidents, and that the data is deleted or returned when the engagement ends. These points aren't optional – they're a legal requirement for the processing to be lawful.
What applies to sub-processors in the cloud chain?
The vendor almost always uses its own subcontractors, such as cloud platforms, and these become sub-processors. You have the right to know who they are and to object to new ones. The agreement should also ensure the vendor passes the same obligations down to its sub-processors. A cloud service outside the EU additionally raises the question of third-country transfer, which requires its own safeguards.