Most GDPR panic on a ten-field waitlist is theater. You are not building a hospital records system; you are collecting emails with consent. What matters is provable consent, honest purpose, and a way to delete someone when they ask — not a forty-page policy before your first signup.
This is not legal advice. If you process health data, children, or enterprise DPIAs, talk to a lawyer in your jurisdiction. For the typical indie SaaS waitlist aimed at EU visitors, five operational checks cover most of the risk founders actually trip over.
Check 1 — Name the role
You are almost certainly the controller for your waitlist: you decide why the email exists and what you send. Your waitlist vendor is the processor: they store and send on your instructions.
Before you collect:
- Privacy policy link on the signup surface (hosted page or embed)
- Vendor listed as processor (or sub-processor) in your policy or DPA
- Know where data lives (EU hosting matters if you sell "EU-first" — match the claim)
If your policy still says "we do not collect personal data" while you run Mailchimp, fix that mismatch first. Regulators read the live page, not your intentions.
Check 2 — Consent you can replay
A pre-ticked marketing box is not consent under GDPR. Neither is "by signing up you agree to everything."
Minimum viable pattern for a product waitlist:
- Unchecked box or clear sentence: "Email me when access opens"
- Link to privacy policy next to the submit button
- Audit trail: IP, timestamp, wording shown, confirmed opt-in if you use double opt-in
When someone emails "I never signed up," you need a row to show them, not a shrug. Tools that ship consent logs out of the box save you a spreadsheet archaeology project later.
Check 3 — Purpose-bound copy
One waitlist, one primary purpose: early access / launch notification. Do not bolt "and weekly partner offers" onto the same form unless that is what they agreed to.
Footer on launch emails: who you are (legal name + address), why they are receiving this, one-click unsubscribe or delete path. If you run a separate newsletter list, separate purpose text — see waitlist vs newsletter.
Check 4 — Retention with a default
"Indefinite" is a policy choice you will regret. Pick a retention window — twelve to twenty-four months after last interaction is common for launch lists — and automate purge or anonymize.
Document it in your privacy policy. Run the purge. "We might delete someday" is not the same as deleted rows.
Check 5 — Data subject requests without heroics
Someone will ask: export my data, delete me, correct my email. You need a playbook, not a panic thread.
Owner-side workflow:
- Search by email (normalized —
user+tag@gmail.comanduser@gmail.commay be the same person) - Export JSON/CSV if they want portability
- Delete subscriber + consent rows + queue position
- Confirm by email you completed it (keep a minimal log that you fulfilled the request, without keeping their marketing data)
If your vendor offers a privacy workspace for owners, use it. If you DIY, script deletion across DB + ESP so ghosts do not receive launch mail.
Double opt-in — when it helps compliance posture
Double opt-in is not required by GDPR for every list. It is strong evidence the inbox owner agreed. Tradeoff: you lose signups who never click confirm. For EU-heavy traffic and future paid email, many founders enable it on the product waitlist only. Deeper tradeoff math: double opt-in worth it.
Before you flip the embed live
- [ ] Privacy policy matches what you collect
- [ ] Processor/DPA or terms acknowledged
- [ ] Consent wording matches what you will send
- [ ] Retention period set and documented
- [ ] You tested export + delete on a fake address
GDPR on a waitlist is mostly discipline: say what you do, log what they agreed to, delete when the relationship ends. The founders who get burned are not missing a magic clause — they are missing the delete button when a user asks.