In this article we will discuss...
Data Processing Agreement under GDPR: when it is required and what it must include
When a company receives a Data Processing Agreement, or DPA, it is common for practical questions to appear immediately: why do I have to sign it, does it make me responsible for the client’s data, do I need it for a one-off service, what happens if I use cloud tools, artificial intelligence or subcontract part of the work?
The short answer is this: a DPA is not a decorative compliance document. It is one of the central instruments required by the General Data Protection Regulation whenever a supplier processes personal data on behalf of another organisation.
If your company hires an accountant, IT support provider, software provider, marketing agency, hosting service, billing platform, CRM, HR tool, app developer or any other supplier that can access personal data, you may need a contract that complies with Article 28 GDPR.
And if you are the supplier, signing a DPA does not mean you can use the client’s data freely. It means the opposite: you may process the data only within the scope of the service, under documented instructions, and with sufficient guarantees.
Quick summary
A processor is an organisation or person that processes personal data on behalf of a controller and under its instructions.
The DPA is required when a supplier needs to access or process personal data in order to provide a service to the controller.
Not every supplier is a processor. The key point is not the commercial label but the reality of the service: who determines the purpose, who determines the essential means, and whether the supplier uses the data for its own purposes.
A DPA should regulate, at least, the subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects, documented instructions, confidentiality, security measures, subprocessors, assistance with data subject rights, personal data breaches, audits and the return or deletion of data at the end of the service.
What is a processor?
A processor is a natural or legal person, public authority, agency or other body that processes personal data on behalf of the controller.
- The controller decides why personal data is processed.
- The processor processes the data to provide a service to the controller.
- The processor may not use the data for its own purposes.
- The processor must follow the controller’s documented instructions.
For example, if a company hires a payroll provider, the company decides that employee data must be processed for employment and payroll purposes. The payroll provider accesses the data to provide the payroll service. In that case, the provider will usually act as a processor.
The same may happen with IT maintenance, hosting, email marketing platforms, billing software, HR platforms, CRM tools, developers configuring an application or suppliers automating internal processes.
What is a controller?
The controller determines the purposes and essential means of the processing of personal data.
In practice, the controller decides what personal data is collected, why it is processed, how long it is retained, who may access it, which suppliers are involved, what legal basis applies, what information is provided to data subjects and what organisational controls must be in place.
The processor does not replace the controller. The controller remains responsible for ensuring that the processing is properly defined, lawful, transparent and protected.
Controller vs processor: practical difference
| Question | Controller | Processor |
|---|---|---|
| Who decides the purpose? | The controller | Does not decide the purpose |
| Who decides the essential means? | The controller | May decide non-essential technical or organisational means |
| For whom is the data processed? | For the controller’s own purposes | On behalf of the controller |
| Can the data be used for own purposes? | Yes, if there is a legal basis and GDPR is complied with | No, unless it acts as controller for a separate processing activity |
| Is an Article 28 GDPR contract needed? | The controller requires it from the processor | The processor signs and complies with it |
| Can processing be subcontracted? | Authorises or refuses subprocessors | Only with prior authorisation from the controller |
The most important difference is simple: the controller decides; the processor executes on behalf of the controller.
Not every supplier is a processor
This is one of the most common mistakes. Being a supplier does not automatically mean being a processor.
A supplier may be a processor, an independent controller, a joint controller, a recipient of data, or a provider with no access to personal data at all.
For example, an IT maintenance company that can access databases, email accounts or devices may be a processor. However, a professional who receives personal data and decides independently how to use it for its own professional activity may act as an independent controller.
Common mistake. Signing a DPA does not automatically turn a supplier into a processor. The legal qualification depends on the real processing activity, not on the title of the document.
When is a DPA required?
A DPA is usually necessary when three elements are present:
- There is a service relationship.
- The supplier accesses or processes personal data.
- The processing is carried out on behalf of the controller and under its instructions.
| Service | May require a DPA? | Reason |
|---|---|---|
| Payroll provider | Yes | Accesses employee data to provide payroll services |
| Web hosting | Yes | Hosts databases, forms or user accounts |
| IT support | Yes | May access devices, credentials, emails or systems |
| CRM software | Yes | Processes customer or contact data on behalf of the client |
| Email marketing platform | Yes | Manages campaigns using the controller’s contact database |
| Marketing agency | It depends | May act as processor or controller depending on the use of data |
| AI provider | It depends | Review whether data is used only for the client or also for training or own purposes |
| External consultant with no access to personal data | Not necessarily | If there is no access to personal data, there is no processing mandate |
The right question is not: is this a supplier? The right question is: does this supplier need to process personal data on behalf of my company in order to provide the service?
When is a DPA not necessary?
A DPA is not necessary where the supplier does not process personal data on behalf of the controller.
- A provider that delivers office supplies without accessing personal data.
- A service provider that does not access systems, databases or information about individuals.
- A professional acting as an independent controller.
- A third party receiving data for its own purposes with its own legal basis.
- A joint controllership relationship, which requires a different arrangement.
Using DPAs “just in case” can create confusion, artificial obligations and an inaccurate picture of the relationship.
Article 28 GDPR explained simply
Article 28 GDPR requires the controller to use only processors providing sufficient guarantees, and to regulate the processing by a contract or other legally binding act.
That contract must describe the processing and impose specific duties on the processor: documented instructions, confidentiality, security, subprocessor rules, assistance to the controller, breach notification, cooperation with audits and deletion or return of data at the end of the service.
In short, Article 28 turns the DPA into a tool for control, security and accountability. It is not just a formality.
What should a Data Processing Agreement include?
| Block | What it regulates |
|---|---|
| Identification of the parties | Who acts as controller and who acts as processor |
| Subject matter of the processing | The service and why it involves personal data |
| Personal data affected | The categories of data the processor may process |
| Categories of data subjects | Customers, employees, users, suppliers, contacts, patients, students, etc. |
| Purpose | What the processor may use the data for |
| Documented instructions | The limits and operational rules of the processing |
| Duration | How long the processing mandate lasts |
| Access methods | How the processor accesses data or systems |
| Confidentiality | Who may access the data and under which commitments |
| Security | Technical and organisational measures |
| Subprocessors | Whether subcontracting is allowed and under what conditions |
| International transfers | Whether data leaves the EEA and which safeguards apply |
| Data subject rights | How the processor assists the controller |
| Personal data breaches | How and when incidents must be notified |
| End of the service | Return, deletion or transfer to a new processor |
| Sufficient guarantees | Evidence of compliance, audits, certifications or security controls |
Need to review or sign a Data Processing Agreement?
Auratech Legal Solutions can help you determine whether a supplier acts as processor, independent controller or subprocessor, and adapt the agreement to the real service.
Clause-by-clause guide
1. Identification of the parties
The contract must clearly identify the controller and the processor: legal name, tax details where relevant, address, representative and contact details. This section fixes the legal architecture of the relationship.
2. Background and service context
The agreement should explain the commercial service and why the supplier needs access to personal data. A generic clause is weaker than a clause that describes the actual service.
3. Subject matter and purpose
The subject matter describes what the processor is engaged to do. The purpose sets the permitted use of the data. The processor should not be allowed to use the data for analytics, marketing, AI training or product improvement unless this is expressly analysed and lawful.
4. Categories of data and data subjects
The agreement should identify the relevant categories of data and individuals: customers, employees, users, suppliers, candidates, patients, students or contacts. This helps calibrate security measures and risk.
5. Documented instructions
The processor may process personal data only on documented instructions from the controller, unless required by EU or Member State law. The contract should explain how instructions are given and what happens if an instruction appears unlawful.
6. Access to data
Access may happen through remote support, user accounts, cloud platforms, shared folders, APIs, backups or administrative panels. The agreement should describe real access routes and apply least privilege, traceability and secure authentication.
7. Duration and end of the service
The DPA should state when the processing begins, when it ends and what happens afterwards. At termination, data should be returned, deleted or transferred to another processor, unless retention is legally required.
8. Subprocessors
The processor may not engage subprocessors without prior specific or general written authorisation from the controller. The same data protection obligations must be imposed on subprocessors, and the processor remains responsible for their performance.
9. International transfers
If data is accessed from outside the EEA, or if cloud or support providers located outside the EEA are involved, the agreement must address the transfer mechanism, such as adequacy decisions, Standard Contractual Clauses and transfer impact assessments where required.
10. Security measures
Security must be appropriate to the risk. Depending on the service, measures may include access controls, multi-factor authentication, encryption, backups, logging, segregation of environments, vulnerability management, incident response and staff training.
11. Data subject rights
The processor must assist the controller in responding to access, rectification, erasure, restriction, portability, objection and automated decision-making requests. The processor should not answer data subjects directly unless instructed to do so.
12. Personal data breaches
The processor must notify the controller without undue delay after becoming aware of a personal data breach. The contract should define channels, minimum information, cooperation duties and timing.
13. Audits and evidence
The processor must make available information necessary to demonstrate compliance and allow audits, including inspections where appropriate. In practice, this may include policies, certificates, security reports or contractual evidence.
Processors and artificial intelligence
AI tools require special attention. A supplier may act as a processor when it uses an AI tool only to provide the service under the controller’s instructions. But if the supplier uses personal data to train models, improve its own products, create profiles or reuse the data for independent purposes, the analysis changes.
Before allowing AI tools in a processing chain, review what data is entered, whether prompts or outputs are stored, whether the provider uses the data for training, where processing takes place, which subprocessors are involved, how deletion works and what security controls apply.
Auratech tip. A good DPA should not simply say “AI tools are allowed”. It should identify the tool, the purpose, the data categories, retention, subprocessors, international transfers and the controller’s instructions.
Common mistakes in DPAs
- Calling every supplier a processor without analysing the real processing activity.
- Using a generic template that does not describe the service.
- Failing to review subprocessors.
- Ignoring international transfers and cloud support access.
- Allowing the supplier to use data for its own purposes.
- Leaving security measures vague.
- Not regulating personal data breaches.
- Failing to define what happens to data at the end of the contract.
- Assuming the DPA legitimises the controller’s main processing activity.
- Thinking that signing the agreement removes responsibility.
What happens if there is no DPA?
If a processor processes personal data without the required Article 28 agreement, both compliance and control are weakened. The controller may be unable to demonstrate that it selected a processor with sufficient guarantees and that processing is subject to documented limits. The processor may also be exposed for failing to comply with its own GDPR obligations.
The issue is not only regulatory. Without a proper DPA, it is harder to manage breaches, subcontracting, international transfers, data deletion, audits and responsibility between the parties.
Checklist before signing a DPA
- Confirm whether the supplier is actually a processor.
- Describe the real service and processing activity.
- Identify data categories and data subjects.
- Review access methods and user permissions.
- Check subprocessors and cloud providers.
- Identify international transfers.
- Define security measures.
- Regulate breach notification and cooperation.
- Clarify return or deletion at the end of the service.
- Review whether AI tools are used.
- Keep evidence of sufficient guarantees.
Frequently asked questions
Do all suppliers have to sign a DPA?
No. A DPA is required when the supplier processes personal data on behalf of the controller. If there is no access to personal data, or if the supplier acts as an independent controller, a DPA may not be the right instrument.
Can a freelancer be a processor?
Yes. A natural person or freelancer can act as a processor if they process personal data on behalf of a controller and under documented instructions.
Is an IT company always a processor?
Not always. It depends on whether the IT company can access personal data and whether it processes the data on behalf of the client.
Is a payroll provider a processor?
Usually yes, because it processes employee data to provide payroll services on behalf of the employer.
Is a cloud software provider a processor?
Often yes, but the terms must be reviewed carefully, especially regarding subprocessors, international transfers, support access and data use for product improvement.
Does the DPA replace the privacy policy?
No. The DPA regulates the controller-processor relationship. It does not replace privacy notices, legal basis analysis or transparency duties towards data subjects.
Does the DPA make the processing lawful?
No. The controller must still have a valid legal basis and comply with GDPR principles. The DPA regulates outsourcing of processing; it does not legitimise the underlying processing by itself.
Can the processor subcontract?
Only with prior authorisation from the controller and by imposing equivalent data protection obligations on the subprocessor.
Can the processor use AI tools?
Only if this fits the controller’s instructions, the tool is properly assessed and the DPA or related documentation covers security, subprocessors, data retention and international transfers.
What should the processor do after the contract ends?
It must return or delete the personal data, according to the controller’s instructions, unless EU or Member State law requires retention.
Data Processing Agreement adapted to the real service
A strong DPA does not merely copy Article 28 GDPR. It identifies access, subprocessors, security measures, breaches, AI, international transfers and the fate of data at the end of the service.
Conclusion
A Data Processing Agreement is one of the key documents in GDPR compliance whenever a supplier processes personal data on behalf of another organisation. It should not be treated as a formality or as a generic template.
The best DPA is the one that reflects the real service, the real access to data, the real tools used and the real risks of the processing chain.