MKB Juristen drafts custom legal documents
It is best not to cobble together or copy important contracts, terms and conditions, and other legal documents yourself. We help entrepreneurs on a budget with customized legal solutions, clear costs upfront, and practical explanations.
- Custom contracts, terms and conditions, and legal documents
- Budget-friendly and clear about the costs upfront
- Request a free consultation or a no-obligation quote
What is a Data Processing Agreement for a software company? It is the agreement in which you, as a SaaS provider or software developer, stipulate how you process the personal data that your customer (the data controller) entrusts to you. Article 28 of the GDPR mandates this agreement as soon as your software processes personal data on behalf of the customer — which is almost always the case with an online platform, an app, or a cloud service. You are then the processor, and that role entails its own obligations: security, sub-processors, notification requirements, audits, and the return of data at the end of the service.
The short answer
- What: a mandatory agreement (Art. 28 GDPR) between your software company and the customer regarding the processing of personal data.
- Your role: processor — you process data exclusively on behalf of the client.
- Key topics: purpose and nature of processing, security (Art. 32), sub-processors, data location, data breach notification obligation, audit and return/deletion.
- Who draws it up? In practice, almost always the software vendor itself, as a fixed part of the terms of service.
- When: before the first processing, i.e. at the start of the subscription or implementation.
What exactly is a data processing agreement for a software company?
The GDPR distinguishes between two roles. The customer determines why and how personal data is processed: that is the controller. You, as the software supplier, process that data on behalf of the customer and according to their instructions: that is the processor. This relationship arises as soon as a SaaS platform, an email tool, an accounting app, or a customer portal stores or processes third-party personal data.
Article 28(3) of the GDPR stipulates that this relationship must be recorded in writing (or digitally). Without a data processing agreement, both the customer and you are acting in violation of the GDPR. For a software company, the agreement is not a separate piece of paper, but a structural part of your service: you enter into it with every business customer who processes personal data via your software.
Why the processor side is different
Most explanations regarding data processing agreements are written from the client's perspective. For a software supplier, the emphasis is different. You determine the technical setup, choose the hosting and sub-processors, and are responsible for security. The client typically signs your template, not the other way around. This means that your data processing agreement must realistically align with how your service works technically.
A few points that carry more weight for you as a processor:
- Instruction-dependent. You may only process data on the customer's instruction. Therefore, describe precisely which processing operations are “included” in the standard service, so that not every customer can impose separate instructions.
- Sub-processors. You will almost certainly use cloud and infrastructure providers (hosting, email, backup, monitoring). These are sub-processors and must be properly arranged.
- Security. Article 32 of the GDPR places part of the technical and organizational measures on you. You must be able to demonstrate what you do.
- Liability. As a processor, you want to limit your liability; customers, on the other hand, want room. You strike that balance here.
The key agreements at a glance
A workable data processing agreement for a software company regulates, in any case:
- Subject and duration of processing, linked to the term of the subscription.
- Nature, purpose, and type of data: which categories of data subjects and personal data your software affects (often in an appendix).
- Security measures in accordance with Article 32, such as encryption, access control, and logging.
- Sub-processors: a list and a procedure for changes.
- Data location: where the data is located (EU/EEA) and what applies to transfers outside of it.
- Data breach notification obligation: the timeframe within which you inform the customer.
- Audit and cooperation: how the client can exercise control.
- Return and deletion of data after completion.
Subprocessors and cloud
Virtually no software company runs entirely on its own hardware. You use cloud hosting, an email provider, a payment service, and a monitoring tool. All those parties that process personal data on your behalf are sub-processors. Article 28, paragraphs 2 and 4 of the GDPR stipulates that you may only engage sub-processors with the customer's consent and that you must impose the same obligations on them as those that apply to you.
In practice, you usually work with general consent: the customer agrees to a published list of sub-processors, and you inform them in advance of any changes, including a period for objection. This is workable for large numbers of customers. Pay attention to the data location: if a sub-processor (for example, a large cloud provider) operates outside the EEA, you need a valid legal basis for transfer, such as the European Commission's Standard Contractual Clauses.
Security, data breaches and end of service
Three topics that often come down to when it comes to software:
- Security (Art. 32). Describe concretely what you do: encryption of data at rest and in transit, two-factor authentication, separate environments, backups, and recovery procedures. Be honest about what you do and do not offer.
- Notification obligation. In the event of a data breach, you, as the processor, must inform the customer “without delay” so that they can assess whether notification to the Dutch Data Protection Authority is necessary. Set a realistic timeframe, for example, within 48 hours of discovery.
- Return and deletion. Upon completion of the service, you must return or delete the data, at the customer's choice. Arrange an export format and a deletion period, and take statutory retention obligations into account.
Practical example
A SaaS provider of planning software for the healthcare sector entered into a data processing agreement with every customer but had recently moved the hosting to a new cloud provider without updating the list of sub-processors. When a customer conducted an audit, it turned out that the data location no longer matched the agreement. By keeping the list of sub-processors up-to-date from then on and informing customers in advance, the problem was resolved structurally — and the audit was completed more quickly.
Honest recommendation
As a software supplier, you need a data processing agreement — this is not a choice, but a legal obligation. The main question is whether to engage a lawyer yourself. If you run a standard SaaS service with common sub-processors and ordinary (non-sensitive) personal data, you can manage perfectly well with a well-thought-out standard template that you have drafted once and then reuse for all customers. However, if you process sensitive data (healthcare, financial), have customers who impose their own templates, or work with many sub-processors outside the EEA, then legal guidance is indeed advisable — precisely because you bear the risk.
Want to know more? View the data processing agreement for a software company, read how to draft such an agreement and which pitfalls to avoid.
Frequently Asked Questions
It is the agreement required under Article 28 of the GDPR in which your software company, as a processor, sets out how it processes the personal data entrusted to it by the customer (controller). Topics include security, sub-processors, data location, notification obligations, and data return.
Usually a processor: you process personal data on behalf of and at the instruction of your client. You are the controller for your own client administration, but for the data that clients process via your software, you are a processor.
Yes. As soon as your software processes personal data on behalf of the customer, an agreement is mandatory under Article 28 of the GDPR. Without an agreement, both you and the customer are acting in violation of the GDPR.
In practice, it is almost always the software vendor itself, as a fixed part of the terms of service. You use one standard model for all your clients. Large clients sometimes impose their own model; in that case, you assess whether it aligns with your technology.
These are parties you engage who, in turn, process personal data, such as your cloud hosting, email provider, or monitoring tool. You may only use them with the customer's consent and must impose the same GDPR obligations on them that apply to you.
Preferably within the EU/EEA. If data is held by a sub-processor outside this area, you need a valid legal basis for transfer, such as the European Commission's Standard Contractual Clauses. Clearly define the data location in the agreement.
At completion, you return the data or delete it, at the customer's choice. Establish an export format, a deletion period, and any statutory retention obligations to ensure there is no ambiguity at the end of the service.