What Is a Data Processing Agreement (DPA)?

Key takeaways:

• Implement a DPA with every third-party processor handling personal data from EU residents, as GDPR legally requires this contract regardless of where your organization is headquartered.

• Verify that your DPA explicitly defines data use boundaries, security standards, breach notification procedures, and processor responsibilities before signing, as vague language creates room for misuse and compliance gaps.

• Recognize that as the data controller you remain legally liable for data breaches even when caused by processor errors, making thorough vetting of vendor security practices essential before sharing any personal data.

• Include all GDPR Article 28 required elements in your DPA: scope and purpose of processing, data categories, duration, controller and processor responsibilities, technical safeguards, and data deletion terms.

How much control do you really have over your customer data once it leaves your hands? When you hand over customer data to a third-party vendor, you are still on the hook for what happens to it, and according to research on third-party risk, the average cost of a third-party breach tops $5.08 million. That is where a data processing agreement (DPA) comes in: the contract that sets the rules of the road for how your data gets handled, stored, and protected.

Whether you are a controller signing your first vendor DPA or a service provider building one from scratch, understanding what belongs in this contract (and when you actually need one) makes the difference between smooth compliance and expensive headaches. Let’s walk through what a DPA is, when it is required, what goes in it, and how to handle it from both sides of the table.

What is a data processing agreement?

A DPA is a legally binding contract between a data controller and a data processor that governs how personal data is collected, stored, used, and protected.

The two parties in a DPA have distinct roles:

• Data controller: The organization that determines why and how personal data is processed, typically a business hiring a third-party service.

• Data processor: The third party that processes data on the controller’s behalf, such as a cloud software provider or analytics platform.

Data processing covers any operation performed on personal data, including collection, storage, retrieval, analysis, and deletion. Because these operations often involve sensitive information about real people, a DPA establishes clear rules for how that data must be handled.

To see how this plays out in practice, consider the New York Times (NYT) and Google BigQuery. The NYT uses BigQuery to gather and analyze data about what articles people read, how long they stay on site, and how often they use the NYT app. That’s personal data being processed by a third party on the controller’s behalf, exactly the scenario a DPA is designed to govern. There’s a DPA between the NYT and Google that sets the terms for how that data is used and managed.

Why a DPA matters, and what you get out of having one

A data processing agreement does more than satisfy a legal checkbox. It defines exactly how personal data moves through your vendor relationships, and what happens when something goes wrong.

Without a DPA, you’re operating on assumptions. With one, you have documented terms that protect your organization, clarify accountability, and give you a clear path forward if a vendor mishandles data.

Here’s what a well-structured DPA actually gives you:

• Defined boundaries for data use: The agreement specifies what a processor can and cannot do with your data. That means no surprises about how a vendor is using customer information you entrusted to them.

• Documented security requirements: A DPA sets explicit standards for how data is stored, encrypted, accessed, and protected, so you can hold vendors accountable to a written standard, not a verbal promise.

• Clear accountability if something goes wrong: When a breach occurs, a DPA establishes who bears responsibility and what steps the processor must take to notify you and cooperate with any investigation.

• A foundation for General Data Protection Regulation (GDPR) compliance: For organizations that collect or process data from people in the European Union (EU), a signed DPA with each third-party processor is a legal requirement under the GDPR. Operating without one exposes you to significant regulatory penalties, according to Infosecurity Magazine, GDPR fines totaled €1.2bn in 2024.

• Reduced risk across vendor relationships: As your vendor stack grows, DPAs create consistency. Every processor relationship is governed by the same baseline requirements, which makes audits, renewals, and compliance reviews significantly easier to manage.

When is a DPA required?

A DPA is legally required any time a data controller shares personal data with a third-party processor to handle on its behalf. This applies across a wide range of common business relationships: using a cloud storage provider, a marketing automation platform, a payroll system, or an analytics tool that touches personal data.

Whether a DPA is strictly mandatory depends on the regulations that govern your data. Two scenarios cover most organizations:

• GDPR applies to you: If your organization collects or processes personal data from people in the EU, a DPA is legally required for every third-party processor you work with—no exceptions.

• GDPR does not apply: Even if your data doesn’t touch EU residents, a DPA is still a strong operational practice. It creates documented accountability between you and your vendors and establishes clear expectations before any data is shared.

In short: if a third party is touching your data, you should have a DPA in place—required or not.

GDPR and the DPA requirement

GDPR is the primary reason most organizations need a DPA. Passed by the EU, GDPR mandates that any organization handling personal data from EU residents must have a signed DPA in place with every third-party data processor it works with.

GDPR’s reach extends beyond Europe. If your organization targets or collects data about people in the EU, regardless of where your company is headquartered, GDPR applies to you. Operating without compliant DPAs in place can result in significant fines, with penalties reaching up to €20 million or 4% of global annual revenue, whichever is higher.

Who is responsible for initiating a DPA?

In most cases, the data processor, the vendor or service provider handling your data, is responsible for providing a DPA. Established software as a service (SaaS) companies, cloud platforms, and enterprise software providers typically maintain a standard DPA that they offer to customers as part of their legal agreements.

That said, the data controller has the right to negotiate DPA terms. If a processor’s standard agreement doesn’t meet your compliance requirements or leaves important provisions undefined, you can and should request revisions before signing.

If you’re operating as a processor and a customer hasn’t raised the topic, it’s good practice to initiate the DPA yourself. Waiting for a customer to ask puts you behind—and signals to enterprise buyers that your compliance posture may not be mature enough for their standards.

