Data Processing Agreement — A Complete Guide to Article 28 GDPR

Every company that uses external service providers processing personal data on its behalf — an accounting firm, a hosting provider, a CRM system vendor, a marketing agency, an IT company, a cloud provider — is required to enter into a data processing agreement (DPA) with that entity. This obligation arises from Article 28 of the GDPR and applies to every data controller, regardless of the size of the organisation.

The absence of a data processing agreement is one of the most frequently identified violations during UODO audits — and one of the easiest to prevent. This article explains what a DPA is, when it is required, what it must contain, and what mistakes to avoid.

What Is Data Processing?

Data processing in this context refers to a situation where a data controller (the entity that determines the purposes and means of processing) entrusts the processing of personal data to another entity — a data processor, who acts on behalf of the controller and on the controller’s instructions.

The key distinction: the processor does not determine the purposes of processing — it carries them out on the controller’s instructions. If an entity independently determines the purposes of processing, it is not a processor but a separate controller (or joint controller).

Typical examples of data processing:

An accounting firm handling a company’s bookkeeping — processes employee and contractor data on behalf of the employer (controller).

A hosting provider storing data on its servers — processes data through storage on behalf of the website owner.

A cloud-based CRM provider (e.g., Salesforce, HubSpot) — processes customer data on behalf of the company using the system.

A marketing agency running an email campaign — processes customer email addresses on behalf of the commissioning company.

An IT company providing technical support — may have access to personal data in the client’s systems.

An external DPO — processes data on behalf of the controller in the course of performing the Data Protection Officer function.

Typical situations that are NOT data processing:

Disclosure of data to another controller — e.g., transmitting employee data to the social insurance institution (which is a separate controller, not a processor).

Use of postal services — the postal operator processes data as a separate controller under postal legislation.

Access to data by public authorities — e.g., providing data at the request of the police, a court, or the supervisory authority.

What Must a DPA Contain — Article 28(3) GDPR

Article 28(3) of the GDPR sets out the mandatory elements of a data processing agreement in detail. The absence of any element means the agreement is incomplete and may fail to meet GDPR requirements.

1. Subject matter and duration of processing A description of what the processing concerns and how long it will last. Example: “The Processor processes the personal data of the Controller’s customers for the purpose of providing hosting services for the duration of the main agreement.”

2. Nature and purpose of processing Why the data is processed and in what manner. Example: “Processing consists of storing, backing up, and making available personal data as part of the hosting service.”

3. Type of personal data What categories of data are covered. Example: “First name, surname, email address, phone number, IP address of the Controller’s customers.”

4. Categories of data subjects Whose data is processed. Example: “Customers, website users, employees of the Controller.”

5. Obligations and rights of the controller The controller’s powers vis-à-vis the processor — including the right to issue instructions, conduct inspections, and perform audits.

6. Processor obligations — the catalogue from Article 28(3)(a)–(h) GDPR:

a) Processing only on documented instructions of the controller — the processor may not process data for its own purposes or go beyond the controller’s instructions. The only exception: an obligation under EU or Member State law — but the processor must inform the controller before commencing such processing.

b) Ensuring confidentiality — persons authorised to process data (the processor’s employees) must commit to confidentiality or be subject to a statutory duty of confidentiality.

c) Implementing appropriate technical and organisational measures — the processor must ensure data security in accordance with Article 32 GDPR (encryption, pseudonymisation, access control, backups, security testing).

d) Conditions for engaging sub-processors — the processor may not engage another processor (sub-processor) without the controller’s prior authorisation. The GDPR provides for two authorisation models:

• Specific authorisation — the controller authorises each specific sub-processor.
• General authorisation — the controller gives general authorisation for the use of sub-processors, but the processor must inform the controller of any changes (addition or replacement of a sub-processor), giving the controller the opportunity to object. In practice, major cloud providers (Google, Microsoft, AWS) use the general authorisation model with a list of sub-processors published on their website.

e) Assisting the controller with data subject rights — the processor must assist the controller in responding to data subject requests (access, erasure, rectification, etc.), taking into account the nature of the processing.

f) Assisting with obligations under Articles 32–36 GDPR — the processor supports the controller in ensuring data security, reporting breaches, conducting DPIAs, and consulting the supervisory authority.

g) Deletion or return of data after processing ends — upon termination of the agreement, the processor must delete or return all personal data and delete existing copies, unless EU or Member State law requires further storage.

h) Making available information and allowing audits — the processor must make available to the controller all information necessary to demonstrate compliance with Article 28 obligations and allow and contribute to audits and inspections conducted by the controller or an authorised auditor.

Form of the DPA

Article 28(9) of the GDPR requires the data processing agreement to be in writing, including in electronic form. In practice, this may be:

A standalone data processing agreement — the most common solution, particularly in relationships with local providers.

An annex to the main agreement (e.g., a service agreement) — popular in IT provider relationships.

A Data Processing Agreement (DPA) / Data Processing Addendum — standard in relationships with international cloud providers. Google, Microsoft, AWS, and Salesforce make their DPAs available online as part of their service terms.

Clauses within the main agreement — permissible, provided they contain all required elements from Article 28(3).

Sub-Processors — The Processing Chain

