Data Processing Agreement Template: What to Include and How to Use It

A data processing agreement template is a written contract that defines how personal data flows between a data controller (the organization that decides why and how data is processed) and a data processor (the vendor or service provider that handles that data on the controller's behalf). Templates provide a structured starting point for this legally required document, but they must be reviewed and customized to match your actual data flows, vendors, and jurisdiction.

Direct answer: A data processing agreement (DPA) is a written contract required under data protection laws like GDPR that specifies how a processor will handle, store, and protect personal data on behalf of a controller. It must include processing scope, security measures, sub-processor management, and data subject rights. Templates accelerate the process, but customization to your specific vendors, data categories, and jurisdiction is essential—a generic template signed without review creates compliance gaps and leaves both parties exposed.

Key concepts you'll encounter:

• Data Controller: The organization that determines the purposes and means of personal data processing.
• Data Processor: A vendor or service provider that processes data on the controller's instructions.
• Personal Data: Any information that relates to an identified or identifiable individual.
• GDPR: The General Data Protection Regulation, which requires a written DPA between controllers and processors in the EU and EEA.
• Standard Contractual Clauses (SCCs): EU-approved contract language for transferring personal data outside the EU/EEA.

---

What a Data Processing Agreement Actually Does

A data processing agreement is not a compliance checkbox—it's a working document that maps responsibility and defines the rules for how data moves through your vendor ecosystem. Without it, neither party has a clear, written understanding of who must do what, who bears liability if something goes wrong, and what happens to the data when the relationship ends.

Why controllers and processors need a written agreement

GDPR Article 28 requires that processing by a processor on behalf of a controller be governed by a contract or other legal act that is binding on the processor. This is not optional. The agreement must specify the subject matter, duration, nature, and purpose of processing, as well as the type of personal data and categories of data subjects. Without a written DPA, both the controller and processor face regulatory enforcement action.

From a practical standpoint, a DPA also protects both parties by clarifying expectations. The processor knows exactly what security measures they must implement, what data they can and cannot share, and what happens if a data breach occurs. The controller knows who is responsible for responding to data subject requests, maintaining audit logs, and deleting data at the end of the contract.

What happens without a DPA in place

If you process personal data through a vendor without a DPA, you are operating outside the legal framework required by data protection law. Regulators like the UK Information Commissioner's Office (ICO) treat the absence of a written agreement as a serious compliance gap. Beyond regulatory risk, you have no contractual recourse if the processor mishandles data or fails to implement promised security measures.

How a DPA differs from other data protection documents

A DPA is distinct from a general service agreement or terms of service. While a service agreement covers pricing, support, and liability for service availability, a DPA specifically addresses how personal data will be handled. A DPA is also different from a Data Protection Impact Assessment (DPIA), which is a risk analysis document you create to evaluate whether a processing activity poses high risks to individuals. A DPA is the contract; a DPIA is the risk assessment that often precedes it.

---

Core Sections Every DPA Template Should Include

A complete DPA template includes six core sections that regulators and auditors expect to see. Each section serves a specific function in defining the relationship and protecting both parties.

Scope and data categories

This section names the specific types of personal data being processed, the categories of individuals those data relate to, and the purposes for which processing occurs. Rather than writing "customer data," a proper DPA specifies: "Name, email address, phone number, and purchase history of end users in the European Union, processed for the purpose of order fulfillment and customer support."

Being specific matters because it limits the processor's authority. If the template says "any data the controller provides," the processor has no clear boundary on what they can access or use.

Processor responsibilities and restrictions

This section defines what the processor can and cannot do with the data. It must state that the processor will process data only on documented instructions from the controller, will not process data for their own purposes, and will ensure that persons authorized to process the data have committed to confidentiality. The European Data Protection Board (EDPB) emphasizes that this section must be explicit and binding.

Security and confidentiality obligations

Here you specify the technical and organizational measures the processor must implement: encryption at rest and in transit, access controls, employee training, incident response procedures, and audit rights. A vague clause like "appropriate security" is insufficient. Instead, name the standards: "AES-256 encryption for data at rest, TLS 1.2 or higher for data in transit, and annual third-party security audits."

Sub-processor management

A processor often uses sub-processors (other vendors) to handle parts of the data. Your DPA must require the processor to get your prior written approval before engaging a sub-processor, to inform you of any changes, and to ensure that sub-processors are bound by the same data protection obligations. Without this clause, you lose visibility and control over your data supply chain.

Data subject rights and assistance

The DPA must state that the processor will assist the controller in fulfilling data subject requests—such as requests to access, correct, delete, or port personal data. (inform users about how their data is processed) The processor must provide the controller with the information needed to respond to these requests within legal timeframes.

Duration and data return or deletion

The DPA must specify what happens to the data when the contract ends. Typically, the processor must either delete the data or return it to the controller, unless law requires the processor to retain it. This section also sets the term of the agreement and conditions for renewal or termination.

---

How to Customize a Template for Your Business

A generic template is a starting point, not a finished document. Customization is where templates become useful rather than theoretical. The goal is to move from a one-size-fits-all clause to language that reflects your actual data flows, vendor relationships, and risk profile.

Identify your data categories and processing purposes

Start by listing every type of personal data you process through this vendor. Do not write "customer data"—instead, write: "First name, last name, email address, phone number, billing address, IP address, and browsing behavior." Next, write the specific purposes: "To deliver the service, to send transactional emails, to prevent fraud, and to comply with tax law." Be as narrow as possible. If you do not need a data category for a stated purpose, do not include it in the DPA.

Map your sub-processors and third-party vendors

Create a list of every vendor or sub-processor that will touch the data. If your main processor uses a payment gateway, analytics tool, or backup service, those are sub-processors and must be listed in the DPA or in an appendix that you can update. Many templates include a schedule or exhibit for this purpose.

Define security standards and encryption requirements

Do not copy a generic "reasonable security" clause. Instead, specify the exact standards your organization requires. For example: "Data at rest must be encrypted using AES-256 or equivalent. Data in transit must use TLS 1.2 or higher. Access must be restricted to named individuals with a documented business need. Multi-factor authentication must be enabled for all administrative access."

If you do not have a security standard yet, consult with your IT or security team to define one. In practice, teams that skip this step often end up with vague agreements that do not actually enforce the security they need.

Set approval and review workflows

Define who in your organization must approve the DPA before signing, and how often it will be reviewed. A common workflow is: Legal reviews for compliance, Security reviews for technical adequacy, and Finance or Procurement signs off on terms. Set a review cadence—for example, "annually or whenever a sub-processor is added."

Align with your jurisdiction and applicable law

Specify which law governs the DPA and where disputes will be resolved. If you operate in the EU, the DPA must comply with GDPR. If you also operate in the UK, you may need UK-specific language. If you transfer data outside the EU/EEA, you must include Standard Contractual Clauses (SCCs) or another approved transfer mechanism.

DPA Customization Checklist

Use this checklist to move from a generic template to a document that reflects your actual data flows and risk profile.

---

Where to Find and Evaluate DPA Templates

Several reputable sources provide DPA templates, ranging from free open-source documents to vendor-specific and paid legal templates. Understanding the source and evaluating the template for your jurisdiction and use case is critical.

Open-source and free templates

Common Paper offers a free, open-source Data Processing Agreement that is GDPR-compliant and designed to be clear and fair to both parties. GDPR.eu provides template resources and guidance on what a DPA should include. These are good starting points, especially if you are new to DPAs, but they are generic and will require customization for your specific vendors and data flows.

Vendor-provided templates

Many SaaS vendors and cloud providers include a DPA as part of their standard contract terms or offer one on request. Examples include AWS, Microsoft Azure, and Salesforce. Vendor templates are often already aligned with their service, but they are written to protect the vendor's interests. You should review them against your security requirements and customize any clauses that do not match your risk tolerance.

Legal document platforms

Platforms like LawDepot, Rocket Lawyer, and Termly offer DPA templates for a fee. These are typically reviewed by lawyers and are jurisdiction-specific (e.g., GDPR-compliant for EU operations, CCPA-compliant for California). The trade-off is cost versus the assurance that a lawyer has reviewed the language.

What to check before using a template

Before adopting a template, verify:

• Jurisdiction alignment: Does the template comply with GDPR, UK GDPR, CCPA, or other laws that apply to your operations?
• Data transfer mechanisms: If you transfer data outside the EU/EEA, does the template include Standard Contractual Clauses or other approved mechanisms?
• Sub-processor management: Does the template allow you to add and update sub-processors without renegotiating the entire agreement?
• Security specificity: Does the template require specific security measures (encryption, access controls, audit rights) or only vague language like "reasonable security"?
• Liability and indemnification: Are the liability limits and indemnification terms acceptable to your organization?
• Termination and data handling: Are the conditions for terminating the agreement and handling data at the end of the relationship clear?

---

Common Mistakes When Using a DPA Template

Teams often treat templates as one-size-fits-all documents and skip critical customization steps. The result is agreements that do not actually reflect how data flows through the organization or what security measures are in place.

Using a template without reviewing your actual data flows

The most common mistake is copying a template and signing it without first documenting what data you actually process through the vendor. This creates a mismatch between the DPA and reality. If the DPA says you process "customer email addresses and purchase history" but you also send IP addresses and browsing behavior, the processor is not contractually bound to protect those additional data types.

Fix: Before customizing a template, map your data flows. List every data type, every purpose, and every vendor involved.

Forgetting to list all sub-processors

A processor often uses other vendors—payment gateways, analytics tools, backup services—without the controller knowing. If these sub-processors are not listed in the DPA or in an appendix, you have no visibility or control over them.

Fix: Ask the processor for a complete list of sub-processors and include it in the DPA. Set a requirement that the processor notify you before adding or changing sub-processors.

Leaving security clauses too vague

A clause that says "the processor will implement appropriate security measures" is unenforceable. If a breach occurs, you cannot prove the processor violated the agreement because "appropriate" is undefined.

Fix: Specify encryption standards (AES-256, TLS 1.2), access controls (MFA, role-based access), and audit rights. Reference industry standards like ISO 27001 if applicable.

Failing to update when vendors or processes change

A DPA is a living document. If you add a new sub-processor, change your data retention policy, or update your security standards, the DPA must be updated. Many teams sign a DPA and then ignore it, leading to outdated agreements that no longer reflect reality.

Fix: Set a review cadence—at minimum annually, or whenever a material change occurs (new vendor, new data type, security incident). Document who is responsible for updates.

---

FAQ

Do I need a separate DPA for each vendor or processor?

Yes, you should have a DPA with each vendor that processes personal data on your behalf. However, some vendors use a single master DPA with appendices or schedules for different services or data types. The key is that each processing relationship must be documented. If a vendor refuses to sign a DPA, you cannot use them to process personal data.

Can I use a free DPA template instead of hiring a lawyer?

Free templates like those from Common Paper or GDPR.eu are a good starting point and are often reviewed by data protection experts. However, they are generic and require customization for your specific vendors, data flows, and jurisdiction. If your data processing is straightforward and low-risk, a free template may be sufficient. If you process sensitive data, transfer data internationally, or operate in a regulated industry, consulting a data protection lawyer is advisable.

What's the difference between a DPA and a Data Processing Addendum (DPA)?

These terms are used interchangeably. A Data Processing Agreement and a Data Processing Addendum both refer to the same document—a contract that governs how a processor handles personal data on behalf of a controller. Some organizations use "Addendum" when the DPA is attached to a larger service agreement; others use "Agreement" when it is a standalone document. The legal function is the same.

How often should I update my DPA?

Review your DPA at least annually, and immediately when a material change occurs: adding or removing a sub-processor, changing your data retention policy, updating security standards, or moving data to a new location. Many organizations tie DPA reviews to their vendor management and security review cycles.

What happens if I don't have a DPA in place?

Operating without a DPA violates GDPR and other data protection laws. Regulators treat this as a serious compliance failure. You have no contractual recourse if the processor mishandles data or fails to implement promised security measures. You also cannot demonstrate to auditors or customers that you have contractual safeguards in place.