Data Processing Agreement (DPA): Elements & Template

The General Data Protection Regulation or GDPR mandates all organizations under its scope to have written Data Processing Agreements (DPA) with its vendors and third parties. However, EU is not the only region to mandate DPAs.

DPAs are also required by several other regulations in countries like the US (CCPA), China, Thailand, Turkey, India, South Africa, Brazil, etc. So, basically, if you’re giving a vendor power over your data, you need to have a written agreement. 

This blog discusses everything about Data Processing Agreements (DPAs)—their meaning, components, requirements, benefits, and a downloadable template you can use to hit the ground running.

TL;DR A Data Processing Agreement maintains accountability, defines responsibilities, forms a security assurance, and helps during cybersecurity audits.  A DPA contains details of processing activities, processor obligations, controller assistance, notification of non-compliance, etc. Challenges while drafting a DPA include certain clauses missing from Article 28 of GDPR, along with the absence of a time limit to notify breaches on behalf of processors.

What is a Data Processing Agreement (DPA)?

A DPA or Data Processing Agreement is a legal document that binds data processors and controllers to protect individuals by ensuring the safe storage, access, usage of their personal data. It defines the responsibilities with what can and can’t be done by the data processor. 

Data processor: A company or individual that processes personal data on behalf of the data controller, following their instructions. For example, a payroll service provider processing employee data for a company. Data controller: An entity that determines the purpose and means of processing personal data. They decide “why” and “how” the data is processed. For example, a business collects customer information for marketing purposes. Personal data: Any information about an identifiable person (data subject). Example: name, email, ID number, location data, or online identifiers, as well as factors specific to physical, genetic, mental, economic, cultural, or social identity.

A GDPR Data Processing Agreement, also called a data processing addendum, contains clauses on the rights and obligations regarding data processing. This is a compulsory ask for compliance (Article 28) if you collect information about EU citizens regardless of where your business is located. 

Apart from a mandate, why is a DPA necessary?

A DPA acts as a legal safeguard so controllers can confidently engage processors while meeting regulatory obligations. Even if you’re operating in a region where it’s not a compulsion, having a Data Processing Agreement protects you from unethical data processing practices. 

1. It maintains accountability: The DPA formalizes the processor’s obligations so they cannot go beyond their ethical processing. It holds them accountable if there’s a breach and ensures both parties understand their liabilities and legal recourse. 
2. It defines responsibilities: The agreement clearly defines the roles and responsibilities of both the controller and the processor to minimize misunderstandings and disputes.
3. It forms a security assurance: A DPA also contains security measures and practices aligning with GDPR requirements, providing assurance that the processor can protect the data effectively.
4. It helps during audits: It often includes provisions for audits or inspections, enabling the controller to verify that the processor adheres to the agreed-upon standards.

What elements should your DPA contain as per GDPR? (10 requirements)

As per Article 28 of the GDPR, a Data Processing Agreement (DPA) must contain all kinds of information related to processing activities. But it’s a little more complicated than that. 

Here are ten elements that are a must-have in your GDPR Data Processing Agreement:

1. Details of processing activities

The details include subject matter, duration, nature, purpose, type of data processed, and categories of data subjects. 

Describe the specific tasks or processes the processor will carry out, such as hosting, data storage, email marketing, or payroll processing. Specify the exact time period for which the processor will handle the personal data, whether tied to the contract’s length or until the data is no longer required.

Include details about the personal data types, such as names, email addresses, financial information, or health records. Lastly, identify whose data is being processed, e.g., employees, customers, or website users.

2. Processor obligations

The processor can only process data on instructions from the controller. Hence, the DPA should explicitly state that the processor cannot process data for its own purposes and must follow written instructions, including restrictions on data transfers to non-EU countries without appropriate safeguards.

Ensure all personnel who handle the data are either contractually or legally bound to maintain confidentiality, with regular training to reinforce these obligations.

As mentioned in Article 32, detailed measures such as encryption, pseudonymization, access controls, firewalls, regular system testing, and incident response protocols are used to prevent unauthorized access, loss, or breach.