In practice, most processors use sub-processors — for example, a cloud-based CRM provider uses hosting services from another entity (Amazon AWS, Google Cloud), which in turn may use subcontractors.

Processor obligations regarding sub-processors:

The processor must impose on the sub-processor the same data protection obligations that arise from the agreement with the controller (Article 28(4) GDPR).

If the sub-processor fails to fulfil its obligations, the processor bears full responsibility to the controller for the sub-processor’s performance.

What the controller should do:

Check whether your DPA regulates sub-processors (specific or general authorisation model).

Request the processor’s list of sub-processors — many providers publish this on their website.

Assess whether sub-processors provide an adequate level of protection — particularly if sub-processors are in third countries (outside the EEA).

Establish an objection procedure — what happens if you do not accept a new sub-processor?

Controller and Processor Liability

The GDPR allocates liability between the controller and the processor:

The controller is responsible for ensuring that processing complies with the GDPR — including selecting a processor that provides sufficient guarantees (Article 28(1) GDPR). The controller must exercise due diligence when selecting a processor.

The processor is responsible for processing in accordance with the DPA and the controller’s instructions. If the processor goes beyond the instructions and independently determines the purposes of processing, it becomes a controller in respect of that processing — and bears full responsibility.

Financial liability — Article 82 of the GDPR provides that both the controller and the processor may be liable for damages to data subjects. The processor is liable if it fails to comply with obligations specifically directed at processors under the GDPR or acts outside the controller’s instructions.

Processor Verification — Due Diligence

Article 28(1) of the GDPR requires the controller to use only processors that provide sufficient guarantees of implementing appropriate technical and organisational measures. In practice, this means verifying the processor before entering into the agreement and throughout the relationship.

What to look for during verification:

Security policies — does the processor have documented data protection and information security policies?

Certifications — does the processor hold ISO 27001, ISO 27701, or other security certifications?

Technical measures — encryption, access control, backups, security monitoring.

Breach response experience — does the processor have an incident response procedure?

Data location — where is data physically stored? Within the EEA or outside?

Sub-processors — who are they and where are they located?

References and track record — does the processor have industry experience?

Most Common DPA Mistakes

No agreement at all — the most serious mistake. The organisation uses a processor’s services without a formal DPA. UODO has imposed fines for this omission.

Internet template without customisation — copying a template agreement without adapting it to the specific relationship, data scope, and processing purposes. The agreement must reflect the actual situation.

No sub-processor regulation — the agreement does not address the rules for using sub-processors or does not specify the authorisation model.

No audit right — the agreement does not guarantee the controller the right to audit the processor. Article 28(3)(h) GDPR expressly requires this right.

Unclear data deletion rules — the agreement does not specify what happens to data after the relationship ends (deletion vs. return, deadlines, confirmation of deletion).

No breach procedure — the agreement does not address the processor’s obligation to inform the controller about data breaches. Article 33(2) GDPR requires the processor to notify the controller without undue delay.

Unilaterally imposed terms — major cloud providers (Google, Microsoft) impose their DPAs, which may not fully meet the controller’s needs. It is worth reviewing these documents and — where possible — negotiating modifications.

No updates — an agreement concluded in 2018 and never updated, despite changes in the scope of processing, addition of new services, or changes in sub-processors.

DPAs and Cloud Providers — Practical Tips

Most organisations use cloud services where the DPA takes the form of a standard DPA/DPA Addendum. Practical tips:

Google — the DPA is part of the Google Workspace and Google Cloud service terms. It includes SCCs for transfers outside the EEA. The list of sub-processors is available on Google’s website.

Microsoft — the Data Protection Addendum is part of Microsoft’s licensing agreements. Microsoft offers an EU Data Boundary. The list of sub-processors is available on Microsoft’s website.

Amazon AWS — the DPA is part of the AWS Service Terms. AWS offers a choice of data storage region. The list of sub-processors is available on AWS’s website.

For smaller providers — if a provider does not have a ready-made DPA, the controller should prepare a data processing agreement and present it to the provider for signature. Not having an agreement is not an option.

Checklist — Data Processing Agreement

1. Identify all processors — with whom do you share personal data as part of outsourcing?
2. Check that you have a signed DPA with each processor.
3. Verify the completeness of agreements — do they contain all elements from Article 28(3) GDPR?
4. Check sub-processor regulation — authorisation model, list, objection procedure.
5. Verify audit rights — does the agreement guarantee your right to audit the processor?
6. Check data deletion rules — what happens to data after the agreement ends?
7. Verify breach procedures — is the processor obliged to promptly inform you of incidents?
8. Assess data transfers — does the processor or its sub-processors transfer data outside the EEA? If so, are appropriate mechanisms in place?
9. Conduct processor due diligence — particularly for new providers.
10. Schedule regular reviews — DPAs should be updated at least once a year.

Need Help With Data Processing Agreements?

Data processing agreements are the legal foundation of outsourcing security. A poorly drafted agreement — or the absence of one — exposes the organisation to UODO fines and liability for damages. At the Law Office of Dr Joanna Maniszewska-Ejsmont, we prepare and review data processing agreements tailored to the actual relationship with processors — from small local providers to international cloud platforms.