GDPR for SaaS: Deletion Requests, DPAs and the Legal Risks Early Founders Should Plan For

How do I manage GDPR, data deletion requests and privacy compliance?

Work out where you are a controller and where you are a processor, put Article 28 data processing agreements in place with customers and sub-processors, and keep a record of what you process and where it goes. Then build a repeatable workflow for data subject requests: verify the person, find their data across every system, act within one month (extendable in complex cases), handle backups by putting data beyond use until it expires, and log what you did.

Step 1: Know whether you are a controller or a processor

The controller decides why and how personal data is processed; the processor processes it on the controller's behalf. The EDPB's Guidelines 07/2020 on the concepts of controller and processor are the authoritative explanation. For a typical B2B SaaS the split looks like this:

Step 2: Put DPAs and a sub-processor list in place

Article 28(3) GDPR requires processing by a processor to be governed by a contract that sets out the subject matter, duration, nature and purpose of processing and the data involved, and that commits the processor to, among other things: act only on documented instructions, keep staff under confidentiality, apply Article 32 security measures, assist the controller with data subject requests and breaches, delete or return data at the end of the service, and make information available for audits. In practice that means:

• Offer a standard DPA to customers. Enterprise buyers will ask; having one ready shortens the process.
• Sign DPAs with your own vendors (hosting, database, email, error tracking, AI providers). Article 28(2) says a processor must not engage another processor without the controller's prior specific or general written authorisation, and under general authorisation must tell the controller about changes so they can object.
• Publish a sub-processor list and a way to be notified of changes. It is also one of the first things a SaaS security questionnaire asks for.

Step 3: Keep records and plan international transfers

Article 30 requires records of processing activities. There is an exemption for organisations with fewer than 250 employees, but it does not apply if the processing is likely to result in a risk, is not occasional, or includes special category or criminal offence data, so most SaaS products that process data continuously should keep records anyway. A spreadsheet listing each data category, purpose, system, retention period, recipients and transfer mechanism is a reasonable start.

If data leaves the EU or UK, each transfer needs a mechanism. At the time of writing the European Commission lists adequacy decisions including the United Kingdom (renewed in December 2025) and the United States for commercial organisations participating in the EU-US Data Privacy Framework. Otherwise the usual tool is the Commission's standard contractual clauses (SCCs), modernised in June 2021. For UK transfers the ICO lists the International Data Transfer Agreement (IDTA) and the International Data Transfer Addendum to the EU SCCs as appropriate safeguards, alongside a transfer risk assessment. Transfer frameworks can change after court challenges, so in our view it is sensible to keep SCCs in your vendor contracts as a fallback even when a framework applies.

Step 4: Handle access and deletion requests on time

Article 12(3) requires you to act on a request without undue delay and within one month of receipt. That can be extended by two further months where necessary given the complexity and number of requests, but you must tell the person within the first month and explain why. The ICO adds practical detail: the clock usually starts on receipt, or once you have the information needed to confirm identity.

The right to erasure in Article 17 is not absolute. Article 17(3) lists exceptions, including processing needed to comply with a legal obligation (for example, keeping invoices for tax law), for public interest in public health, for archiving or research in limited cases, for freedom of expression, and for the establishment, exercise or defence of legal claims. Article 19 requires you to tell each recipient you disclosed the data to about the erasure, unless that is impossible or involves disproportionate effort.

An engineering workflow for deletion requests

1. One intake channel. A privacy email address or form, logged in a ticket with the date received; that date starts the clock.
2. Verify identity proportionately. A request from the account's own logged-in session or email is usually enough; do not ask for more data than you need.
3. Route processor requests to the customer. If the person is your customer's end user, tell the customer and help them, as your DPA requires; do not decide on their behalf.
4. Use a data map. Keep a list of every system holding personal data: primary database, file storage, search index, analytics, email and CRM tools, logs, error tracking, AI vendors. Deletion scripts should iterate over this list.
5. Delete or anonymise. Hard-delete rows where you can. Where other records depend on them (invoices, audit logs), keep the legally required minimum and anonymise the rest, and record which Article 17(3) exception you relied on.
6. Propagate to vendors. Call vendor deletion APIs or file their requests, per Article 19.
7. Confirm and log. Reply to the person, and keep a minimal record that the request was completed (not the deleted data itself).

Step 5: Be ready for breaches

Article 33(1) requires a controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in a risk to people; late notifications must include reasons. Article 33(2) requires a processor to notify the controller without undue delay, so your customer DPAs will usually set a specific timeframe. Article 34 requires telling affected individuals without undue delay where the breach is likely to result in a high risk. The ICO also says to record all breaches, including ones you do not report. Fold this into your incident runbook; our guide to running a SaaS covers the incident side.

US state laws in brief

The California Privacy Protection Agency's FAQ says the CCPA applies to for-profit businesses doing business in California that meet any of several thresholds: gross annual revenue of $26.625 million or more in the preceding calendar year (the figure from 1 January 2025, adjusted periodically), buying, selling or sharing the personal information of 100,000 or more California residents or households, or deriving 50% or more of revenue from selling or sharing it. It also places separate obligations on service providers and contractors, which is often where a B2B SaaS sits. Businesses must confirm a deletion, correction or access request within 10 business days and respond within 45 calendar days, extendable by another 45. Other states have their own laws, so check where your users are.