3. Controller assistance

Processors must assist in fulfilling rights such as access, rectification, erasure (right to be forgotten), and data portability. For instance, they must provide tools or processes to retrieve or delete data upon request.

Help the controller to conduct Data Protection Impact Assessments (DPIAs) and meet breach notification timelines. Provide documentation or certifications as evidence of compliance efforts.

4. Engagement of sub-processors

Sub-processors need proper authorization to determine whether the controller provides specific (case-by-case) or general (pre-approval) authorization.

Set timelines for informing the controller about intended changes to sub-processors, allowing for objections within a defined period. It’s a good practice to require sub-processors to implement the same GDPR-level standards, ensuring they don’t introduce new risks to personal data.

5. End of processing obligations

After the time period for processing ends, specify how the processor will delete or securely return data upon contract termination, including timelines and methods for secure deletion.

In case of exceptions, address situations where legal or regulatory requirements necessitate retaining data, such as for tax or audit purposes.

6. Demonstrating compliance

Documentation is key to showcasing compliance. To demonstrate adherence to GDPR, maintain detailed records of processing activities, security measures, and incident logs.

For inspections, permit scheduled audits by the controller or third-party auditors detailing advance notice periods, audit scopes, and cost-sharing arrangements.

7. Notification of non-compliance

In case of a legal breach, mention the requirement of processors to promptly notify the controller if any instructions conflict with GDPR or other legal obligations, enabling the controller to amend the instructions.

Processors should also provide recommendations for legally compliant processing practices when needed.

8. Liability for sub-processors

For accountability, specify that the initial processor remains fully liable for sub-processor performance, ensuring the controller doesn’t bear additional risks from sub-processing arrangements.

The processor is also liable to resolve issues caused by sub-processors, including breaches or compliance failures.

9. Adherence to standards

If the processor complies with cybersecurity standards, include references to codes of conduct (Article 40) that demonstrate compliance with GDPR (e.g., information security certifications like ISO 27001).

10. Written agreement

The DPA must be formally documented and legally binding, whether as a standalone agreement or an appendix to the main service contract. Include provisions for amending the DPA in light of regulatory changes or evolving business needs.

The above ten requirements, however, are packaged differently when actually written in the formal DPA. Since it’s a legal document, ensure you follow the right template. You can download a ready-to-use template below.

Role of controllers and processors in a DPA

In a Data Processing Agreement (DPA), data controllers and data processors have distinct yet interconnected roles.

Controllers determine why and how personal data should be processed. When hiring a processor, they must ensure the processor has the right technical and organizational safeguards in place to protect the data. 

Processors, on the other hand, act on the controller’s instructions. Their role is to handle data securely, ensuring it is protected from unauthorized access, loss, or misuse. They must maintain confidentiality and implement all measures as implied in the DPA. 

As mentioned in the DPA, if they work with sub-processors, they need the controller’s approval and must pass on the same compliance obligations.

5 challenges you should expect while drafting a DPA (with solutions)

When you’re negotiating the clauses of a Data Processing Agreement, some sticking points can stall discussions between the two parties involved. 

Here are five common challenges and some practical ways to resolve them as suggested by Michael Whitener, Attorney and a VLP Partner:

1. Article 28 doesn’t mention processor’s liability

The GDPR doesn’t address liability limits, so it’s up to you to negotiate. Controllers often want no liability limits for data protection breaches, while processors push to include them. This tug-of-war can make things messy.

Solution: A clean approach is to address liability limits in the main services agreement, not the DPA itself. Many businesses now agree to a “super cap” for data protection breaches. Either a flat amount or a multiple of the fees is paid. This provides balance and clarity for both sides.

2. No clause if the controller objects to a subprocessor

Processors often need subprocessors to deliver their services, but controllers worry about losing oversight. The GDPR allows for “general” authorization (with notice) or “specific” authorization for subprocessors—but what happens if the controller objects? The same is not mentioned in Article 28, and this causes a dilemma. 

