What this document is for

A GDPR Data Processing Agreement, often called a DPA, is a legal document used when one party processes personal data on behalf of another party. It sets out the rules, responsibilities, and safeguards that apply to that processing relationship under the General Data Protection Regulation and related data protection laws.

This document is typically used between a data controller and a data processor. The controller decides why and how personal data will be used, while the processor handles that data on the controller’s instructions. A DPA helps make that relationship clear and ensures the processor only uses personal data for authorized purposes, keeps it secure, helps with compliance, and supports the controller in meeting legal obligations.

A well-drafted GDPR Data Processing Agreement is important for businesses that use third-party service providers such as cloud platforms, payroll companies, CRM tools, email marketing services, analytics providers, customer support platforms, IT vendors, software developers, hosting companies, and outsourced operations teams. It creates a written framework for lawful personal data handling and helps reduce regulatory, contractual, and reputational risk.

When to use it

Use a GDPR Data Processing Agreement when one party will process personal data on behalf of another party in connection with a service, platform, or business relationship.

This document is useful when:

• a company uses a third-party software provider that stores customer data
• a business hires a payroll provider to process employee information
• a service provider handles personal data for support, hosting, analytics, or communications
• a vendor processes contact details, account data, or user records for a client
• a controller needs a compliant processor agreement before using a SaaS platform
• a business outsources data-related operations to another company
• a processor may use subprocessors to provide the service
• the parties need written terms on security, confidentiality, breach reporting, and deletion of data
• personal data of EU or UK individuals may be involved
• the service agreement exists, but the data protection terms need to be formalized separately

A DPA is especially important where the service involves customer records, employee data, marketing data, health-adjacent information, financial data, account data, or any other personal information protected by privacy law.

When not to use it

A GDPR Data Processing Agreement is not the right document for every privacy-related situation. Some relationships require a different type of arrangement.

You may need a different document if:

• both parties independently decide how and why the personal data is used, making them joint controllers or separate controllers
• no personal data is being processed at all
• the document needed is a privacy policy for website visitors rather than an inter-company agreement
• the relationship is purely internal within one organization
• the main issue is international transfer compliance rather than processor terms alone
• the parties need a broader commercial services agreement, not just data processing clauses
• the organization needs internal employee privacy notices or consent forms
• the arrangement concerns direct collection from individuals, not third-party processing on behalf of a controller
• the parties need standard contractual clauses or other transfer mechanisms in addition to a DPA
• the applicable law is not GDPR-focused and requires another privacy compliance document

A DPA does not replace a privacy policy, terms of service, cookie notice, or the main commercial contract. It usually works alongside those documents.

Key clauses explained

A GDPR Data Processing Agreement often includes several essential clauses. These should be clear, specific, and aligned with the real data processing relationship.

Parties and roles

This section identifies the controller and the processor. It is important to describe the roles correctly because GDPR obligations differ depending on whether a party is acting as a controller, processor, or joint controller.

Subject matter and duration

This clause explains what the processing relates to and how long it will continue. It often ties the DPA to a main services agreement.

Nature and purpose of processing

This section describes what the processor is doing with the personal data, such as hosting, storing, analyzing, transmitting, supporting, or deleting it.

Categories of personal data

A DPA should describe the types of personal data involved, such as names, email addresses, billing details, account data, employee records, usage data, or support information.

Categories of data subjects

This clause identifies whose data is being processed, such as customers, employees, website users, suppliers, job applicants, or contractors.

Controller instructions

The processor should only process personal data on documented instructions from the controller, unless required by law to do otherwise.

Confidentiality

This clause requires people authorized to process the data to keep it confidential and limits access to those who need it.

Security measures

A DPA should address technical and organizational measures used to protect personal data, such as access controls, encryption, backups, logging, staff training, and incident response procedures.

Subprocessors

If the processor may engage other vendors to help provide the service, this clause explains whether controller approval is needed and what obligations must flow down to those subprocessors.

Assistance with data subject rights

The processor may need to help the controller respond to requests relating to access, deletion, correction, portability, restriction, or objection.

Personal data breach notification

This section deals with how and when the processor must notify the controller if a personal data breach occurs.

Audits and information rights

A DPA often allows the controller to request information or evidence showing that the processor is meeting its GDPR obligations.

Return or deletion of data

At the end of the relationship, the DPA should explain whether the processor must return or delete personal data, subject to any legal retention requirements.

International transfers

If personal data will be transferred outside the relevant legal area, the agreement may need to address transfer safeguards such as standard contractual clauses or similar mechanisms.

Liability and interaction with the main contract

The DPA may explain how privacy-related liability fits with the broader commercial agreement, although this should be reviewed carefully.

Jurisdiction notes

A GDPR Data Processing Agreement is designed for situations involving the General Data Protection Regulation or similar European data protection regimes. However, the exact compliance requirements may vary depending on the countries involved, the location of the parties, the type of data, and whether other laws also apply.

Before using this GDPR Data Processing Agreement, check:

• whether GDPR applies to the controller, processor, or processing activity
• whether UK GDPR, EU GDPR, or both are relevant
• whether local implementing laws add extra requirements
• whether international data transfers are involved
• whether standard contractual clauses or other transfer mechanisms are needed
• whether the parties are actually controller and processor, rather than joint controllers
• whether the main services agreement already includes mandatory privacy wording
• whether sector-specific privacy rules apply
• whether the processor uses subprocessors in multiple jurisdictions
• whether data retention, security, or breach reporting rules require more specific wording

