---
title: "Set up GDPR compliance for a SaaS"
excerpt: "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."
category: "Template"
---

# Set up GDPR compliance for a SaaS

    A 10-step playbook. Open in Dock and you'll get four surfaces seeded:

    - **Steps** (table) — the 10 GDPR gates as rows, owner + due + status
    - **Data inventory** (table) — your Article 30 records of processing activities
    - **Brief** (doc) — the canonical write-up plus your privacy notice draft
    - **DSAR log** (table) — every data subject request received, with the 30-day clock tracked

    Read `Steps` top-to-bottom on first open. GDPR Article 30 records are mandatory even for solo founders if you process EU resident data — start there.

## Outcome

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

**Estimated time:** 3-5 weeks of focused work  
**Difficulty:** intermediate  
**For:** Founders + first ops hires of SaaS companies with EU users.

## What you'll need

Pre-register or install before you start.

- **[GDPR.eu reference](https://gdpr.eu/)** _(Free)_ — Free plain-English reference of the regulation. Read the article numbers; everyone cites them.
- **[ICO (UK regulator) guidance](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/)** _(Free)_ — The UK regulator's plain-English guidance maps closely to EU GDPR. Most accessible reference for small companies.
- **[OneTrust](https://www.onetrust.com/)** _(From ~$15k/year (overkill for early stage))_ — Enterprise privacy management platform: data mapping, DSAR automation, cookie consent.
- **[Termly (or Iubenda)](https://termly.io/)** _(From $10/mo, free tier exists)_ — Generates GDPR-compliant privacy policy + cookie consent banner from a questionnaire.
- **[Cookiebot (or Cookieyes)](https://www.cookiebot.com/)** _(Free up to 100 subpages, then ~$15/mo)_ — GDPR-compliant cookie consent banner with auto-scanning.
- **[Stripe Atlas DPA](https://stripe.com/atlas)** _(Free (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

## Step 1: Determine if GDPR applies to you

_Estimated time: 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

- **[Official]** [GDPR Article 3 — territorial scope](https://gdpr.eu/article-3-the-territorial-scope-of-the-gdpr/)
- **[Official]** [ICO — does the UK GDPR apply?](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/about-the-uk-gdpr/who-does-the-uk-gdpr-apply-to/)

> [!CAUTION]
> **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.

## Step 2: Build the data inventory (Article 30 records of processing)

_Estimated time: 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

- **[Official]** [GDPR Article 30 — records of processing](https://gdpr.eu/article-30-records-of-processing-activities/)
- **[Official]** [ICO — documentation guide](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/)

> [!CAUTION]
> **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

```text
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."
```

## Step 3: Write the privacy notice (and host it at /privacy)

_Estimated time: 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

- **[Official]** [GDPR Articles 13-14 — information to be provided](https://gdpr.eu/article-13-personal-data-collected/)
- **[Official]** [ICO — right to be informed](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/the-right-to-be-informed/)

> [!CAUTION]
> **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

```text
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.
```

## Step 4: Sign DPAs with every sub-processor

_Estimated time: 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

- **[Official]** [GDPR Article 28 — processor obligations](https://gdpr.eu/article-28-processor/)
- **[Official]** [Stripe DPA](https://stripe.com/legal/dpa)
- **[Official]** [AWS DPA](https://aws.amazon.com/compliance/gdpr-center/)

> [!CAUTION]
> **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.

## Step 5: Build the DSAR (data subject access request) intake process

_Estimated time: 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

- **[Official]** [GDPR Articles 15-22 — data subject rights](https://gdpr.eu/article-15-right-of-access/)
- **[Official]** [ICO — right of access](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/the-right-of-access/)

> [!CAUTION]
> **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.

## Step 6: Implement cookie consent + tracking consent

_Estimated time: 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

- **[Official]** [ePrivacy Directive — cookie law](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32002L0058)
- **[Official]** [CNIL guidance on cookie consent](https://www.cnil.fr/en/cookies-and-other-trackers)

> [!CAUTION]
> **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.

## Step 7: Run a DPIA (Data Protection Impact Assessment) for high-risk processing

_Estimated time: 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

- **[Official]** [GDPR Article 35 — DPIA](https://gdpr.eu/article-35-impact-assessment/)
- **[Official]** [WP29 DPIA guidelines](https://ec.europa.eu/newsroom/article29/items/611236) — The Article 29 Working Party's guidance on when a DPIA is required.

> [!CAUTION]
> **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.

## Step 8: Set up the breach response process (72-hour clock)

_Estimated time: 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

- **[Official]** [GDPR Article 33 — breach notification](https://gdpr.eu/article-33-notification-of-a-personal-data-breach/)
- **[Official]** [GDPR Article 34 — notifying data subjects](https://gdpr.eu/article-34-communication-of-a-personal-data-breach/)
- **[Official]** [ICO breach notification](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/)

> [!CAUTION]
> **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.

## Step 9: Appoint an EU representative (if non-EU based) and consider a DPO

_Estimated time: 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

- **[Official]** [GDPR Article 27 — representatives](https://gdpr.eu/article-27-representatives-of-controllers-or-processors/)
- **[Official]** [GDPR Article 37 — DPO designation](https://gdpr.eu/article-37-designation-of-the-data-protection-officer/)

> [!CAUTION]
> **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.

## Step 10: Train the team + maintain the program

_Estimated time: 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

- **[Official]** [EDPB enforcement decisions](https://edpb.europa.eu/news/news_en)

> [!CAUTION]
> **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

```text
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

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

```text
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

### 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.