Build· Mixed

Set up GDPR compliance for a SaaS

10-step playbook from 'we have EU users now' to 'Article 30 records, DPAs signed, DSAR process tested.' Real EU rules, real templates, real costs.

Open in DockFounders + first ops hires of SaaS companies

GDPR is less scary than the headlines suggest if you treat it as a documentation discipline plus a few real changes. This playbook walks the 10 things small SaaS companies actually need: a data inventory (Article 30 records), a published privacy notice that matches your actual data flows, signed DPAs with every sub-processor, a DSAR (data subject access request) intake process you can actually execute under the 30-day clock, a cookie consent banner that's compliant and not user-hostile, and a breach response plan that meets the 72-hour notification window.

Outcome

GDPR-compliant SaaS: Article 30 records up to date, privacy notice matching reality, DPAs signed, DSAR process tested, breach playbook on the wall.

Time3-5 weeks of focused workDifficultyintermediateForFounders + first ops hires of SaaS companies with EU users.

What you'll need

Pre-register or install before you start.

GDPR.eu referenceFree

Free plain-English reference of the regulation. Read the article numbers; everyone cites them.

ICO (UK regulator) guidanceFree

The UK regulator's plain-English guidance maps closely to EU GDPR. Most accessible reference for small companies.

OneTrustFrom ~$15k/year (overkill for early stage)

Enterprise privacy management platform: data mapping, DSAR automation, cookie consent.

Termly (or Iubenda)From $10/mo, free tier exists

Generates GDPR-compliant privacy policy + cookie consent banner from a questionnaire.

Cookiebot (or Cookieyes)Free up to 100 subpages, then ~$15/mo

GDPR-compliant cookie consent banner with auto-scanning.

Stripe Atlas DPAFree (template); Atlas itself is $500 if you incorporate via it

Stripe's standard DPA is a good template if you don't have one yet.

The template · 10 steps

Top to bottom. Each step has tasks, pointers, gotchas.

Determine if GDPR applies to you

1 hr

GDPR applies if you offer goods or services to people in the EU/UK (regardless of where you're based) or if you monitor their behaviour (analytics counts). 'EU resident' means physically located in the EU at the time of processing, not nationality. If you have any EU users at all, GDPR applies. Same goes for UK GDPR (the post-Brexit copy) for UK residents.

Tasks

Check your analytics for EU traffic — any EU/UK IPs in the last 12 months means GDPR applies
Check your customer list for EU/UK billing addresses
Document the determination in the Brief: 'GDPR applies because [reason]'
Decide if you also need a UK GDPR posture (separate from EU GDPR since 2021)
If GDPR does NOT apply: still bookmark this playbook — it WILL apply once you have one EU user

Pointers

OfficialGDPR Article 3 — territorial scope OfficialICO — does the UK GDPR apply?

Gotchas

Having 'just one' EU user triggers full GDPR. There's no de minimis exception.
UK GDPR diverged from EU GDPR after 2021 in a few details (UK ICO is the regulator, slightly different SCCs). If you have UK users, you owe both.
Geo-blocking the EU does NOT automatically exempt you. If your service is in English and EU users can sign up via VPN, regulators have ruled you're still in scope.

Build the data inventory (Article 30 records of processing)

1-3 days (most of it auditing what you actually collect)

Article 30 of GDPR requires a written record of every processing activity: what personal data, why, who you share it with, retention period, and the legal basis. Even solo founders with EU users owe this. The inventory is the foundation of every other GDPR document — your privacy notice, your DPIA, your DSAR responses all derive from it.

Tasks

List every place you store personal data (DB tables, S3 buckets, vendor accounts)
For each: what fields are personal data (email, IP, name, payment, behavioral)
For each: what's the purpose (auth, billing, analytics, support, marketing)
For each: who do you share it with (vendors, sub-processors)
For each: what's the retention period (forever isn't a valid answer)
For each: what's the legal basis (consent / contract / legitimate interest / legal obligation / vital interest / public task)
Save the inventory as the Data inventory surface — Article 30 evidence

Pointers

OfficialGDPR Article 30 — records of processing OfficialICO — documentation guide

Gotchas