What goes in a DPA

A data processing agreement must document four core things: the scope and purpose of data processing, what personal data is involved, how that data will be protected, and the specific responsibilities of each party.

GDPR-compliant DPAs go further, requiring detailed provisions across each of these areas. The following elements are required under GDPR’s Article 28 and should be addressed in any well-structured DPA.

General information

The general information section establishes the foundational terms of the agreement, defining who is involved, what data is covered, and how long the arrangement lasts.

This section typically covers:

• The specific data processing activities being performed

• How personal data will be used by the processor

• Which party is responsible for ensuring GDPR compliance

• The duration of the data processing arrangement

• Definitions of data subjects (such as customers or employees)

• The categories and types of personal data being processed

• Where and how data will be stored

• Terms for returning or deleting data when the contract ends

Responsibilities of the controller

When it comes to GDPR compliance, establishing a lawful data process and observing data subjects’ rights falls to the controller. The controller is also responsible for issuing processing instructions and dictating how the processor handles data.

Responsibilities of the processor

Under GDPR, processors carry substantial legal obligations that must be explicitly documented in the DPA.

Processor responsibilities include:

• Maintaining information security and implementing appropriate technical safeguards

• Processing data only according to the controller’s documented instructions

• Cooperating with supervisory authorities during any investigation or inquiry

• Reporting data breaches to the controller promptly, typically within 72 hours of discovery

• Providing the controller with opportunities for audits and inspections

• Keeping accurate records of all data processing activities

• Returning or securely deleting all personal data at the end of the contract

If the processor intends to use sub-processors, that arrangement requires separate documentation and written consent from the controller.

Technical and organizational requirements

Technical and organizational requirements define the specific security measures both parties must implement to protect personal data throughout the processing relationship.

GDPR requires that these measures be appropriate to the risk involved. Controllers and processors must jointly consider the state of available technology, the cost of implementation, and the nature of the data being processed when determining the right level of protection. At minimum, a DPA should document:

• Encryption standards for data in transit and at rest

• Access controls that limit who can view or modify personal data

• Processes for regularly testing and evaluating the effectiveness of security measures

• Procedures for ensuring the ongoing confidentiality, integrity, availability, and resilience of processing systems

Signing a DPA as a customer (controller)

When you hire or partner with a third-party data processor, you’ll be asked to sign a DPA. This is standard practice—and legally required if you’re working with personal data from EU residents.

Here’s what that looks like in practice. A healthcare provider purchasing cloud-based patient management software is handing a third party access to sensitive medical records. That vendor is now collecting, storing, and transmitting personal data about patients, which is exactly the kind of arrangement a DPA is designed to govern. The agreement defines the terms of that relationship and protects the healthcare provider if something goes wrong.

Before signing any DPA, review it carefully with the following in mind:

• Verify data use is clearly defined: The agreement should specify exactly what the processor can and cannot do with your data. Vague language creates room for misuse.

• Check that required elements are present: Cross-reference against the elements covered in the “What goes in a DPA” section above. If something is missing, request that it be added before signing.

• Confirm security capabilities: The processor should be able to demonstrate that they have the technical and organizational measures in place to actually deliver on their commitments.

• Understand your liability exposure: Under GDPR, you as the controller can be held responsible for a data breach even if it was caused by a processor error. Vetting your processor’s security practices before signing isn’t optional; it’s how you protect your organization.

Creating a DPA as a service provider (processor)

If you provide data processing services to other businesses, particularly those serving EU residents, you need to be able to create, negotiate, and manage DPAs at scale.

The challenge is that every customer relationship is slightly different. Some customers come with their own DPA requirements. Others expect you to provide a standard agreement. Some will request modifications. Multiply that across a growing customer base and DPA management becomes a real operational burden for your legal team, a challenge that drives many organizations to seek out a dedicated contract lifecycle management (CLM) platform. That burden also shows up in broader contracting data: procurement contracts average 23 days to sign, with 66% involving legal and 77% on counterparty paper, according to our 2026 Contracting Benchmark Report.

A few things make this harder than it looks:

• DPAs are detailed documents: Even a standard DPA runs several pages and requires precise language to be enforceable. Drafting each one from scratch isn’t sustainable.

• Customers have different requirements: Enterprise customers in particular will scrutinize your DPA closely and may request terms that deviate from your standard language.

• Version control becomes a problem fast: When DPA negotiations happen over email and documents live in separate systems, it’s easy to lose track of what was agreed and with whom.

The right CLM platform addresses all of this in one place. Most CLM platforms provide a basic repository to store your DPAs and simple templates to get you started. But our platform goes further by giving legal teams dynamic workflow capabilities that automatically route negotiated DPAs to the right stakeholders, extract critical metadata, and handle high contract volumes without slowing your team down.

If you’re ready to see how a CLM can simplify your DPA process, request a demo and we’ll walk you through it.

Frequently asked questions about data processing agreements

---

Ironclad is not a law firm, and this post does not constitute or contain legal advice. To evaluate the accuracy, sufficiency, or reliability of the ideas and guidance reflected here, or the applicability of these materials to your business, you should consult with a licensed attorney. Use of and access to any of the resources contained within Ironclad’s site do not create an attorney-client relationship

Sources

• Gartner, Most GC Pursue a Costly & Ineffective Contract Analytics Strategy, James Crocker, Rachel Pakianathan, and Rithika Lanka, 24 February 2026.