Data Processing Agreements (DPAs): What Website Owners Need to Know

What Is a Data Processing Agreement?

A Data Processing Agreement (DPA) is a legally binding contract between you — the business deciding why and how personal data is used (the "controller") — and a third party that processes that data on your behalf (the "processor"). When you use an analytics tool, an email platform, a hosting provider, or a CRM, those vendors handle your visitors' and customers' personal data under your instructions. The GDPR requires that relationship to be governed by a written agreement with specific clauses, set out in Article 28 of the GDPR.

The DPA is one of the most overlooked compliance requirements among website owners, partly because it lives in the background — you sign it once and forget it. But its absence is a clear, easily-spotted violation: if a regulator asks "where is your DPA with this processor?" and you don't have one, there is no ambiguity to argue. This guide explains when you need a DPA, what it must contain, and how to keep them organized. It builds on the GDPR basics.

Controller vs Processor: Who's Who

The DPA requirement hinges on a distinction that confuses many people. The controller determines the purposes and means of processing — the "why" and "how." The processor acts on the controller's behalf and follows its instructions.

For a typical website owner, you are the controller for your visitors' data, and most of your tools are processors. When you configure Google Analytics to measure your traffic, you decided to do that and why — you're the controller; Google processes the data on your instruction. The DPA documents that you've instructed the processor properly and bound it to protect the data.

One nuance: some relationships are joint controllership or involve the vendor acting as an independent controller for its own purposes (common with advertising platforms). Those need a different kind of arrangement. But for the core "tool processes data on my behalf" case, a DPA is the instrument.

When the GDPR Requires a DPA

The rule is straightforward: whenever a processor handles personal data on your behalf, Article 28 of the GDPR requires a DPA. In website terms, you need one with essentially every third-party service that touches your visitors' or customers' personal data, including:

• Analytics providers — they process visitor behavior data.
• Email and marketing platforms — they hold subscriber and customer data.
• Hosting and cloud infrastructure — your servers store personal data.
• CRM and support tools — customer records and conversations.
• Payment processors — though these are often controllers in their own right for parts of the flow.
• Form, scheduling, and chat widgets — anything collecting input from users.

The practical first step is the same one that underpins transfer compliance: know which third parties actually receive data. A scan of your site's connections surfaces the vendors you may have forgotten you added.

What a DPA Must Contain

Article 28 specifies the clauses a compliant DPA includes. When you review a vendor's DPA, check that it covers:

• Subject matter and duration of the processing.
• Nature and purpose of the processing, and the types of data and categories of data subjects involved.
• Processing only on documented instructions from the controller.
• Confidentiality commitments from personnel handling the data.
• Security measures appropriate to the risk (Article 32).
• Sub-processor rules — the processor must get authorization before engaging sub-processors and flow the same obligations down to them.
• Assistance to the controller — helping you respond to data subject requests and meet your security and breach-notification duties.
• Deletion or return of data at the end of the engagement.
• Audit rights — allowing the controller to verify compliance.

If a vendor's agreement is missing these, it's not a complete DPA, regardless of what it's labeled.

DPAs and International Transfers

DPAs frequently intersect with the transfer question. Where a processor is outside the EU/EEA, the DPA is often the vehicle that carries the Standard Contractual Clauses or references the provider's Data Privacy Framework certification. So when you accept a US vendor's DPA, you're frequently handling both the processor relationship and the transfer mechanism in one document. Read it with both hats on: does it bind the processor properly, and does it establish a valid basis for sending data abroad?

Managing DPAs Across Your Stack

The real challenge isn't any single DPA — it's keeping track of all of them. A mid-sized website can easily use dozens of tools that process personal data. Build and maintain a simple register: the vendor, what data they process, whether you have a signed/accepted DPA, where it's stored, their sub-processors, and their transfer basis. Tie this register to your cookie and vendor inventory so that adding a new tool triggers a DPA check. This register is also exactly what you'll reach for during an audit or when answering a due-diligence questionnaire from a customer.