GDPR Checklist for SaaS: 14 Technical Requirements to Get Right

A GDPR checklist for SaaS comes down to 14 technical requirements: know what personal data you hold, keep tenants apart, let customers export and delete their data, log who accessed what, control your subprocessors and spot a breach in time. Most are cheap to build in from day one and expensive to retrofit once an EU customer sends a security questionnaire.

I'm a developer based in Denmark, not a lawyer. This covers the engineering side, not legal advice, so have a lawyer or privacy consultant review your contracts and privacy policy.

The short answer: 14 requirements

Requirements 6-8 take the most work to retrofit, so plan them early. If you're still mapping out the whole product, start with my guide to building a SaaS and treat this list as its technical appendix.

Processor or controller: know your role first

When customers put data about their staff or clients into your product, they're the controller and you're the processor, acting only on their instructions. The EDPB explains the distinction in its guidelines on controllers and processors. For your own customers' accounts and billing, you're the controller.

Being outside the EU doesn't change that: the GDPR applies to non-EU companies that offer services to people in the EU. The UK has its own near-identical law, the UK GDPR, but this checklist follows the EU text.

As a processor, you need a data processing agreement (DPA) with each customer under Article 28 of the GDPR. It typically promises security, help with data subject requests, deletion when the contract ends and breach notification, all of which your code has to deliver.

Data and access: requirements 1-5

1. You know where the data lives

Map the tables and columns that hold personal data, uploaded files and the services that get a copy, such as error tracking and search. Processors also have to keep a record of the processing they carry out for customers (Article 30(2)). Without the map, you can't export or delete reliably.

2. Tenants are isolated in code

The worst privacy bug a SaaS can ship is customer A seeing customer B's data. With a shared database, every query needs a tenant filter, ideally applied automatically. I compare the models in my post on multi-tenant SaaS architecture. Write tests that try to read another tenant's records and run them on every change.

3. Least-privilege access

Inside the product, that means roles; here's how to design roles and permissions from the start. Behind the product, it means two-factor authentication on hosting, database and code repository, personal accounts instead of shared logins, and access revoked the day a contractor leaves. If support needs to see a customer's account, build a logged "impersonate user" feature.

4. Encryption in transit and at rest

HTTPS is the baseline. Check that your database, file storage and backups are encrypted at rest, which most major hosts offer. Encrypt sensitive fields such as national ID numbers or customers' API keys in the application, for example with Laravel's built-in encrypted cast.

5. An audit log of access and changes

An audit log records who did what and when: logins, exports, deletions, permission changes and support access to customer accounts. It lets you answer a customer who asks whether anyone viewed their data. Keep it separate from your application logs, which should never contain passwords or tokens.

Export and deletion: requirements 6-9

6. Export for users and tenants

Individuals have a right of access (Article 15) and a right to receive their data "in a structured, commonly used and machine-readable format" (Article 20), and you have to help your customer meet those requests. Build export for one user and for a whole tenant, such as JSON or CSV in a zip file. The controller generally has one month to respond (Article 12(3)), so a documented manual process can work while you're small.

7. Deleting a user

Deletion has to reach the database, uploaded files, search index, cache and third parties such as your email and help desk tools. A soft delete, where the row is only flagged, isn't enough on its own. Use a short grace period, then a job that permanently deletes or anonymizes the record. If the law requires you to keep something, such as accounting records, document why.

8. Offboarding a tenant

When the contract ends, you must return or delete the customer's data, at their choice (Article 28(3)(g)). That takes an export, an agreed deadline and a job that deletes the whole tenant. Backups are the tricky part: let them expire after a fixed window, such as 30 days, make sure deleted data stays deleted after a restore, and state the window in your DPA.

9. Retention rules that run themselves

Personal data shouldn't be kept longer than necessary (Article 5(1)(e)). Turn that into scheduled jobs: delete unverified accounts, clean up trials that never converted and purge old logs after a fixed period. Keep the rules in one place so they can go into your DPA and privacy policy.

Vendors, backups and incidents: requirements 10-14

10. A subprocessor list

Hosting, file storage, transactional email, error tracking, help desk, analytics and AI providers are typically all subprocessors. Your customer has to authorize them, and under a general authorization you must announce changes so they can object (Article 28(2)). Publish a list with name, purpose and location. LLM providers are no exception, as I cover in GDPR and LLM APIs.

11. Data location and transfers

The GDPR doesn't require data to stay in the EU, but a transfer to, say, the US needs a legal basis. On 10 July 2023 the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework covering US companies certified under it. Otherwise, standard contractual clauses are the usual route. Some European B2B buyers require EU hosting anyway, so keep that in mind when you compare SaaS hosting options.

12. Backups you've actually restored

Article 32 expects you to restore access to personal data in a timely manner after an incident. That means automated, encrypted backups stored separately from production, and a restore you've actually tested. Write down how long a full restore takes, because larger customers often ask.

13. Detect breaches and notify fast

As a processor, you must notify your customer without undue delay (Article 33(2)), because they have to notify their supervisory authority within 72 hours where feasible (Article 33(1)). That takes error tracking, alerts on unusual activity like bulk exports, and a one-page plan for who contacts whom.

14. Test environments without real data

A copy of the production database on a developer's laptop is an easy way to lose control of personal data. Use seeders and factories that generate realistic fake data. If a bug only reproduces with real data, debug it in an environment with production-level access controls and delete the copy afterwards.

What you can skip at the MVP stage

With a few pilot customers, focus on isolation, access, encryption and backups. Export and deletion can start as a documented manual process. But add a tenant ID to every tenant-owned table from the first commit, because that's painful to fix later.

If your team already has these covered, you don't need a developer like me.

Next steps

1. Build the data map from requirement 1. It shows where the gaps are.
2. Mark each requirement as done, partly done or missing.
3. Prioritize isolation, access and backups, and plan export and deletion before you sign your first larger customer.

If you want a SaaS with these requirements designed in from the start, see how I approach SaaS development. You work directly with me and own the code from day one.

Frequently asked questions

Does the GDPR apply to a B2B SaaS?+

Yes. A B2B product almost always holds personal data, such as employee names and emails, business contacts and IP addresses in your logs. Data about a company itself, such as its registration number and address, isn't personal data, but data about the people who work there is.

Do I need to appoint a data protection officer?+

Only in specific cases. Under Article 37, you need a DPO when your core activities involve large-scale, regular and systematic monitoring of individuals, or large-scale processing of special category data such as health information. Most small B2B SaaS companies fall outside this, but check with an advisor if you handle sensitive data.

Do I need ISO 27001 or SOC 2 to sell to larger companies?+

The GDPR doesn't require any certification, but some enterprise buyers and public tenders ask for ISO 27001, a SOC 2 report or a security questionnaire. For a new SaaS, certification rarely pays off. Start with your data map, subprocessor list, a summary of your security measures and your breach plan.

Does a SaaS app need a cookie banner?+

Only if you use cookies or similar technologies that aren't strictly necessary. A session cookie for login doesn't need consent. Analytics, session replay and marketing pixels generally do, even behind a login. Choose cookieless analytics, or ask for consent before those tools load.