What Is a Data Processing Agreement (DPA)? Guide & Free Template

In today’s digital economy, businesses rarely process personal data on their own. From cloud storage providers and communication platforms to payroll software and customer relationship management systems, organizations rely on a wide range of third-party service providers to support their operations. Whenever personal data is shared with these providers, businesses must ensure that such data is handled securely, lawfully, and in accordance with applicable privacy regulations.

This is where a Data Processing Agreement (DPA) becomes essential.

What Is a Data Processing Agreement?

A Data Processing Agreement is a legally binding contract between a data controller and a data processor that governs the processing of personal data. It establishes the rights and responsibilities of each party and sets out the rules for how personal data may be collected, used, stored, transferred, protected, and ultimately deleted.

In simple terms, a DPA serves as a roadmap for data protection. It ensures that personal data is processed only for authorized purposes and that appropriate safeguards are in place throughout the processing lifecycle.

Under privacy regulations such as GDPR, a DPA is not merely a best practice, it is a legal requirement whenever a processor handles personal data on behalf of a controller.

Practical Example

Consider a company that uses Slack as its internal communication platform.

By using Slack, the company may provide access to various categories of personal data, including:

• Employee names and business email addresses;
• Internal communications and private messages;
• Files and documents shared within channels;
• Customer information discussed during day-to-day operations.

Without a DPA, there may be uncertainty regarding how this information is processed and protected. A DPA addresses these concerns by clearly defining:

• What personal data may be processed;
• The purposes for which the data can be used;
• Security measures that must be implemented;
• Whether subcontractors may access the data;
• Rules for international data transfers; and
• What happens to the data when the service relationship ends.

In essence, the DPA establishes clear boundaries and accountability for the handling of personal data.

A well-drafted DPA serves several important purposes. Privacy laws around the world increasingly require organizations to establish contractual safeguards when engaging service providers that process personal data. Failure to have an appropriate DPA in place can expose businesses to regulatory scrutiny, penalties, and reputational damage.

Data breaches and cybersecurity incidents can occur even when businesses outsource certain functions. A DPA allocates responsibilities between the parties and helps ensure that processors maintain appropriate technical and organizational security measures.

Customers, employees, and business partners expect organizations to protect personal information responsibly. Demonstrating robust data governance practices helps build trust and strengthen commercial relationships.

Do You Actually Need a DPA?

If your business engages a third party to process personal data on your behalf, privacy laws such as the GDPR generally require a written agreement that sets out how that data will be handled.

You likely need a DPA if…

1) You are a controller

Your organization decides why and how personal data is processed.

2) A third-party processes personal data for you

Examples include cloud providers, payroll services, marketing platforms, customer support tools, hosting providers, and IT vendors.

3) The third party is acting on your instructions

They are not using the data for their own independent purposes, but to provide services to your organization.

In that scenario, a DPA is typically required under GDPR Article 28. Other privacy regimes may use different terminology, but they generally require contractual safeguards when service providers handle personal data on behalf of a business.

Ask yourself the following questions:

1) What is your role?

Are you a controller that determines the purposes and means of processing, or a processor that processes data on behalf of someone else?

2) Do you use third-party service providers?

Think about cloud hosting, payment processors, email platforms, CRM systems, HR tools, analytics providers, and IT support vendors.

3) What type of personal data is involved?

Sensitive data (health, financial, biometric, children’s data) increases risk and often requires stronger contractual and security controls.

4) Do you collect data through cookies or tracking technologies?

If so, you should also consider consent, transparency, and opt-out requirements under applicable privacy laws.

5) Do you transfer data internationally?

Using providers or servers in other countries may require additional transfer mechanisms and contractual safeguards.

6) Are you subject to laws such as the GDPR or CCPA/CPRA?

If you operate in, target, or collect data from individuals in those jurisdictions, you may have specific contractual obligations.

7) Do your contracts with providers contain privacy terms?

A generic services agreement is often not enough. The contract should address data processing obligations specifically.

8) Can you document your processing activities?

Organizations should generally be able to describe what personal data they collect, why they collect it, and where it is stored.

9) Do you have breach and subcontracting procedures?

You should know how incidents are reported, investigated, and communicated, and how subcontractors are managed.

10) Do you share personal data within a corporate group or with contractors?

Internal sharing may also require documented safeguards and appropriate agreements.

