What is a DPA?
A DPA (Data Processing Agreement) is the legal contract that must be in place whenever a vendor processes personal data on your behalf. In practice it's required for almost every cloud service and development partnership, and it governs instructions, security, subprocessors, and deletion. Standard agreements are rarely negotiable, but they should always be read.
As soon as you bring in a cloud service or an agency that touches your customers’ data, the abbreviation DPA shows up – often as an attachment you’re asked to sign. It’s easy to click through, but the agreement is the actual foundation for making the processing lawful. Here’s what a DPA is, when it’s required, and what to look for.
The definition: the agreement behind the processing
A DPA (Data Processing Agreement) is the legal contract that governs how a vendor may process personal data on your behalf. It’s signed between you, as the data controller, and the vendor, as the data processor.
The agreement does two things at once. It fulfills a requirement – GDPR explicitly states that such an agreement must exist – and it sets the ground rules: what the vendor may and may not do with the data. Without it, the processing lacks its legal foundation, no matter how well the vendor actually behaves in practice.
Note that DPA and personuppgiftsbiträdesavtal are exactly the same thing. The English abbreviation shows up even in Swedish-market contexts, especially with international vendors.
When it’s required: more often than you think
The basic rule is simple: a DPA is required as soon as a vendor processes personal data on your behalf. And that happens considerably more often than you’d first think.
- Cloud services. If the vendor stores your data – customer records, user accounts, email addresses – you need a DPA. In practice, that applies to every cloud service holding personal data.
- Hosting and operations. A partner running servers that hold personal data is processing it on your behalf.
- Development partnerships. An agency building or maintaining a system often gets access to personal data during the work, for example in test data or while debugging.
The exception is if the vendor only handles fully anonymous data that can’t be linked to any person. But that boundary is narrow – most systems touch personal data somewhere. So assume a DPA is needed, and justify the exception rather than the other way around.
The core content: four things to require
A DPA can be long, but four points form the core. If any is missing, the agreement is incomplete.
| Part | What it secures |
|---|---|
| Instructions | The vendor only processes the data as you've determined |
| Security measures | What protection must be in place |
| Subprocessors | Which other vendors may in turn be engaged |
| Deletion | How the data is handled when the collaboration ends |
Instructions bind the vendor to only doing what you’ve told them to do with the data. Security measures describe the protection, both technical and organizational. Subprocessors lists which vendors the processor may in turn bring in – often underlying cloud services, and that list says a lot about where your data actually ends up. Deletion governs that the data is removed or returned when you end the relationship. A complete agreement also covers things like how you’re notified of a personal data breach.
Read it, even if you can’t change it
A common objection is that it’s not worth bothering, since the large vendors’ DPAs can’t be negotiated anyway. It’s true that they offer a standard agreement that applies equally to everyone, and that an individual customer rarely gets to change a single line.
But not being negotiable isn’t the same as not needing to be read. On the contrary – it’s in the standard agreement that you see what you’re actually agreeing to: which subprocessors are used, which countries your data might end up in, and what protection is promised. You need that information to judge whether the vendor is right for your particular data. With smaller or local vendors there’s sometimes more room to negotiate, but the requirement to read it applies just the same.
How to put this to use
In practice, that means three things for you as the buyer. Map out which vendors process personal data on your behalf, and make sure there’s a DPA with each one – it’s you, as the controller, who bears responsibility for the agreement existing. Read the sections on subprocessors and data storage in particular. And do this before the system goes live, not after.
If you’d like help building the right contract and data protection requirements in from the start, at Weapp we’re happy to be part of that systems work. Get in touch and we’ll go through which DPAs you need to have in place.
Frequently asked questions
When do we need a DPA?
As soon as a vendor processes personal data on your behalf. In practice, that means almost every cloud service, hosting partner, and development collaboration that comes into contact with your customers' or employees' data. If the vendor only handles fully anonymous data, it's not needed, but that boundary is narrower than many people think, so assume the agreement is required.
What should a DPA contain?
The core is four things: that the vendor only processes the data according to your instructions, what security measures apply, which subprocessors may be used, and how the data is deleted or returned when the collaboration ends. A complete DPA also covers things like how you're notified of a personal data breach. If the core points are missing, the agreement is incomplete.
Is a DPA the same thing as a data processing agreement?
Yes. DPA stands for Data Processing Agreement, which is also known in Sweden as a personuppgiftsbiträdesavtal. They're two names for exactly the same thing: the agreement between a data controller and a data processor that governs how the processor may handle the data. You'll often see the English abbreviation used even in Swedish-market contracts, especially with international vendors.
Can you negotiate a DPA?
Rarely with the large vendors. They offer a standardized DPA that applies to all customers and that, in practice, can't be changed. With smaller or local vendors, there's sometimes more room. But even a non-negotiable agreement should be read carefully, because that's where you see where your data ends up and which subprocessors are used.
What happens if we don't have a DPA?
Then the processing isn't compliant with GDPR, which explicitly requires a written agreement whenever a processor handles personal data. It's you, as the data controller, who bears responsibility for making sure the agreement exists, not the vendor. A missing DPA is therefore a gap you're accountable for, and one of the easier things to fix in time.