Key Takeaways

• Roles: A SaaS provider is usually a processor for its customers’ data, but it may be a controller for its own purposes, such as analytics, product improvement or training AI features. The SaaS agreement should reflect both.
• Processor terms: The UK GDPR and EU GDPR require specific contractual terms between controller and processor. Assistance, sub-processing, audits and deletion are where most negotiation happens.
• Recent changes: The Data (Use and Access) Act 2025 changed parts of UK data protection law in 2026, and the EU renewed its adequacy decision for the UK until December 2031.
• Liability: Customers increasingly ask for uncapped or higher liability for data protection breaches. A separate, defined data protection cap is often the most workable compromise.

A Software-as-a-Service (SaaS) agreement sets out the terms on which a provider makes software available to customers over the internet, rather than licensing a copy for installation. The provider hosts and manages the application and the data processed through it, and the customer and its users access the service online.

Because SaaS providers hold and process their customers’ data, often across several jurisdictions and through a chain of hosting and support providers, data protection is central to the agreement. Getting it wrong can expose the provider to regulatory action, claims from customers and lost sales. This article considers the key data protection elements of a SaaS agreement from the provider’s perspective under UK law, with reference to the EU where relevant.

Which data protection laws apply to SaaS providers?

A SaaS provider established in the UK, or offering its services to people in the UK, will generally be subject to the UK GDPR regulation and the Data Protection Act 2018. A provider established in the EU, or offering services to people in the EU or monitoring their behaviour, will also be subject to the EU GDPR regulation. Many providers must comply with both, as well as with applicable data protection laws of other countries in which they or their customers operate.

The UK regime was amended by the Data (Use and Access) Act 2025, most of whose data protection changes came into force on 5 February 2026. These include a new lawful basis of “recognised legitimate interests” for specified public-interest purposes, a more permissive framework for automated decision-making subject to safeguards, a revised test for international transfers, new exemptions from the consent requirement for certain cookies, and higher maximum fines under the Privacy and Electronic Communications Regulations. From 19 June 2026, controllers must also have a policy for handling data protection complaints. Providers should check that their customer terms, data processing agreements and privacy notices reflect these requirements and are up to date with changes in the law.

Is a SaaS provider a controller or a processor?

The roles of the parties determine their obligations, so the agreement should state them clearly. A controller decides the purposes and means of processing personal data; a processor processes personal data on the controller’s behalf and on its instructions.

In most SaaS arrangements, the customer is the controller of the personal data it uploads to or collects through the service, and the provider is its processor. The provider will, however, usually be a controller for some processing, such as managing its customer relationships and billing, and often for collecting usage data, improving the service or developing new features. The position needs particular care where the provider wishes to use customer data to train or improve AI models, since doing so for its own purposes is likely to make it a controller for that processing, with its own need for a lawful basis and transparency.

The agreement should therefore distinguish between processing carried out for the customer and processing the provider carries out for its own purposes, and set out the provider’s rights to use aggregated, anonymised or usage data. Customers will often scrutinise these rights closely.

What must a data processing agreement contain?

Article 28 of the UK GDPR (and of the EU GDPR) requires processing by a processor to be governed by a contract that sets out the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subjects, and the obligations and rights of the controller. Among other things, the contract must require the processor to:

• process personal data only on the controller’s documented instructions;
• ensure that people authorised to process the data are bound by confidentiality;
• implement appropriate technical and organisational security measures;
• engage sub-processors only with the controller’s authorisation and on equivalent terms;
• assist the controller with data subject requests, security, breach notification and data protection impact assessments;
• delete or return the personal data at the end of the services, at the controller’s choice; and
• make available the information needed to demonstrate compliance, and allow for and contribute to audits.

Many providers use a standard data processing addendum that applies to all customers. This supports the scalability on which the SaaS model depends, but enterprise customers will often seek to negotiate it.

How much assistance must a SaaS provider give?

Processors must assist controllers in meeting their obligations, but the extent and cost of that assistance is a commercial matter. A provider may wish to meet its obligations primarily through the functionality of the service, for example by giving customers tools to retrieve, correct and delete data, and to charge for assistance that goes beyond this. Customers may seek more extensive commitments, particularly on audits. A common approach is to rely on independent certifications or audit reports, with on-site audits limited in frequency and scope and subject to confidentiality and reasonable notice.

