SaaS data processing agreement: what must it contain, and what should you require?

Almost every SaaS service processes personal data, whether it is an HR system, a CRM, an accounting solution or an AI tool. The customer is then usually the controller and the supplier the processor. This means that the customer bears the legal responsibility for the supplier’s processing, and the data processing agreement is the most important tool for managing that risk.

When do you need a data processing agreement for SaaS?

You need a data processing agreement when a SaaS supplier processes personal data on your behalf. The obligation follows from GDPR Art. 28(3), which applies in Norway through Personal Data Act § 1 in the Personal Data Act (personopplysningsloven). Storage, hosting, backup and support with access to data all constitute processing.

The decisive question is who determines the purposes and means of the processing. If the supplier uses the data for its own purposes, such as product development or training AI models, it is itself a controller for that part. Under GDPR Art. 28(10), a processor that goes beyond its instructions becomes a controller for that processing. The EDPB has elaborated on the distinction in Guidelines 07/2020.

Before the agreement is concluded, you must also satisfy yourselves that the supplier provides sufficient guarantees that the requirements of the GDPR will be met, under GDPR Art. 28(1). This is a separate obligation, and it is not fulfilled simply by signing an agreement.

What must a SaaS data processing agreement contain?

The agreement must be in writing, and electronic form is sufficient under GDPR Art. 28(9). It must set out the subject matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects and the obligations and rights of the controller. In addition, GDPR Art. 28(3) points (a) to (h) require the processor to commit to the following.

The processor must also immediately inform you if, in its opinion, an instruction infringes the rules. The European Commission has adopted standard contractual clauses for the relationship between controller and processor in Implementing Decision (EU) 2021/915, under GDPR Art. 28(7). They are voluntary, but serve well as a benchmark when assessing the supplier’s own agreement.

The data processing agreement does not shift responsibility to the supplier. It is the evidence that you have taken responsibility.

How should sub-processors be regulated?

The processor may only engage sub-processors with the prior authorisation of the controller, either specific or general, under GDPR Art. 28(2). With general authorisation, the supplier must give notice of intended changes so that you have the opportunity to object. In SaaS, general authorisation is the norm, because the service relies on cloud platforms, email services and support tools that are replaced over time.

Under GDPR Art. 28(4), the same data protection obligations must be passed on to the sub-processor, and the initial processor remains fully liable to you if the sub-processor fails to fulfil its obligations. In Opinion 22/2024, the EDPB took the view that the controller should at all times have access to information on the identity of all sub-processors in the chain, and that the final responsibility for accepting them lies with the controller.

The right to object is of little value if its only consequence is that you must terminate the service without compensation. Require at least 30 days’ notice, an up-to-date list of sub-processors with name, country and function, and the right to terminate without a termination fee and with a pro rata refund of prepaid fees if you do not accept the change.

What applies to transfers outside the EEA?

Transfers to countries outside the EEA must have a basis in GDPR Chapter V. This also applies where a sub-processor in the US has access to data in a European data centre, for example through support. The data processing agreement should therefore require all transfers to be listed, with country and transfer mechanism.

The most common mechanisms are an adequacy decision or the Commission’s standard contractual clauses in Implementing Decision (EU) 2021/914. If you use the standard contractual clauses, a transfer impact assessment must also be carried out. For the US, the supplier can rely on the Data Privacy Framework if the recipient is certified. How robust that framework is, and what you should keep in reserve, is explained in the article on transferring personal data to the US and the Data Privacy Framework.

Breach notification in the data processing agreement

The processor must notify the controller without undue delay after becoming aware of a personal data breach, under GDPR Art. 33(2). The law sets no deadline in hours for the supplier. It does for you, since as a rule you must notify the breach to the Norwegian Data Protection Authority (Datatilsynet) within 72 hours.

The agreement should therefore set a specific deadline, for example 24 or 48 hours, and specify what the notification must contain. Without this, you risk receiving the notification so late that the deadline towards Datatilsynet is already in jeopardy. See what you must do in the event of a personal data breach.

Audits, deletion and exit

The right to audit under GDPR Art. 28(3)(h) cannot be contracted away. Large suppliers often offer audit reports and certifications instead of your own inspections, and that is often a practical solution. Make sure, however, that the agreement still gives a right to further insight in the event of a specific suspicion of breach or an order from a supervisory authority, and that the cost provisions do not render the right illusory.

On termination, the supplier must delete or return the data at your choice. The agreement should specify the format, the deadline and confirmation of deletion, including in backups. This is closely linked to the terms for cloud exit, and the two should be read together.

Liability and limitation of liability

Both you and the supplier may be liable to data subjects under GDPR Art. 82, and the processor is liable where it has breached its specific obligations or acted outside its instructions. Administrative fines can be imposed on both. Between the parties, however, it is the agreement that decides who ultimately bears the loss.

Many SaaS agreements apply the general limitation of liability to breaches of the data processing agreement as well. This may mean that you are left with the costs of breach handling, notification and claims from data subjects, even though the supplier is at fault. Consider a separate, higher liability cap for data protection breaches. See more on limitation of liability in SaaS agreements.

What should the customer require in a SaaS data processing agreement?

The statutory minimum is not the same as a good agreement. The table shows where the supplier’s standard terms are typically weak.

If the service processes special categories of personal data or uses AI, you should consider whether a data protection impact assessment is required before the agreement is concluded. See DPIA for AI tools and the data protection topic page.

What should the business do?

1. Map which SaaS services process personal data, and check that there is a data processing agreement for each of them.
2. Assess the supplier before the agreement is concluded, with security documentation, certifications and a list of sub-processors.
3. Compare the supplier’s agreement with the standard clauses in Implementing Decision (EU) 2021/915 and note the deviations.
4. Negotiate a specific notification deadline, active notification of new sub-processors and a right to terminate at no cost.
5. Check transfers outside the EEA and document the transfer mechanism for each recipient.
6. Clarify whether the supplier uses data for its own purposes, in particular for training AI models.
7. Read the data processing agreement and the limitation of liability together, and consider a separate liability cap for data protection breaches.

See also the contracts topic page for more articles on SaaS agreements.

Questions and answers

Next legal review: 31 March 2027