A DPA must reflect the actual data flow and legal roles. Using a generic document without understanding the controller-processor relationship can create compliance gaps.

How to fill this out correctly

To complete a GDPR Data Processing Agreement properly, make sure the document matches the real services and data handling activities.

1. Identify the parties clearly.
   Use the full legal names of the controller and processor.

2. Confirm the legal roles.
   Make sure one party is genuinely processing personal data on behalf of the other.

3. Describe the services involved.
   State what the processor is doing, such as hosting, support, payroll processing, analytics, or communications management.

4. List the categories of personal data.
   Include the types of personal data involved in the service.

5. List the categories of data subjects.
   Identify whose personal data is being handled.

6. Describe the purpose of processing.
   Explain why the processor is handling the data and how that relates to the services.

7. Include security commitments.
   Record the technical and organizational safeguards used to protect the data.

8. Address subprocessors.
   State whether subprocessors are allowed and what approval or notification process applies.

9. Set out breach reporting obligations.
   Make sure the processor must notify the controller without undue delay where required.

10. Deal with deletion or return of data.
    State what happens to personal data when the service ends.

11. Check transfer issues.
    If data crosses borders, make sure international transfer safeguards are addressed where needed.

12. Align the DPA with the main contract.
    Make sure the data processing terms do not conflict with the broader services agreement.

13. Have both parties sign or validly adopt the DPA.
    Keep a complete executed copy with the main commercial documents.

A DPA should be tailored to the real processing arrangement, not treated as a generic attachment with no relation to actual operations.

Common mistakes

Data processing agreements often become weak or non-compliant because they are copied without being adapted. Common mistakes include:

• identifying the parties’ roles incorrectly
• using a DPA where the parties are actually independent controllers
• failing to describe the processing activities properly
• using vague phrases without listing the types of personal data involved
• not identifying data subjects clearly
• omitting security obligations or making them too generic
• failing to deal with subprocessors
• ignoring international data transfers
• using a DPA that conflicts with the main services agreement
• not addressing deletion or return of data at the end of the relationship
• assuming a privacy policy is enough without a controller-processor agreement
• forgetting that UK and EU requirements may differ in some cases
• signing a template without checking how the service actually works

A DPA should reflect the real data lifecycle, not just satisfy a paperwork requirement.

Before you sign checklist

Before signing this GDPR Data Processing Agreement, review the following:

• Confirm the full legal names of both parties
• Check that the controller and processor roles are correct
• Review the description of the services
• Confirm the categories of personal data
• Confirm the categories of data subjects
• Check the stated purpose of processing
• Review confidentiality obligations
• Check the security measures described
• Confirm how subprocessors are handled
• Review assistance with data subject rights
• Check breach notification wording
• Confirm return or deletion terms
• Review any international transfer provisions
• Make sure the DPA aligns with the main services agreement
• Check whether local privacy laws add extra requirements
• Ensure both parties understand the obligations before signing

Completed sample

Below is an example of how a GDPR Data Processing Agreement might look once completed. This sample is for illustration only.

Controller:
Northbridge Commerce Ltd

Processor:
CloudAxis Systems GmbH

Main Service:
Cloud-based customer support platform and ticket hosting services

Processing Purpose:
The processor hosts and manages customer support data on behalf of the controller so that the controller can receive, track, and respond to support requests.

Categories of Personal Data:

• customer names
• email addresses
• phone numbers
• account IDs
• support request content
• usage logs

Categories of Data Subjects:

• customers
• prospective customers
• support users employed by the controller

Security Measures:

• role-based access controls
• encrypted data transmission
• audit logging
• backup procedures
• staff confidentiality obligations
• incident response procedures

Subprocessors:
The processor may use approved infrastructure and email delivery subprocessors subject to written contractual safeguards.

Breach Notification:
The processor must notify the controller without undue delay after becoming aware of a personal data breach affecting the personal data processed under the agreement.

End of Services:
Upon termination of the services, the processor must delete or return the personal data as instructed by the controller, unless retention is required by law.

Signatures:
Controller: ____________________
Processor: ____________________
Date: ____________________

FAQ

What is a GDPR data processing agreement?

A GDPR data processing agreement is a contract that sets out the data protection obligations of a processor handling personal data on behalf of a controller.

When is a DPA required?

A DPA is generally needed when one organization processes personal data on behalf of another in a controller-processor relationship governed by GDPR or similar privacy laws.

Is a DPA the same as a privacy policy?

No. A privacy policy explains how an organization handles personal data in relation to individuals. A DPA is an agreement between organizations about processing on behalf of a controller.

Can I use this DPA with any vendor?

Only if the vendor is actually acting as a processor on your behalf. If the vendor determines its own purposes and means of processing, the relationship may be different.

Does a DPA need to list subprocessors?

In many cases, it should address whether subprocessors are used and how they are approved or notified, because that is an important part of GDPR compliance.

Do I need standard contractual clauses as well?

Possibly. If personal data is transferred internationally in a way that requires additional safeguards, a DPA alone may not be enough.

Can this template cover employee data and customer data?

It can be adapted for different data categories, but the processing description should match the real services and data involved.

Should I get legal advice before using a GDPR DPA?

That is often sensible, especially for cross-border data processing, high-risk processing, sensitive data, or large-scale vendor relationships.

Related resources

You may also find these documents and guides useful:

• Privacy Policy
• Terms and Conditions
• Cookie Policy
• Data Sharing Agreement
• Non-Disclosure Agreement
• Service Agreement
• Information Security Policy
• Records of Processing Activities
• Standard Contractual Clauses
• Data Retention Policy