How should sub-processors be managed?

Most SaaS providers rely on third parties, including cloud hosting providers, data centres, support providers and, increasingly, third-party AI model providers. A processor may engage a sub-processor only with the controller’s prior specific or general written authorisation. Seeking specific approval from every customer for every change is rarely practicable, so providers usually rely on a general authorisation, combined with a published list of sub-processors, advance notice of changes and a right for the customer to object. The agreement should set out what happens if the customer objects, such as a right to terminate the affected service.

The provider remains liable to the customer for its sub-processors’ performance and must impose equivalent data protection obligations on them. Where sub-processors’ terms are non-negotiable, as is often the case with large cloud providers, the provider should check that they are consistent with the commitments it gives its customers.

What about international transfers?

The UK GDPR and EU GDPR restrict transfers of personal data to countries outside the UK and the European Economic Area unless the destination is covered by adequacy regulations or an adequacy decision, or appropriate safeguards are in place. For UK transfers, these safeguards typically take the form of the International Data Transfer Agreement or the UK Addendum to the EU standard contractual clauses. Under the Data (Use and Access) Act 2025, the question is now whether the standard of protection after the transfer is “not materially lower” than in the UK.

For transfers from the EU, the European Commission renewed its adequacy decision for the UK on 19 December 2025, so that personal data can continue to flow from the EEA to the UK until 27 December 2031, subject to ongoing monitoring. The SaaS agreement should identify where data will be hosted and accessed, including backups and support locations, and the transfer mechanisms relied on.

Data security and breach notification?

Both controllers and processors must implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. Customers will expect the agreement to describe the provider’s security measures, and providers are generally best placed to specify them. Describing the measures by reference to recognised standards, and reserving the right to update them provided that the overall level of security is not reduced, gives the provider flexibility as threats and technology change.

A processor must notify the controller without undue delay after becoming aware of a personal data breach, and the controller must generally notify the regulator within 72 hours where the breach is likely to result in a risk to individuals. Customers often seek a fixed notification period and detailed information about any breach, and the agreement should set realistic commitments.

Are there other rules to consider?

SaaS providers with EU customers should also consider the EU Data Act, which includes rules on switching between data processing services. From 12 January 2027, providers may no longer charge customers for switching to another provider. Where the service includes AI features, the EU AI Act may impose transparency and other obligations depending on how the features are used.

Limitation of liability

Customers frequently ask SaaS providers to accept unlimited liability, or liability outside the general cap, for breaches of data protection obligations. This can expose the provider to a level of risk out of proportion to the fees and to its insurance. A common compromise is a separate, higher cap for data protection claims. The wording needs care: in Drax Energy Solutions v Wipro [2023] EWHC 1342 (TCC), the court relied partly on the drafting of a separate data protection cap when deciding how the general cap operated. We consider limitation of liability more generally in our article on limitation of liability in technology contracts.

SaaS data protection: a practical checklist

For SaaS providers, data protection in customer agreements is likely to involve:

• Roles. Identifying when you act as processor and when as controller, including for usage data and AI features.
• Processor terms. A data processing addendum that meets Article 28 and reflects how your service actually works.
• Assistance and audits. Self-service tools where possible, clear limits on audits, and charges for additional assistance.
• Sub-processors. A general authorisation, a published list, notice of changes and a defined objection process.
• Transfers. A map of hosting, backup and support locations, and the transfer mechanisms relied on.
• Security and breaches. Security measures tied to recognised standards, and realistic breach notification commitments.
• Recent law. Terms and notices updated for the Data (Use and Access) Act 2025 and, for EU customers, the EU Data Act.
• Liability. A clearly drafted data protection cap that aligns with your insurance.

At Maybrook Law, we advise SaaS providers, technology companies and their customers on SaaS and cloud agreements, data processing terms, international transfers and data protection compliance. If you are developing or updating your customer terms, or would like to discuss any of the issues raised in this article, we would be pleased to advise on your position.

This article reflects the law as at 1 November 2026. Our insights, articles and guides do not, and are not intended to, constitute legal advice or be an exhaustive review of all legal developments. Although every effort is made to ensure that the information provided in this article is accurate as of the publication date, please be aware that this area of law is developing rapidly and may be subject to change. Please seek legal advice before applying the information provided to any specific circumstances, transactions or legal issues.