The most common mistake when reviewing a data processing agreement is that companies sign the document without verifying who holds which role in that relationship. A data processing agreement sets out the terms between a controller, who determines why and how data is processed, and a processor, who does so on their behalf. If that role allocation is not verified, you may end up signing a document that does not apply to your situation at all, or you may miss an agreement that should have been in place.
Beyond that, three other issues frequently arise: sub-processors that are not listed, security measures described only in general terms, and no agreement whatsoever on what happens to the data once the cooperation ends. These are not minor details but the core purpose of a data processing agreement: to establish who is responsible for what, for as long as the cooperation lasts and afterwards as well.
Failing to verify the role allocation
A data processing agreement assumes a fixed division: one party determines the purpose and means of processing, the other carries out that processing according to instructions. In practice, those roles sometimes vary per assignment. An accounting firm is a processor for a client's payroll administration, but a controller for its own personnel data. If you sign an agreement without determining this role, you cannot be sure the correct document is being signed. The GDPR itself describes this role allocation, and the EDPB guidelines discuss it in detail.
Sub-processors that remain unidentified
Many SaaS tools in turn engage other parties, for example for hosting or customer service. A data processing agreement should specify whether that is permitted, on what terms, and whether you are informed in advance. If that provision is missing, you simply do not know which parties in practice have access to the data you provide. That is precisely the kind of information you can look up in the knowledge base by topic before you sign.
Security described only in general terms
A sentence such as "appropriate technical and organisational measures shall be taken" says little in itself. An agreement that goes further specifies in concrete terms what those measures entail: encryption, access control, backups, incident notification procedures. The more specifically this is documented, the clearer it is what a supplier actually does. By way of comparison: on the page about how we ourselves handle data and security you can see how such an explanation can look in practice.
No agreement on the end of the cooperation
What happens to the data once the contract ends? Are they returned, destroyed, or do they remain somewhere? This is one of the points most often missing, even though it is particularly difficult to make arrangements after cooperation has ended. A data processing agreement that says nothing about this leaves you with a gap in your records precisely when you can least afford it.
How to prevent this
Most of these mistakes do not stem from unwillingness but from lack of time: a data processing agreement is seen as a formality when substantively it concerns four or five concrete points. Review those points before you sign, and press the supplier for details if something is missing or vaguely worded. If you are in doubt about a specific provision, consult a lawyer or, for questions about the interpretation of the GDPR itself, contact the Data Protection Authority. You will also find answers to frequently asked questions about this type of document under the frequently asked questions about data processing agreements.
This explanation is intended to help you understand what should be included in a data processing agreement, not to assess whether a specific document you received meets those requirements. You can read about how we arrived at this information and which sources underpin it on the page about how it works.
Would you like to quickly see where your company stands? Take the free quick-scan or browse through the topics in the knowledge bank to see which step is relevant to your situation.