GDPR for SaaS: what has to stand before your first enterprise customer
For: SaaS providers in the DACH region
Updated: 2026-09
Six areas are unavoidable for a SaaS product: a legal basis per processing activity, a maintained processing register, data subject rights implemented in the system, a deletion concept that actually works, clean sub-processor chains, and a demonstrable statement on data residency.
Data protection usually gets taken seriously too late in SaaS products — typically when the first sizeable customer sends a questionnaire. By then the expensive decisions are long made: data model, hosting region, sub-processors.
This checklist covers what should stand before that moment. It is written for products in the DACH region and accounts for Swiss providers regularly having to serve both the revised Swiss data protection act and the GDPR.
The checklist
- 01
Map processing activities to legal bases
Name each processing activity in the product individually and assign it a legal basis. Particularly relevant for analytics, product telemetry and anything beyond plain contract performance.
Done when: No processing in the product lacks a named legal basis, and consents are technically withdrawable.
- 02
Couple the processing register to development
Maintain the register so that new data fields and new third-party services arrive in it. A register decoupled from development stops reflecting the product after two releases.
Done when: The register was updated at the last release, and the trigger for doing so is part of the development process.
- 03
Implement data subject rights technically
Access, rectification, erasure and portability each need a route through the system. As long as that means hand work in the database, the deadline will not hold when several requests arrive at once.
Done when: Each right has a defined procedure, and an access request has been run end to end once.
- 04
Check deletion across every storage location
Deletion has to reach backups, log files, search indices and analytics tools. The record in the main database is usually the only one anybody thinks of.
Done when: A list of every location holding personal data exists, with a retention period per location.
- 05
Capture sub-processors completely
Every service processing customer data is a sub-processor — including monitoring, error tracking, email delivery and AI interfaces. That list belongs in public view.
Done when: The list is complete, every entry has a contract, and customers can retrieve it without asking.
- 06
Make data residency demonstrable
Know not only where the main database sits but also where backups, logs and support tooling sit. Questionnaires from regulated industries ask exactly this.
Done when: The region can be named for every storage location without checking with the vendor.
- 07
Verify tenant isolation
In multi-tenant systems, separation of customer data is the single most critical point. A failure here is simultaneously a data breach and a loss of trust a product rarely recovers from.
Done when: Separation is enforced at the database layer and covered by a test that runs on every release.
Common mistakes
- —The privacy policy describes a product that no longer exists. It is written at launch and never adjusted to product changes.
- —Deletion reaches the main database but not backups, logs and analytics tools, which makes it incomplete.
- —New third-party services get wired in during development without anyone adding them to the sub-processor list.
- —Tenant separation rests on application logic instead of database enforcement. A single forgotten filter is then enough for an incident.
What this checklist does not cover
- —This checklist does not replace a data protection review of your specific product, particularly where special categories of personal data are involved.
- —Data protection impact assessments are a separate procedure and are not covered here.
- —International transfers are touched only insofar as they bear on data residency. Contractual safeguards for third-country transfers are their own subject.
- —Sector-specific law — healthcare, financial services, public procurement — comes on top.
Parent service: SaaS Product Development
Matching offers
GDPR & revDSG audit for SaaS
A data protection audit for SaaS checks whether data flows, processing agreements, deletion concept, and technical measures are GDPR- and revDSG-compliant. The output is a concrete finding with prioritised fixes — from people who run SaaS themselves.
SaaS security & RLS audit
A SaaS security audit targets tenant isolation specifically: is row-level security watertight, does access control hold, are typical Supabase pitfalls (service role in the client, missing RLS) avoided? The output is a finding with concrete fixes.
FAQ
Is EU hosting enough for GDPR compliance?
No. Server location is one building block, but legal bases, data subject rights, deletion and sub-processor chains have to be met independently of it.
What applies additionally to Swiss providers?
The revised Swiss data protection act applies in parallel. The requirements largely overlap but diverge in detail — for instance on breach notification and on the register.
When should you start on this?
Before fixing the data model and the hosting region. Those two decisions are the most expensive to correct later.
Do we need a data protection officer?
That depends on the nature and scale of processing rather than on company size alone. With large-scale systematic monitoring or special data categories the question needs serious assessment.
More checklists
Reviewing a data processing agreement: what to look for before signing
Six points decide a DPA review: subject matter and instruction binding, the sub-processor chain and your right to object, place of processing, assistance with data subject rights, the breach notification route, and what happens to the data when the contract ends.
Technical due diligence: what can be established in a few days
Technical due diligence under time pressure concentrates on six questions: does the architecture carry the planned growth path, how large is the technical debt, does the system depend on individuals, how do security and licensing stand, and can operations be handed over.
Technical SEO review: the points that actually block indexing
Most technical SEO problems trace back to a handful of causes: pages are not indexable, canonicals point elsewhere, the sitemap lists pages that should not be indexed, hreflang is not reciprocal, or pages carry almost no internal links.