Solution: A middle ground is for the processor to notify the controller of any new subprocessor, allowing a set time (e.g., 15 days) to object. If no resolution is reached, the controller can terminate the agreement. This protects controllers without letting a single objection disrupt the processor’s operations.

3. Article 32 mentions broad security measures

Article 32 of the GDPR sets broad, risk-based security requirements, but controllers often try to impose their own detailed standards on processors. This can create conflicts, especially when processors work with multiple controllers.

Solution: Processors should rely on their own security frameworks but prove they meet GDPR standards. Controllers, in turn, should focus on whether those measures align with Article 32 requirements rather than forcing custom rules.

4. No time limit on processors to notify during breaches

Processors must notify controllers of data breaches “without undue delay,” as per GDPR, but controllers often push for stricter timelines like 24 hours. This can be unrealistic for processors, as assessing a breach properly takes time.

Solution: A feasible compromise is a 48-hour notification window, starting only when the processor confirms an actual breach (not just suspicions). This gives processors time to provide useful details while controllers still have room to meet their 72-hour reporting obligations.

5. Processors demand limited audit rights

Controllers have the right to audit processors for compliance, but processors usually want to limit scope, frequency, and intrusions. Controllers may even request audits of subprocessors, which can further complicate matters.

Solution: Controllers should start with documentation first. Processors can share certifications like SOC 2 reports or ISO 27001 for that. If that’s insufficient, an on-site audit can follow, but with agreed-upon timing, scope, and confidentiality terms. This balances transparency with practicality.

DPA is the legal part; what about the technicalities?

A well-structured DPA is undoubtedly necessary for GDPR compliance when transferring personal data, especially outside the EEA (European Economic Area). 

Alongside Standard Contractual Clauses (SCCs), DPAs provide the legal foundation to protect data and meet regulatory requirements. However, it’s important to understand that while GDPR mandates legal obligations like drafting DPAs and SCCs, it also emphasizes strong security and technical controls to protect personal data.

Sprinto simplifies the technical side of GDPR compliance, helping you bridge the gap between legal requirements and operational readiness.

How do we help?

• We set up a data protection policy and maintain staff acknowledgment.
• We provide updated security training materials to educate staff on GDPR responsibilities.
• We conduct thorough vendor risk assessments to evaluate third-party compliance.
• We assist in maintaining records of processing activities for transparency.
• We implement security and technical controls required under GDPR for critical systems (ideal for customers new to SOC 2 or ISO certifications).

Watch how Factors AI got GDPR and SOC 2 compliant with Sprinto:

Frequently asked questions

1. What is the purpose of a Data Processing Agreement?

The purpose of a Data Processing Agreement (DPA) is to establish clear responsibilities and obligations between a data controller and a data processor regarding the handling of personal data. It ensures compliance with data protection laws like the GDPR, safeguards the rights of data subjects, and outlines the terms for secure data processing.

2. Can the DPA be a part of the service contract?

Yes, a DPA can be integrated into the main service contract as a specific clause or appendix. However, it is often drafted as a separate legal document to clearly outline the roles, obligations, and legal requirements related to data processing.

3. When do organizations need a data processing contract?

Organizations need a DPA whenever a data controller (who decides how and why data is processed) engages a third-party data processor to process personal data on its behalf. This is especially necessary when the processing involves data subject to regulations like the GDPR, ensuring there are legal and technical safeguards in place for the data.

4. Is a DPA mandatory?

Yes, under the GDPR, a DPA is mandatory whenever a data controller outsources data processing to a third party. It is a legal requirement to formalize the processor’s obligations, including data security, handling data breaches, and assisting the controller with GDPR compliance. Without a DPA, organizations risk fines and penalties for non-compliance.

5. Who drafts a DPA?

A DPA is typically drafted by a legal expert or a lawyer specializing in data protection and privacy laws. Given its legal nature and the complexities of GDPR requirements, professional legal assistance ensures the document meets all regulatory obligations and minimizes liability for both the controller and processor.