If you answered “yes” to #1 and #2, there is a strong chance you need a DPA. If you also answered “yes” to questions about sensitive data, international transfers, or GDPR applicability, the importance of having a properly drafted DPA increases significantly.

Need a DPA tailored to your business?

Get a Data Processing Agreement that reflects how your business handles personal data, works with service providers and allocates responsibilities. TAXUS can draft a new DPA or adapt a template to your needs.

Explore Contract Drafting

The Most Important Clauses in a DPA

Not all DPAs are created equal. While many organizations treat them as standard template documents, a poorly drafted DPA can create significant legal, operational, and compliance risks. A robust DPA should clearly define how personal data is handled throughout the entire business relationship and allocate responsibilities between the parties. Although the exact requirements vary by jurisdiction, most modern privacy laws share a common objective: ensuring that personal data remains protected even when processing activities are outsourced to third parties.

GDPR Requirements

For organizations subject to the GDPR, Article 28 sets out mandatory contractual provisions that must be included whenever a processor handles personal data on behalf of a controller. At a minimum, the processor must agree to:

• Process personal data only on documented instructions from the controller;
• Ensure that personnel authorized to access personal data are bound by confidentiality obligations;
• Implement appropriate technical and organizational security measures;
• Obtain authorization before engaging subprocessors and impose equivalent data protection obligations on them;
• Assist the controller in responding to data subject requests;
• Support the controller in meeting its GDPR compliance obligations, including security, breach management, and data protection impact assessments where applicable;
• Return or securely delete personal data at the end of the services; and
• Make available all information necessary to demonstrate compliance and facilitate audits.

CCPA/CPRA Requirements

Businesses operating in California face similar obligations under the California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act (CPRA). When personal information is shared with service providers, contractors, or third parties, the parties must enter into a written agreement that limits how the information may be used and imposes specific privacy obligations on the recipient. Among other things, such agreements should:

• Restrict the use of personal information to the purposes expressly described in the agreement;
• Require the recipient to provide a level of privacy protection consistent with applicable legal requirements;
• Grant the business the right to monitor and verify compliance;
• Require prompt notification if the recipient can no longer meet its privacy obligations; and
• Allow the business to take reasonable steps to remediate unauthorized processing.

Key Provisions

ESSENTIAL DPA CONTENT	DESCRIPTION
Must be a contract or other legal act that is binding	DPA must be in writing and executed by both parties as a standalone agreement or incorporated as part of another agreement
Subject matter and duration of processing	• Outline what you are trying to achieve with the personal data  • Outline the duration of the agreement with start and end dates  • Define conditions that would trigger termination (e.g. data processing cessation)
Nature and purpose of data processing	• Explain the context (e.g. marketing analysis, payroll)  • Be precise about the intended outcomes (e.g. improving services, legal obligations)
Categories of data subjects	Specify the people whose data you are processing (e.g. employees, customers, job applicants)
Types of personal data	• Specify the data type (e.g. names, addresses, financial details)  • Consider sensitive data (e.g. health information, racial or ethnic origin)
Obligations & responsibilities	Detail the specific obligations and responsibilities of both the controller and the processor, including that processor:  • Process personal data only on instruction of the data controller  • Ensure persons with access are subject to confidentiality  • Makes available to the controller all information necessary to demonstrate compliance with obligations laid down in this article  • Allow for audits or inspections to be carried out by the controller or its authorized representative  • Inform the controller if, in its opinion, any instructions infringe or breach any data protection or other State Member data protection provisions  • Assist the controller in fulfilling the controller’s obligation to respond to requests to exercise a data subject’s rights
Technical and organizational  measures	Processor shall:  • Assist the controller in compliance with the obligations set out in Article 32 to 36 of GDPR, taking into account the nature of processing and the information available to the processor  • Provide the controller with assistance to conduct a Data Protection Impact Assessment (DPIA), if needed  • Specify who has access to the personal data and under what conditions  • Outline the procedures for reporting breaches promptly, including the time for reporting to the controller, allowing them to respond within the statutory 72-hour time limit  • Describe the additional security measures in place (e.g. encryption), ideally using an appendix or annex to the processing agreement
International data transfers	Detail how cross-border data transfers comply with regulations (e.g. relying on SCCs, BCRs, adequacy)
Data retention and deletion	• Define how long data will be stored (e.g. based on legal requirements and business needs)  • Describe the conditions and process for securely erasing data or returning the data to the controller
Use of sub-processors	• Establish whether another processor can be engaged, either without prior specific or general written authorization of the controller  • Allow the data controller to object, within a reasonable time period, to the use of any particular sub-processor.  • Ensure the contract with the sub-processor is on the same/similar terms and incorporates the appropriate international transfer mechanisms where necessary  • Confirm that the processor is liable for any failure of its sub-processor  • Request a list of sub-processors being used by the processor