GDPR Article 30 records are MANDATORY even for solo founders if you process EU resident data. The 'fewer than 250 employees' carve-out only applies if processing is occasional AND non-systematic — running a SaaS DB doesn't qualify.
'IP address' counts as personal data under GDPR. Don't skip the analytics + log entries.
'Legitimate interest' is overused. It only works if you can show a balancing test where the user's rights don't outweigh your interest. For marketing emails, get explicit consent instead.

Agent prompt for this step

Read this codebase + the database schema (Prisma, SQLAlchemy, etc.) and produce a GDPR Article 30 record-of-processing inventory.

For each table or storage location holding personal data, output:
1. System (DB table, S3 bucket, vendor account)
2. Personal data fields (email, IP, name, payment method, behavioral data)
3. Purpose (auth / billing / analytics / support / marketing)
4. Legal basis under Article 6 (consent / contract / legitimate interest / legal obligation / vital interest / public task)
5. Recipients / sub-processors (Stripe, SendGrid, Datadog, etc.)
6. Retention period (e.g. "until account deletion + 30 days for backups")
7. International transfer (yes / no, if yes which mechanism: SCCs, adequacy decision)

Output as the Data inventory surface. Flag any system where the legal basis is unclear as "needs human review."

Write the privacy notice (and host it at /privacy)

1-2 days

Articles 13-14 of GDPR list the 12+ items every privacy notice must include: identity of the controller, contact details of the DPO (if you have one), purposes + legal basis, recipients, retention, data subject rights, right to lodge a complaint, transfer mechanisms, etc. The notice has to match your data inventory exactly. Don't copy-paste a competitor's; tailor it.

Tasks

