GDPR Consent Audit Trail for Solo SaaS Founders
If you're running a SaaS product solo, GDPR probably wasn't on your mind when you were shipping features and chasing your first paying customers. Then one day you get a data subject access request, or a customer's legal team asks for "proof of consent," and you realize your cookie banner and a checkbox in your signup form were never actually an audit trail — they were just UI.
This is one of the most common gaps for indie founders and small SaaS teams. You're not being negligent; you simply never had a reason to think about what "proof" means until someone asked for it. The good news is that building a real audit trail doesn't require a legal team or an enterprise compliance platform. It requires a handful of deliberate decisions, made early, before you have thousands of users to retroactively fix.
Why "We Have a Cookie Banner" Isn't an Answer
A cookie banner demonstrates that you asked. It says nothing about who answered, what they answered, or when. Under GDPR Article 7, the accountability burden is on you as the controller to demonstrate consent — not assume it, not infer it from the fact that a banner was rendered.
An auditor or a user exercising their rights isn't going to accept "the banner was there, so presumably they clicked accept." They're going to ask for a specific record tied to a specific person, a specific point in time, and a specific version of what they agreed to.
If you can't produce that record in minutes, that gap itself becomes the finding — regardless of whether your actual data practices were fine.
What a Defensible Audit Trail Actually Contains
Strip away the legal language, and a solid consent audit trail comes down to five things, logged every single time consent is captured or changed:
- Identity — who consented (a user ID or hashed identifier, not more personal data than you need)
- Scope — what exactly they consented to (analytics, marketing emails, third-party sharing — these are separate consents, not one blanket "accept")
- Timestamp — precisely when, down to the second
- Version — which version of your privacy policy or consent copy was in effect at that moment
- Evidence — some record of what was actually shown to the user, since your banner copy will change over time and "v2" alone doesn't tell you what v2 said
Most solo founders have maybe two of these. Usually identity and a boolean "consented: true/false." That's not nothing, but it's not defensible either — it can't answer "consented to what, exactly, and based on what wording?"
The Audit Trail Mistakes That Are Easy to Make Solo
Treating consent as one flag instead of several. A single consented boolean in your users table conflates analytics tracking, marketing emails, and data sharing into one decision the user never actually made as a single choice. When a data subject request comes in asking specifically about marketing consent, a single flag can't answer it.
Overwriting instead of appending. If a user updates their consent — say, they opt out of marketing after initially opting in — and you simply update the row, you've destroyed the history. An audit trail needs to show the full sequence of consent states over time, not just the current one. Every change is its own event, timestamped and immutable.
No record of what the banner actually said. Six months from now, if you've updated your privacy policy copy or changed which vendors process analytics data, "policy_version: v2" only helps if you can reconstruct what v2 actually presented to the user. A lot of founders skip this because it feels like overkill early on — until it's the exact thing an auditor asks for.
Storing raw IP addresses "just in case." It feels safer to keep more data for proof purposes, but storing raw IPs against consent records creates its own processing obligation under GDPR. Hash them instead — you retain the ability to detect anomalies without holding a reversible personal identifier.
No fast export path. When someone asks for their consent history, you want a query that returns a clean, complete record in minutes. If producing that requires writing custom SQL under pressure while a legal deadline is ticking, that's a sign the audit trail was never really designed — it just accumulated.
What "Good Enough" Actually Looks Like for a Solo Founder
You don't need enterprise consent management infrastructure to be defensible. You need:
- Consent logged as separate events per purpose, not one combined flag
- Every consent action appended, never overwritten — grants and withdrawals are both events
- A timestamp and policy version attached to every record
- Some form of evidence of what was shown at that moment — even a stored snapshot of the banner text is enough
- A way to export a user's full consent history on demand, without custom engineering work each time
This is a genuinely achievable checklist for a one-person team. The failure mode isn't complexity — it's simply never sitting down to build it deliberately, because there was always something more urgent shipping that week.
Building This Yourself vs. Not
If you have the bandwidth, all of the above is buildable with a database table, a logging endpoint, and some discipline about append-only writes. It's a weekend project, not a quarter-long compliance initiative.
Where it tends to get harder is maintaining it — remembering to snapshot every banner update, keeping the export path working as your schema evolves, making sure every new feature that touches user data actually logs its own consent purpose instead of reusing an old flag. That maintenance tax is usually what eventually pushes founders toward a dedicated tool.
If you'd rather have this handled without owning the upkeep, ConsentKeep was built specifically for this — solo-founder-sized consent logging with screenshot proof, IP hashing, and one-click export, so the audit trail is already sitting there the day someone actually asks for it.