Processor Agreement for a Software Company Example: The Key Provisions

An example of a Data Processing Agreement for a software company demonstrates which provisions are indispensable for a SaaS provider: obligation to follow instructions, security (Art. 32 GDPR), sub-processors and data location, notification obligation in the event of a data breach, audit, and the return or deletion of data at the end of the service. Below, we review these core provisions from the processor's perspective, outlining the key aspects of each component. Please note: an example is a starting point, not a ready-made solution — the key lies in tailoring it to your actual technology and sub-processors.

The short answer

• Roles and instructions: the customer is responsible; you process only on instruction.
• Processing overview: nature, purpose, data and data subjects in an appendix.
• Security (Art. 32): concrete measures.
• Sub-processors and data location: list, amendment procedure and EU/EEA principle.
• Reporting obligation and audit: deadlines and control rights.
• Return and disposal: procedure at the end of service.

An example starts with the roles

Every usable example opens with the division of roles. The customer is the data controller and determines the purpose and means; you, as the software supplier, process the personal data exclusively on their instructions. This instruction-dependent nature is the core of Article 28 of the GDPR. A good model therefore states that you only process as agreed, and which processing operations are “included” in your standard service — otherwise, any customer can impose separate instructions that your software cannot handle.

Provisions 1 and 2: processing overview and security

Processing overview (appendix). Article 28, paragraph 3 requires a description of the subject, duration, nature, and purpose, plus the categories of data and data subjects. For software, include this in an appendix that may vary slightly per client. Explicitly state whether special categories of personal data are involved.

Security (Art. 32). Here, customers expect concreteness. A strong example mentions encryption at rest and in transit, access control with two-factor authentication, separate environments, logging, backups, and a tested recovery process. Avoid the phrasing “appropriate measures” without substance — in the event of a data breach or audit, what is actually stated and done counts.

Provision 3: sub-processors and data location

For a software company, this is often the most important provision. You use cloud hosting, email, backup, and monitoring — all sub-processors. A good example covers:

• A list of sub-processors to which the customer agrees (general consent).
• A change procedure: you inform in advance about new sub-processors, with an objection period.
• The obligation to impose the same GDPR requirements on sub-processors that apply to you
• The data location: processing preferably within the EU/EEA, and for transfer outside, a legal basis such as the European Commission's Standard Contractual Clauses.

Provisions 4 and 5: reporting obligation and audit

Data Breach Notification Obligation. As a processor, you must inform the customer without delay in the event of a data breach, so that the customer can assess whether notification to the Dutch Data Protection Authority is necessary. A concrete example specifies a timeframe (for instance, within 48 hours of discovery) and the information you must provide.

Audit. The customer has the right of inspection. As a supplier with many customers, keep this manageable: offer an audit report or certification and attach reasonable conditions to physical audits (notification, frequency, costs). A good example balances the customer's right of inspection with the supplier's business operations.

Provision 6: return and disposal

At the end of the service, you must return or delete the data, at the customer's choice (Art. 28, paragraph 3, sub g). A useful example regulates:

• An export format in which the customer receives their data back.
• A removal period after expiration.
• Scope for statutory retention obligations that temporarily prevent deletion.

For a software company, this is also practically relevant: you want to know when you are allowed to delete customer data from your systems and backups.

Clause 7: Liability

Align the liability clause with your general terms and conditions. As a processor, you limit your liability within the bounds of the law; customers want flexibility. A template containing unlimited liability while your terms and conditions stipulate a limit leaves a gap in your protection. Align both documents.

Practical example

A project management software supplier used a template downloaded from the internet without a sub-processor appendix. When a customer asked where the data was stored, it turned out the agreement said nothing about this, even though the hosting ran partly outside the EEA. By supplementing the template with an up-to-date list of sub-processors, the data location, and a legal basis for data transfer, the agreement became complete and the customer could be reassured.

Honest recommendation

An example is an excellent starting point, and for a standard SaaS service involving ordinary personal data and common EU sub-processors, you can manage perfectly well on your own—provided you honestly complete the appendices (processing, security, sub-processors) regarding your actual setup. You do not necessarily need a lawyer in that case. However, never blindly copy an example if you process special categories of data, use sub-processors outside the EEA, or if liability is complex: in such cases, verification is advisable, because you, as the processor, bear the risk.

Want to look further? View the data processing agreement for a software company, read how to draft such an agreement , or have a custom one drawn up.

Frequently Asked Questions