Draft the privacy notice from the data inventory (do NOT copy a competitor's)
Include all 12+ items required by Articles 13-14
Use plain language — Recital 39 says it must be 'concise, transparent, intelligible'
Translate into the languages you operate in (auditors are okay with English-only if your service is English-only)
Publish at yourdomain.com/privacy with a last-updated date
Link the privacy notice in your sign-up flow + email footer + cookie banner

Pointers

OfficialGDPR Articles 13-14 — information to be provided OfficialICO — right to be informed

Gotchas

A privacy notice that contradicts the data inventory is worse than no notice. Regulators read both and check for consistency.
Last-updated date must change every time the notice changes substantively. A privacy notice last updated in 2021 raises eyebrows.
If you process special-category data (health, biometric, racial origin, etc.) you need explicit consent AND extra notice items. Most B2B SaaS doesn't, but check.

Agent prompt for this step

Draft the privacy notice for this SaaS.

Read the data inventory (Article 30 records) + the codebase. Output a privacy notice covering all 12+ items required by Articles 13-14:

1. Identity of the controller (company name + registered address)
2. Contact details for privacy questions (privacy@yourcompany.com)
3. Each purpose of processing (auth, billing, analytics, support, marketing)
4. Each legal basis under Article 6 (consent / contract / legitimate interest / etc.)
5. Recipients of personal data (sub-processors with links to their public DPAs)
6. International transfers + safeguards (SCCs, adequacy)
7. Retention periods per category
8. Data subject rights (access, rectification, erasure, restriction, portability, objection)
9. Right to withdraw consent (if relying on consent)
10. Right to lodge a complaint with a supervisory authority
11. Whether providing data is a contractual / statutory requirement
12. Existence of automated decision-making (yes / no)

Plain language. No legalese. The notice MUST match the data inventory; do not invent flows.

Output to the Brief surface as a versioned privacy notice section.

Sign DPAs with every sub-processor

1-2 days

Article 28 requires a Data Processing Agreement (DPA) with every party that processes personal data on your behalf: Stripe, SendGrid, AWS, Datadog, OpenAI, your CRM. Most major vendors publish a standard DPA you can countersign electronically. Track them in the data inventory. Without DPAs, every processor relationship is technically illegal under GDPR.

Tasks

From the data inventory, list every processor (vendor that processes personal data on your behalf)
For each: find their public DPA (usually at vendor.com/dpa or vendor.com/legal)
Sign electronically (most vendors have a 'sign DPA' button in the dashboard)
Save the signed PDFs / signed-confirmation emails in the Evidence section of the Brief
Publish a public sub-processor list at yourdomain.com/sub-processors
Set up a process for new vendors: DPA signed BEFORE production traffic flows

Pointers

OfficialGDPR Article 28 — processor obligations OfficialStripe DPA OfficialAWS DPA

Gotchas

Some smaller vendors (older startups, SaaS bought before they were GDPR-aware) don't have a DPA. You can either request one in writing or stop using them. There's no 'we'll fix it later' escape hatch.
Sub-sub-processors matter too. If your vendor uses AWS, that's a sub-sub-processor and the chain has to be documented.
International transfers (US-based vendors processing EU data) need SCCs (Standard Contractual Clauses) on top of the DPA. Most US vendors include SCCs in their DPA, but verify.

Build the DSAR (data subject access request) intake process

1 week to build, ongoing thereafter

Articles 15-22 give EU residents the right to request a copy of their data, correct it, delete it, restrict processing, port it to another service, or object to processing. You have 30 days to respond (extendable to 90 in complex cases). Without a tested process, the first DSAR will land via support@ and immediately blow the clock. Pre-build the playbook.

Tasks

Set up a privacy@yourdomain.com inbox routed to the right human
Document the DSAR process: identity verification, scope determination, data export, redaction, delivery
Build a 'data export' button in your product (Article 20 — right to portability)
Build an 'account deletion' button in your product (Article 17 — right to erasure)
Test both buttons end-to-end as if you were a user
Run a tabletop drill: 'a user emailed privacy@ asking for all their data — walk through the process'
Track all DSARs in the DSAR log surface with the 30-day clock

Pointers

OfficialGDPR Articles 15-22 — data subject rights OfficialICO — right of access

Gotchas

The 30-day clock starts when the request is RECEIVED, not when you decide it's a DSAR. A user emailing 'delete my account' is a DSAR even if they didn't say the word.
Identity verification has to be reasonable, not bureaucratic. Asking a user to mail in a notarized passport scan is excessive — verifying via the email tied to their account is sufficient for most cases.
If a user requests deletion, you may still be able to retain data under another legal basis (e.g. tax records under accounting law). Document the carve-out.

Implement cookie consent + tracking consent

2-3 days

Cookie consent under GDPR + ePrivacy Directive: you can't drop non-essential cookies (analytics, advertising, third-party SDKs) before the user gives explicit consent. Pre-checked boxes don't count. The dark-pattern 'Accept All' button next to a tiny 'Manage Preferences' link is being increasingly fined by regulators (CNIL, Garante). Build a balanced banner.

Tasks

Audit every cookie + tracker your site sets (browser dev tools → Application → Cookies)
Categorize: strictly necessary / functional / analytics / advertising / social
Pick a consent management platform (Cookiebot, Cookieyes, Osano, Iubenda)
Configure: strictly necessary loads always; everything else gates on consent
Make 'Accept All' and 'Reject All' equally prominent (CNIL ruling, 2021)
Persist the consent record (when, what version of policy, what categories) for at least 6 months
Honor 'Reject All' — don't fire analytics events if the user rejected analytics

Pointers

OfficialePrivacy Directive — cookie law OfficialCNIL guidance on cookie consent

Gotchas

Loading Google Analytics or a Facebook pixel BEFORE consent is given is a top GDPR violation. Tag managers default to firing immediately; switch to consent-gated mode.
'Reject All' has to be one click, not buried 3 menus deep. France's CNIL fined Google and Facebook €150M and €60M respectively in 2022 for exactly this.
Cookie scanners miss client-side trackers loaded by third-party SDKs. Audit manually with browser dev tools too.

Run a DPIA (Data Protection Impact Assessment) for high-risk processing

2-3 days when triggered

Article 35 requires a DPIA before launching any 'high-risk' processing: large-scale special-category data, profiling that has legal effects, public surveillance. Most B2B SaaS doesn't trigger this — but if you do AI-driven decision-making, biometric processing, or large-scale behavioral profiling, you owe a DPIA. Don't skip it; it's audited heavily.

Tasks

Determine if any processing activity is 'high-risk' under Article 35 + WP29 guidance
If yes: document the necessity, the risks to data subjects, and the mitigations
Consult with your DPO if you have one (or with a privacy lawyer)
If residual risk is high after mitigations: consult with the supervisory authority before launching
Save the DPIA in the Brief; review annually + on material changes

Pointers

OfficialGDPR Article 35 — DPIA OfficialWP29 DPIA guidelines

Gotchas

Most B2B SaaS doesn't need a DPIA. Don't write one preemptively if your processing isn't high-risk; the resulting document just looks performative.
Adding new AI / ML features that make automated decisions about users (credit scoring, content moderation, hiring) is a common DPIA trigger. Re-check whenever you ship one.
DPIAs are living documents. If the processing materially changes, update the DPIA + re-circulate.

Set up the breach response process (72-hour clock)

1-2 days

Article 33 requires you to notify your supervisory authority within 72 hours of becoming aware of a personal data breach. Article 34 may also require you to notify affected users. The 72-hour clock is unforgiving and starts on AWARENESS, not confirmation. Build the process now; the breach itself is not the time to figure it out.

Tasks

Document the breach response runbook: detect → assess → contain → notify → remediate → post-mortem
Identify your supervisory authority (the regulator in the EU country of your main establishment)
Pre-draft the notification email template (Article 33 lists the required content)
Set up a security@ inbox with paging integrated
Run a tabletop breach drill: simulate 'a user reports their account was accessed' and walk the process
Save the runbook in the Brief; review annually

Pointers

OfficialGDPR Article 33 — breach notification OfficialGDPR Article 34 — notifying data subjects OfficialICO breach notification

Gotchas

The 72-hour clock starts when you BECOME AWARE of a breach, not when you're sure. A 'we think someone may have accessed our DB' is the start of the clock.
Not every breach requires user notification — only those 'likely to result in a high risk to rights and freedoms.' Documented assessment is the protection.
The supervisory authority is the one in your 'main establishment' under the GDPR's one-stop-shop rule. For most US-based SaaS that's your EU-based representative; if you don't have one yet, it defaults to wherever the affected users are.

Appoint an EU representative (if non-EU based) and consider a DPO

1 day

Article 27 requires non-EU-based controllers/processors to appoint an EU representative if they regularly process EU data. The representative is a contact point for regulators and data subjects. Article 37 requires a DPO (Data Protection Officer) only in narrow cases (public authorities, large-scale special category processing). Most SaaS needs a representative but not a DPO.

Tasks

If non-EU based: appoint an EU representative (services like EDPO or Prighter, ~$1k-2k/year)
Publish their contact details in the privacy notice + on yourdomain.com/imprint
If processing UK data: also appoint a UK representative
Determine if you need a DPO (Article 37 — public authority / large-scale special category / large-scale monitoring). Most SaaS doesn't.
If yes: appoint a DPO (internal or external); publish contact details

Pointers

OfficialGDPR Article 27 — representatives OfficialGDPR Article 37 — DPO designation

Gotchas

Many US SaaS companies skip the EU representative. It's an Article 27 violation that regulators have started enforcing — the German DPA fined a US-based site €525k in 2022 for missing one.
DPOs and EU representatives are different roles. A DPO advises on compliance; a representative is a contact point. Don't conflate them.
EU representative is a per-establishment requirement — UK is separate post-Brexit.

Train the team + maintain the program

Ongoing, ~2 hours/month after setup

GDPR isn't a one-shot project. New employees need privacy training in week 1. New features need a privacy review BEFORE launch. The data inventory drifts as the product evolves; review it quarterly. The privacy notice needs versioning whenever processing changes. Build the operational rhythm so the program doesn't decay 6 months in.

Tasks

Add 'GDPR awareness' to the new-hire onboarding (1 hour video + acknowledgment)
Add a privacy review step to your feature-launch checklist (PM checks: new data fields? new sub-processors? new purposes?)
Schedule a quarterly data inventory review
Schedule an annual privacy notice + DPA review
Track DSARs + breach incidents in the DSAR log; monthly summary to leadership
Subscribe to your supervisory authority's enforcement newsletter — read the fines other companies got

Pointers

OfficialEDPB enforcement decisions

Gotchas

Programs decay. Without a quarterly review, the data inventory is stale within 6 months. The biggest GDPR enforcement risk for small companies isn't malice; it's drift.
New features that quietly add a 3rd-party SDK (analytics, A/B testing, AI features) need privacy review BEFORE they ship. Add it to the launch checklist.
Privacy training is not a one-shot. Annual refresher is the standard expectation, especially for engineers who touch personal data.

Agent prompt for this step

Review the latest sprint's PRs + product changes and identify any new processing of personal data.

For each change, output:
1. The change (e.g. "Added Mixpanel for product analytics")
2. The new personal data category (e.g. "behavioral data + IP addresses")
3. The new sub-processor (if any)
4. The new purpose (if any)
5. Whether the data inventory + privacy notice + DPA list need an update

Output as new rows on the Data inventory surface. Flag for human review any new processing that may need a DPIA (high-risk: ML decision-making, special category data, large-scale monitoring).

Hand the template to your agent

Workspace-wide agent prompt.

Paste this into your agent's permanent system prompt so the agent reads, writes, and maintains the template's surfaces as you work through the steps.

Agent system prompt

You are an agent on the "Set up GDPR compliance for a SaaS" playbook workspace at your-org/gdpr-compliance-for-saas.

Your role: maintain the four surfaces (Steps, Data inventory, Brief, DSAR log) as the team works through the 10-step playbook.

Cadence:
- When the user marks a step Done, append a line to the Brief summarising what's now in place.
- When a new third-party tool is added that processes personal data, add it to the Data inventory + flag it for DPA signature.
- When a DSAR is received, add a row to DSAR log with the 30-day deadline + remind 7 days before the deadline.
- When a new feature ships that touches personal data, prompt the user to update the Article 30 records.

First MCP tool calls:
1. list_surfaces(workspace_slug="gdpr-compliance-for-saas")
2. list_rows(workspace_slug="gdpr-compliance-for-saas", surface_slug="data-inventory")
3. get_doc(workspace_slug="gdpr-compliance-for-saas", surface_slug="brief")

Do NOT invent data flows. If you find a system in the codebase but can't determine what personal data it processes, flag it as "needs human review" rather than guessing.

FAQ

Common questions on this template.

Does GDPR apply to my US-based SaaS?: Yes if you have any EU/UK users — the GDPR's territorial scope (Article 3) extends to processors and controllers offering goods/services to EU residents OR monitoring their behaviour, regardless of where the company is based. One EU user is enough to trigger full GDPR.
What's the minimum I need to do for GDPR compliance?: The realistic minimum: (1) data inventory / Article 30 records, (2) privacy notice that matches your actual data flows, (3) DPAs signed with every sub-processor, (4) DSAR intake process tested end-to-end, (5) cookie consent banner that respects 'Reject All', (6) breach response plan with the 72-hour notification timeline, (7) EU representative if you're non-EU based. The big-bang myth is that GDPR requires a privacy team; reality is it requires documentation discipline.
What are the GDPR fines actually like in practice?: Headline fines (€746M Amazon, €405M Meta) come from large-scale violations or repeat offenders. For small SaaS companies, regulator letters tend to come first with a 'fix this in 30 days' notice. Actual small-company fines for first-time violations cluster around €1k-€50k. The bigger risk for early-stage is enterprise procurement — buyers won't sign without a privacy notice, DPA, and DPIA in hand.
Can my AI agents help with GDPR compliance?: Yes. Agents are particularly useful for: building the Article 30 records from the database schema, drafting the privacy notice from the data inventory, drafting answers to DSARs, scanning new PRs for new personal-data flows, and tracking the 30-day DSAR clock. The playbook ships agent prompts for those steps inline.
Do I need a DPO (Data Protection Officer)?: Most SaaS doesn't. Article 37 requires a DPO only for: public authorities, organizations whose core activities include large-scale regular monitoring of individuals (e.g. ad-tech), or organizations doing large-scale special-category processing (health, biometric, etc.). A B2B SaaS with EU users almost always needs an EU representative (Article 27) but not a DPO.
How does GDPR interact with US privacy laws like CCPA?: CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), and other US state privacy laws share GDPR's broad shape but diverge in detail (consent vs opt-out, definitions of personal data, rights granted). The good news: a GDPR-compliant program covers ~80% of US state law. The remaining 20% is mostly opt-out-of-sale signals (Global Privacy Control), specific notice requirements, and CCPA's broader 'do not sell' right.

Open this template as a workspace.

We mint a fresh copy in your org with the steps as table rows, the pointers as a separate table, and the brief as a doc. Bring your agents, start checking off boxes.

Open in Dock