If your first enterprise security questionnaire is coming and your GDPR setup is a privacy policy plus a cookie banner, start with one action: list every system that stores a user's email address and check whether you can delete or export it from each. That list is the map every other GDPR task depends on.
GDPR compliance for B2B SaaS is an architecture problem more than a policy one. Each data-subject right needs a code path that runs without a person copying data by hand, and each vendor that touches personal data needs a contract and an entry on a list. This post covers erasure, access and portability requests, residency, and sub-processors, with code where it helps. It isn't legal advice, so have counsel confirm the points that depend on your contracts and your role.
DLA Piper's January 2026 survey reports an average of 443 breach notifications per day across the jurisdictions it covers in 2025, up 22% from 363 the year before, and cumulative fines of EUR 7.1 billion since May 2018. Regulators are busy, and your customers' procurement teams read the same numbers.
What does "GDPR in code" mean for a B2B SaaS?
It means every data-subject right, such as erasure, access and portability, has a dedicated code path that works across all the places personal data lives, not just your main users table.
Take one email address. It sits in your users table, and probably also in your email platform, your support tool, your audit logs, your payment provider, your analytics or warehouse, and your server access logs. A "delete account" button that sets is_deleted = true on one table leaves the other locations untouched. Multi-tenant SaaS adds a layer: tenant isolation keeps customers apart, but each tenant's end-user data still spreads across shared infrastructure.
Start with a data inventory
The foundation is a literal mapping of every data type to every table, integration, backup and log. This is my recommendation rather than a legal rule, but every flow below depends on it: without the map you build erasure against a system you can't fully see. A spreadsheet with four columns (data type, location, purpose, who can delete it) is enough to begin.
Why a surface layer isn't enough
Consider a hypothetical team that ships fast, gains paying customers and then moves upmarket. The first enterprise questionnaire asks for a data processing agreement covering all sub-processors. The team lists the two vendors it remembers, and procurement returns with questions about the analytics, error-tracking and logging tools an engineer added months earlier. Nobody did anything wrong; sub-processor management simply wasn't part of how tools got adopted. The fix is procedural and architectural at once: before a tool that touches personal data reaches production it gets a DPA and a security review, and the data inventory tells you which tools are in scope.
How do you build a right-to-erasure flow?
Use two-phase deletion: hide the user immediately with a soft delete, then hard-delete on a schedule that finishes well inside the legal deadline, and handle every system outside the database separately.
Article 17 gives the data subject the right to erasure "without undue delay" where its grounds apply, and Article 12(3) sets one month from receipt as the outer limit for acting on the request, extendable by two further months for complex or numerous requests if you tell the person within the first month. So a long "grace period" before hard delete is a design choice you must be able to justify. The pattern below uses a short one.
Phase 1, soft delete on request:
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMPTZ;
ALTER TABLE users ADD COLUMN hard_delete_at TIMESTAMPTZ;
UPDATE users
SET deleted_at = NOW(),
hard_delete_at = NOW() + INTERVAL '7 days'
WHERE id = $1;
Once deleted_at is set, add WHERE deleted_at IS NULL to every user-scoped query so the person disappears from the product at once. Phase 2, a scheduled hard delete:
-- Run nightly via pg_cron or an external scheduler
DELETE FROM users WHERE hard_delete_at < NOW();
Foreign keys with ON DELETE CASCADE propagate the deletion to related tables. Audit those relationships before building the job, because orphaned rows in appointments, invoices or consent records are both a compliance gap and an integrity bug.
What the database pattern doesn't cover
- Email and analytics platforms: call their contact-deletion or data-deletion endpoints as part of the same job.
- Payment provider records: Stripe's delete-customer API permanently deletes the customer object, cancels active subscriptions and removes card details, while deleted customers can still be retrieved to track history. Check your accounting retention duties first; Article 17(3) lists legal obligations and legal claims among the exceptions to erasure, and which records that covers is a question for your accountant or counsel.
- Backups: Article 17 doesn't mention backups, so document your backup retention window and how deleted data ages out, and tell customers what it is.
- Your role: when you act as a processor for business customers, erasure requests usually arrive through the customer, and your product needs an endpoint or admin action that executes them on instruction.
Log every erasure: timestamp, subject identifier and the hard_delete_at date. That log is your evidence when an auditor asks whether a specific person's data was removed. For the audit-trail schema itself, see audit logs for B2B SaaS.
How do you handle access and portability requests at scale?
Automate the export for the stores that hold most of the data, and treat the one-month response limit as a hard deadline. Manual email handling works for a handful of requests and breaks when volume grows.
Article 12(3) applies the one-month limit, with the two-month extension described above, to requests under Articles 15 to 22. For portability, Article 20 requires data the person provided to be delivered in a "structured, commonly used and machine-readable format", and it applies where processing is based on consent or contract and carried out by automated means. A SAR is broader than portability, so design the export for access first.
A workable growth-stage flow has five steps:
- An intake form creates a ticket and records the date received.
- A backend job queries the application database for everything tied to the user ID.
- Connectors pull analytics events and support history.
- Sub-processors that hold their own copy are asked for an export.
- A person reviews the assembled JSON, then delivers it securely.
Design the export schema before your first request: a flat JSON with profile, activity and preferences is far easier to build calmly than under a countdown. Full automation is overkill at ten requests a month; manual handling is a liability at several hundred.
What do data residency and sub-processors require?
GDPR doesn't require EU-only hosting, but it does require safeguards when personal data leaves the EU and a contract chain covering every sub-processor. Residency is therefore mostly documentation plus vendor configuration.
Article 46 allows a transfer to a third country only if the controller or processor has provided appropriate safeguards, and lists standard data protection clauses adopted by the Commission among them. Enterprise buyers often ask where data lives and which legal entities can access it, so make your answers match your real setup.
| Requirement | What to implement |
|---|---|
| Database region | Choose an EU region at your cloud provider and state it in your DPA |
| Backups | Keep backups in the same region and document retention |
| Sub-processor options | Confirm that email, logging and analytics vendors offer EU processing, and select it |
| Transfers outside the EU | Put safeguards such as standard contractual clauses in place and record them |
| Processor records | Keep records of processing activities where Article 30 applies to you |
On Article 30, processors must keep records of processing carried out for each controller, and the exemption for organisations under 250 people doesn't apply where processing is regular or includes special categories of data, which suggests a small SaaS shouldn't assume it is exempt.
Keep a living sub-processor list
Article 28(2) says a processor needs the controller's prior specific or general written authorisation to engage another processor, and under a general authorisation it must inform the controller of intended changes so they can object. Article 28(4) requires the same data-protection obligations to flow down to each sub-processor by contract. The practical pattern is a public page listing each sub-processor's name, country, purpose and data categories, with a changelog and optional change alerts for customers.
Breach handling is part of the same chain. Article 33 requires a processor to inform the controller without undue delay after becoming aware of a breach, which is why your secrets and logging hygiene, covered in secrets management for SaaS, belongs next to your GDPR work. The broader compliance picture, including SOC 2, is in SaaS security and compliance, and the isolation model underneath all of it is in multi-tenant SaaS architecture. For the tool side, see multi-tenant SaaS tools.
Callidus, a clinic SaaS I built, lists GDPR handling among its scope in its case study; clinic data is a reminder that every store, including payments, needs its own deletion path. For a two-sided product, see how BookBed is scoped.
Which data store in your product has no deletion path today? Pick that one, write the endpoint this week, and add it to your data inventory with the date it shipped.