GDPR Compliance Checklist for Indie Hackers
Most indie hackers building SaaS products don't ignore GDPR because they don't care — they ignore it because it looks like a legal problem that belongs to companies with legal departments. In practice, the actual technical requirements for a small product with EU users are a short, concrete list. You don't need a lawyer to get through most of it. You need to know what the list actually is.
This isn't a substitute for legal advice if you're handling sensitive data or scaling fast — but for a typical solo SaaS with EU signups, the following covers the parts that matter most and get checked first.
1. Know If GDPR Applies to You
GDPR applies if you process personal data of anyone located in the EU, regardless of where your company is based. If your landing page has an EU visitor who signs up, GDPR applies to that relationship — company size and revenue are irrelevant to whether the law applies, though they do affect enforcement risk in practice.
If you have zero EU users and no plans to, you can deprioritize this. If you have any EU signups today, this list applies to you now.
2. Have a Real Privacy Policy (Not a Template You Never Read)
A privacy policy needs to actually describe what you do: what data you collect, why, how long you keep it, and who you share it with (analytics providers, payment processors, email tools — all of it). Copy-pasting a generic template and never updating it as your stack changes is a common gap — if you add a new analytics tool six months from now and never touch the policy, the policy is now inaccurate, which is its own problem.
Checklist item: Review your privacy policy every time you add a new third-party tool that touches user data.
3. Separate Consent by Purpose
This is the single most common mistake. One "Accept" button covering cookies, analytics, and marketing emails as a bundle is not valid consent under GDPR — each purpose needs its own explicit, unbundled choice. A user should be able to accept analytics tracking and decline marketing emails independently.
Checklist item: Audit your signup and cookie flows — is there one consent action doing the work of three?
4. Make Consent an Affirmative Action, Never a Default
Pre-checked boxes, consent implied by scrolling, or consent implied by continued use of the site don't meet the legal standard. This was tested directly in the CJEU's Planet49 ruling on pre-ticked cookie boxes — and it lost. Consent has to be an active, unambiguous action the user takes.
Checklist item: Check every checkbox and toggle in your signup flow — is anything pre-selected that shouldn't be?
5. Log Consent, Don't Just Collect It
Having a consent flow in your UI is not the same as being able to prove, months later, that a specific user consented to a specific thing at a specific time. GDPR puts the burden of proof on you as the controller — "we have a banner" isn't an answer to "show me this user's consent record."
At minimum, log: who, what purpose, when, which policy version was live, and some record of what was actually presented to them.
Checklist item: If someone asked you right now to produce one user's full consent history, could you, in under five minutes?
6. Build a Path for Data Subject Requests
Users have rights under GDPR to access, correct, delete, or export their data. You don't need automated self-service tooling on day one, but you do need a documented internal process — even a manual one — for handling these requests within the required timeframe (one month, generally).
Checklist item: Write down, even informally, what you'd actually do if a user emailed asking to delete their account and all associated data.
7. Know Your Sub-Processors
Every third-party tool that touches user data on your behalf — your email provider, analytics tool, payment processor, hosting provider — is a sub-processor under GDPR. You're expected to know who they are and, generally, to have Data Processing Agreements (DPAs) in place with them. Most major SaaS tools (Stripe, Mailchimp, common analytics providers) offer standard DPAs you can accept, often in their settings or legal pages.
Checklist item: List every third-party tool in your stack that touches user data. Do you have a DPA with each?
8. Set a Data Retention Policy — Even a Simple One
"Keep everything forever" is not a retention policy, and indefinite retention of personal data without justification is itself a compliance gap. You don't need a complex system; you need a decision. "We delete inactive free-trial accounts after 12 months" is a valid policy. No policy at all is not.
Checklist item: Decide, in writing, how long you keep user data after an account is deleted or goes inactive.
What This Checklist Deliberately Leaves Out
This isn't a complete legal compliance program — it doesn't cover things like appointing a Data Protection Officer (only required past certain thresholds), formal Data Protection Impact Assessments, or cross-border transfer mechanisms, which matter more as you scale or if you're handling sensitive categories of data. For a typical solo SaaS in its early stages, the eight items above are the ones that actually get checked first, by users, by potential enterprise customers doing due diligence, and by regulators.
Where Founders Usually Get Stuck
Of everything on this list, item 5 — logging consent properly — is the one most indie hackers skip entirely, because it's invisible until someone asks for it. A privacy policy is visible. A consent banner is visible. A consent audit trail sitting quietly in your database, ready to answer "prove it," is not something you notice you're missing until the moment you actually need it.
If you're building this yourself, a simple append-only log — purpose, timestamp, policy version, and some snapshot of what was shown — covers most of what you need. If you'd rather not maintain that piece as your product grows, ConsentKeep was built specifically to handle it: consent logging with screenshot proof, IP hashing, and instant export, so item 5 on this checklist is already done.