Why a DPA is a requirement, not a formality
Almost every company today uses vendors that, in one way or another, handle personal data on its behalf. It might be a payroll system, a cloud email service, a CRM, a support platform, or an agency that runs your marketing. Every time such a vendor processes personal data for you, the General Data Protection Regulation (GDPR) imposes an explicit requirement: there must be a written data processing agreement, commonly abbreviated as a DPA (in Swedish, PUB-avtal).
Many companies treat the DPA as just another formality among the documents a vendor sends over. That is a mistake. The DPA is a legal requirement under GDPR, and the absence of a proper agreement is itself a breach – regardless of whether any personal data has actually gone astray. The agreement is also what determines who bears responsibility if something goes wrong.
This article explains what a DPA is, when it is required, what it must contain, how it relates to cloud services and international transfers, and the mistakes and risks you should be aware of.
What a DPA is and when it is required
GDPR distinguishes between two central roles. The controller is the party that determines the purposes and means of a processing operation – that is, why and how personal data is to be processed. The processor is the party that processes the data on the controller’s behalf, according to its instructions.
The controller–processor relationship
A typical example: your company (the controller) uses a cloud-based payroll system from a vendor (the processor). You decide why the payroll data is processed and how it is to be used, while the vendor provides the system and processes the data for you. As soon as such a relationship arises, GDPR requires it to be governed by a written agreement. The requirement follows from Article 28 of the regulation, which provides that a controller may only use processors that offer sufficient guarantees, and that the processing must be governed by a contract or other legal act.
The difference from joint and independent controllership
Not every vendor relationship is a processor relationship. If a counterparty processes personal data for its own purposes, it is itself a controller, and a different arrangement is needed rather than a DPA. Sometimes two parties jointly determine the purposes and means, creating joint controllership with its own requirements. Correctly classifying the relationship is therefore the first step – a DPA with the wrong party protects neither you nor your data subjects.
Sub-processors in the chain
Modern cloud services almost always rely on a chain of subcontractors – the vendor in turn uses an infrastructure provider, which in turn uses others. GDPR permits such sub-processors, but only if the processor has your authorisation and ensures the sub-processors are bound by the same obligations. A good DPA therefore regulates how sub-processors may be engaged and how you are informed of changes.
What a DPA must contain
GDPR sets clear minimum requirements for the content of a DPA. The agreement must describe the subject matter and duration of the processing, its nature and purpose, the types of personal data processed and the categories of data subjects affected.
Beyond this, the agreement must, among other things, establish that the processor only processes the data on your documented instructions, that persons with access to the data are subject to confidentiality, and that the processor implements appropriate technical and organisational security measures. The agreement must also provide that the processor assists you in responding to data subject requests, helps you meet your obligations in the event of personal data breaches, and deletes or returns the data when the engagement ends. Finally, the processor must give you the ability to audit and inspect, so that you can verify the obligations are actually being met.
The point of these requirements is that the controller can never offload its responsibility by engaging a processor. Responsibility stays with you, and the DPA is the tool that lets you retain control over how the data is processed.
SaaS, cloud services and international transfers
For most companies, the DPA arises above all in the use of SaaS and cloud services. When your data sits in a vendor’s systems, the vendor is a processor, and the agreement is needed. Most established SaaS vendors today provide a standardised DPA as part of their terms, but you should not accept it unread. Pay particular attention to how sub-processors are handled, where the data is stored and processed, and what security measures are actually promised.
A particularly important question is where in the world the data is processed. GDPR permits transfers of personal data to countries outside the EU and EEA only if there is an adequate level of protection. For certain countries there is an adequacy decision. For transfers to the United States, a vendor that has joined the EU-US Data Privacy Framework can provide a basis for transfer. In many cases, the European Commission’s standard contractual clauses (SCCs) are used instead, sometimes supplemented by additional safeguards.
Because many large cloud providers are based, or keep their infrastructure, outside the EU, this is a question you need to ask proactively. A DPA that does not address where the data ends up, and on what legal basis it may be transferred, is incomplete.
A practical example: the vendor that became your risk
Imagine a growing e-commerce company that engages an external agency for customer service and newsletters. The agency is given access to the customer database and routinely handles personal data on the company’s behalf. No DPA is put in place – it feels like an obvious working relationship, and no one thinks about the formal side.
A year later, the agency suffers a data breach in which part of the customer database leaks. When the supervisory authority examines the matter, it turns out that the company, as controller, never had an agreement governing the agency’s security measures, instructions or obligation to report incidents. The company therefore cannot demonstrate that it ensured the processor offered sufficient guarantees. The absence of a DPA becomes a deficiency in its own right, alongside the breach itself.
With a proper DPA, the company could have shown that it imposed security requirements, documented instructions and secured the right to audit the agency. The agreement would not have made the breach impossible, but it would have given the company both a better legal position and practical tools for managing the situation.
Common mistakes businesses make
The most common mistake is having no DPA at all with vendors that actually process personal data. Many companies have agreements with the largest vendors but miss the smaller ones – the agency, the freelancer, the niche tool that some department started using on its own.
A second mistake is signing the vendor’s standard DPA without reading it. Standard terms are written to protect the vendor, and they may contain broad rights to engage sub-processors or process data in ways you cannot oversee.
A third mistake is misclassifying the relationship – for example, treating an independent controller as a processor. This leads to agreements that do not match reality and that provide false comfort.
A fourth mistake is never keeping track of where the data is processed. Without control over international transfers and sub-processors, personal data can end up in countries without adequate protection, without you even knowing.
The legal risks of missing or deficient DPAs
Lacking a DPA where one is required is itself a breach of GDPR. The regulation allows supervisory authorities to impose fines of up to EUR 20 million or four percent of a group’s global annual turnover, depending on the nature of the breach. Even though the highest amounts are reserved for the most serious cases, the level shows the weight the legislator places on compliance.
Beyond the direct sanctions, there is the risk of compensation to data subjects, the costs of managing incidents, and – often just as damaging – reputational harm if it becomes known that you did not have your vendor relationships in order. Responsibility also stays with you as controller even when the practical failure was committed by a processor, which makes your own agreements decisive for where the risk lands.
Recommended actions
Start by mapping which vendors process personal data on your behalf. Go through all systems and collaborations, including the smaller tools brought in without central oversight, and decide for each relationship whether the counterparty is a processor, an independent controller or a joint controller.
Ensure there is a DPA with every processor and that the agreement meets GDPR’s content requirements. Review vendors’ standard DPAs rather than accepting them unread, and pay particular attention to sub-processors, security measures and where the data is processed. For transfers outside the EU, check that there is a valid basis – for example an adequacy decision, standard contractual clauses, or membership of the EU-US Data Privacy Framework.
Finally, treat DPAs as part of an ongoing process, not a one-off task. Vendors change sub-processors, move data centres and amend terms, and your data protection work needs to keep pace.
Frequently asked questions about DPAs
What is the difference between a DPA and a PUB-avtal?
Nothing in substance. “PUB-avtal” is the Swedish abbreviation for personuppgiftsbiträdesavtal, while “DPA” (Data Processing Agreement) is the English term for the same thing. International vendors usually use the term DPA.
When do we need a DPA?
You need a DPA every time a vendor processes personal data on your behalf according to your instructions – that is, acts as a processor. This applies, for example, to cloud and SaaS services, payroll systems, support platforms and agencies that handle your customer data.
Is the vendor’s standard agreement enough?
An established standard DPA often meets the basic requirements, but you should still review it. Standard terms are written from the vendor’s perspective and may grant broad rights regarding sub-processors and data processing. Your responsibility as controller remains regardless of what the vendor’s template says.
What applies if the vendor is outside the EU?
Then the rules on international transfers come into play. A transfer may take place if there is an adequacy decision, if the vendor is covered by the EU-US Data Privacy Framework, or if you use standard contractual clauses, sometimes with supplementary safeguards. The DPA should reflect the basis on which the transfer takes place.
Who is responsible if a processor causes a breach?
Responsibility as controller stays with you, even when the failure was practically committed by the processor. The processor has its own obligations under GDPR and may also be held liable, but within the DPA you can ensure that risk and costs are allocated reasonably between the parties.
Does a DPA have to be in writing?
Yes. GDPR requires the processing to be governed by a contract or other legal act, and in practice this means a written agreement, which may also be in electronic form. A verbal arrangement does not meet the requirement.
Conclusion
A DPA is not a formality but an explicit requirement under GDPR and one of the most important tools for retaining control over how your personal data is processed. Anyone who engages vendors without governing the processor relationship risks both sanctions and lost trust, and also bears responsibility for what happens at others’ hands. Having your DPAs in order is therefore one of the most fundamental – and most overlooked – parts of effective data protection.
Lawgent helps companies map their vendor relationships, draw up and review DPAs, and secure international transfers in line with GDPR. We combine experienced data protection advice with AI-driven efficiency, so that you achieve compliance and control without drowning in legalese – faster and more cost-effectively than at a traditional firm. Want to know whether your vendor agreements measure up? Contact Lawgent for a review of your DPAs.