Common Misconceptions About DPAs

Despite becoming a standard component of modern business relationships, DPAs are still frequently misunderstood. One of the most common mistakes organizations make is assuming that other legal documents, such as privacy policies or non-disclosure agreements, can serve the same purpose as a DPA. They cannot.

A Privacy Policy Is Not a DPA

A privacy policy and a DPA serve entirely different functions. A privacy policy is an external-facing document that explains how an organization collects, uses, stores, shares, and protects personal data. It is typically addressed to customers, website visitors, employees, or other individuals whose data is being processed.

A DPA, on the other hand, is a contractual agreement between businesses. It governs the relationship between a data controller and a data processor and establishes the rules for handling personal data on the controller’s behalf.

While a privacy policy focuses on transparency towards individuals, a DPA focuses on accountability between organizations. For example, a privacy policy may inform users that a company uses a cloud-based customer relationship management platform. The DPA with that service provider will specify exactly how the provider may process the data, what security measures must be implemented, whether subprocessors can be used, and what happens to the data when the services end. Simply having a privacy policy does not satisfy the contractual requirements imposed by privacy regulations.

An NDA Is Not a DPA

Another common misconception is that an NDA can replace a DPA. Although both agreements deal with information protection, their objectives are fundamentally different. An NDA is designed to protect confidential information from unauthorized disclosure. It typically requires the receiving party to keep information confidential and use it only for limited purposes. A DPA goes much further.

An NDA may help protect confidential business information, but it generally does not contain the detailed privacy and compliance provisions required under modern data protection laws.

Privacy policies, NDAs, service agreements, and DPAs each serve a distinct purpose. While there may be some overlap between these documents, one should not be viewed as a substitute for another.

If a third party processes personal data on behalf of your organization, a properly drafted DPA is typically required regardless of whether you already have a privacy policy, an NDA, or a master services agreement in place.

🚩 DPA Mistakes Businesses Make

Even when organizations take data protection seriously, DPAs are often negotiated using overly broad templates or vendor-favorable terms. This can create significant compliance gaps, especially where critical clauses are vague, incomplete, or open-ended. Below are some of the most common red flags found in DPAs, and how they should be addressed in practice.

Unclear wording and unbalanced liability provisions can also affect the wider service agreement. Our guide to common contract mistakes and how to avoid them explains what to check before signing.

Unrestricted Geographic Processing

🚩 Risk Language: “Data may be processed in any jurisdiction where processor maintains operations.”

❌ Why It’s Dangerous: This type of clause creates a major compliance risk because it allows personal data to be processed in any country where the processor operates, regardless of the local level of data protection. This may include jurisdictions with limited privacy safeguards or broader government access rights.

🛡 Better Approach: “Customer data should be processed and stored only in jurisdictions with adequate data protection standards, such as the United States, European Union, Canada, or other countries explicitly approved by the customer. Where transfers occur, they should be subject to clearly defined legal safeguards and contractual restrictions.”

Vague International Transfer Language

🚩 Risk Language: “International transfers comply with applicable law.”

❌ Why It’s Dangerous: This wording is often too general to provide meaningful protection. It does not identify which legal mechanism governs the transfer or what safeguards are actually in place.

🛡 Better Approach: “International data transfers should explicitly reference the applicable transfer mechanism, such as Standard Contractual Clauses (SCCs), and include supplementary technical and organizational measures, including encryption, access controls, and monitoring.”

Unlimited Access to Personal Data

🚩 Risk Language: “Processor personnel may access customer data as necessary for service delivery and support.”

❌ Why It’s Dangerous: This clause provides broad discretion without defining who can access the personal data or under what conditions.

🛡 Better Approach: “Access to customer data is limited to processor authorized personnel whose specific job functions require such access, implemented through role-based access controls with quarterly access reviews and complete access logging.”

