GDPR for SaaS in 2026: A Practical Compliance Guide

If your SaaS touches the personal data of anyone in the EU or UK, GDPR applies — wherever your company is based. Eight years on it is no longer new, but it remains the single most common privacy requirement in enterprise procurement. This guide cuts through the legalese to what a SaaS team actually needs in place.

This is practical guidance, not legal advice — confirm specifics with a qualified data-protection professional.

Controller or processor? Usually both

The first thing to get straight is your role. For your customers’ data that you process on their behalf, you are typically a processor. For your own employee and prospect data, you are a controller. Most SaaS companies are both at once, and the obligations differ — so map which hat you wear for each data set before anything else.

The core obligations

Sub-processors: the part SaaS teams forget

Your cloud host, analytics, email provider, and support tools are all sub-processors handling your customers’ data. GDPR requires you to keep a current sub-processor list, flow your DPA obligations down to each of them, and give customers notice of changes. This overlaps heavily with vendor risk management — see our guide to third-party risk — so manage them in the same place.

International data transfers

Moving EU or UK personal data outside those regions needs a valid transfer mechanism — an adequacy decision, Standard Contractual Clauses (with the UK addendum where relevant), or another recognised safeguard. If you use US-based infrastructure, document which mechanism you rely on and keep it current as the legal landscape shifts. Offering an EU data-residency option is increasingly a deal-maker for European buyers.

Handling data subject requests at scale

You must be able to find, export, correct, or delete an individual’s data across every system that holds it — within one month. The teams that handle this calmly are the ones that mapped their data flows in advance and built repeatable processes, rather than scrambling each time a request lands.

Lawful basis: the question that decides everything downstream

Every processing activity needs a lawful basis under Article 6, chosen before you process and documented. You cannot switch later because the first one became inconvenient, and you cannot fall back on consent when legitimate interests fails.

For a B2B SaaS company, three bases do almost all the work:

The most common mistake is reaching for consent because it feels safest. It is usually the weakest option for a SaaS company: it can be withdrawn at any moment, and if withdrawal would break the service you were never genuinely relying on it.

What your Article 30 record has to contain

Records of processing activities are a hard requirement for most organisations, and the exemption for under-250-employee companies is narrower than people assume — it falls away where processing is not occasional, where it is likely to risk individuals’ rights, or where special category data is involved. A SaaS product processing customer data continuously will not qualify.

It does not need to be elaborate. A spreadsheet with a row per processing activity works, provided each row carries the purpose, the categories of data subject and personal data, the recipients including sub-processors, any transfers outside the UK or EEA with the safeguard relied on, retention periods, and a description of your security measures.

Maintain it as one record covering both your controller activities (your own staff, prospects, website visitors) and your processor activities (your customers’ data). Keeping two separate documents is how they diverge.

Breach notification: the 72-hour clock

As a controller you have 72 hours from becoming aware of a personal data breach to notify your supervisory authority, unless the breach is unlikely to result in risk to individuals. As a processor you must notify your controller — your customer — “without undue delay”, and your DPA almost certainly commits you to something more specific.

Two points teams get wrong. First, the clock starts at awareness, not at conclusion of the investigation — you can and should file an incomplete notification and follow up. Second, “breach” is broader than a hack: accidental deletion, sending data to the wrong recipient, and losing an unencrypted laptop all qualify.

• Know which supervisory authority you report to, and register for their online form before you need it.
• Keep an internal breach log even for incidents you decide not to report — the decision and its reasoning are part of your accountability evidence.
• Check the notification window in your own DPA. Many processors commit to 24 hours, which leaves the controller time to meet their own 72.
• Where risk to individuals is high, you must also tell the individuals — a separate and much harder conversation to run unprepared.

UK and EU GDPR are now two regimes

Since Brexit the UK operates its own GDPR alongside the Data Protection Act 2018, and while the two remain closely aligned, they are separate laws with separate regulators. If you process data from both, you are subject to both.

Practical consequences: you may need a representative in one bloc or the other if you have no establishment there, transfers into the UK and into the EEA rely on different paperwork (the UK addendum or the IDTA, rather than the EU SCCs alone), and enforcement comes from the ICO in one case and the relevant EU authority in the other. Adequacy decisions currently bridge the two, but they are reviewed periodically rather than permanent — worth a calendar note rather than an assumption.

A pragmatic starting checklist

GDPR overlaps substantially with ISO 27001 and SOC 2 — much of the security evidence is shared. If you are building a broader programme, treating privacy and security together avoids duplicate work; our continuous compliance guide shows how to keep it all current.