Broad and Uncontrolled Data Use

🚩 Risk Language: “Processor may use customer data for service improvement, analytics, and other lawful business purposes.”

❌ Why It’s Dangerous: This is one of the most problematic provisions, as it may allow the processor to reuse personal data for its own commercial benefit.

🛡 Better Approach: “The processor should be contractually limited to processing personal data strictly for the purpose of providing the services and only in accordance with documented instructions. Any secondary use should be explicitly prohibited.”

Weak Security Incident Notification Clauses

🚩 Risk Language: “Processor will notify customer of security incidents in a timely manner.”

❌ Why It’s Dangerous: Without defined timelines, this language creates uncertainty at a critical moment when rapid response is essential.

🛡 Better Approach: “Processor shall notify customer within 24 hours of discovering any security incident affecting customer data, with preliminary details provided within 2 hours of discovery.”

Incomplete Data Deletion Obligations

🚩 Risk Language: “Upon termination, processor will delete customer data from active systems.”

❌ Why It’s Dangerous: This wording fails to address residual copies, backups, archives, or technical environments where data may persist.

🛡 Better Approach: “Upon termination, processor shall securely delete all customer data, including backups and archived copies, and provide written certification of complete data destruction within 30 days.”

Regulatory Exposure and Consequences

Weak or incomplete DPAs are not just a contractual issue, they can result in significant regulatory and financial exposure.

Under the GDPR, organizations may face administrative fines of up to:

• €10 million or 2% of global annual turnover for certain infringements; or
• €20 million or 4% of global annual turnover for more serious violations.

Under the CCPA/CPRA, penalties may reach up to:

• $2,500 per unintentional violation; and
• $7,500 per intentional violation or violations involving minors.

Beyond fines, inadequate DPAs can also lead to reputational damage, loss of customer trust, and contractual disputes.

Received a DPA from your service provider?

Before you sign, understand what you are agreeing to. TAXUS can review the document, flag unclear or one-sided terms and propose practical changes to data use, security, subprocessors and liability clauses.

Explore Contract Review

FAQs

1. What is the difference between a data controller and a data processor?

A data controller determines why and how personal data is processed. In most cases, this is the business that collects personal data from customers, employees, or users and decides the purpose of the processing. A data processor processes personal data on behalf of the controller and only according to the controller’s instructions. Examples include cloud service providers, payroll platforms, hosting providers, and customer support software vendors.

2. What is a subprocessor?

A subprocessor is a third party engaged by a processor to assist in providing services involving personal data. For example, a SaaS provider may use cloud infrastructure providers, support vendors, or security service providers to deliver its services. A DPA should clearly address whether subprocessors may be used, how they are approved, and how equivalent data protection obligations are imposed on them.

3. Is a DPA legally required?

In many cases, yes. Under the GDPR, a written DPA is generally mandatory whenever a processor handles personal data on behalf of a controller. Similar contractual requirements exist under other privacy laws, including the CCPA/CPRA and various international data protection frameworks. If your organization shares personal data with a third-party service provider that processes the data on your behalf, a DPA should typically be in place.

4. Can a privacy policy replace a DPA?

No. A privacy policy informs individuals about how an organization collects, uses, and protects personal data. It is an external-facing document designed to promote transparency. A DPA is a contractual agreement between organizations that governs the processing of personal data and allocates legal responsibilities between the parties. Both documents serve important but entirely different purposes.

5. What happens if a business does not have a DPA?

Failure to implement an appropriate DPA may expose an organization to regulatory penalties, contractual disputes, and increased compliance risks. In certain circumstances, regulators may view the absence of a required DPA as a violation of applicable privacy laws. In addition to financial penalties, businesses may also face reputational damage and increased scrutiny from customers, partners, and regulators.

Download a DPA Template

Need a starting point for your agreement? Download the TAXUS DPA template and use it to structure discussions with your service providers.
Before using it, adapt the wording to your data processing activities, the responsibilities of each party and the laws that apply to your business.

Download the DPA Template

Please note: This template is provided for informational purposes only and does not constitute legal advice. It should be reviewed and adapted to reflect your specific business model, data processing activities, and applicable legal requirements before use.

If you use AI to adapt this template, read our article on AI contract drafting to understand why a polished draft still needs a review of its legal terms and business context.