This isn't legal advice — GDPR compliance obligations depend on specifics (where your customers are, what data you handle, how your business is structured) that a real privacy lawyer or compliance professional should weigh in on for anything beyond a straightforward small-scale case. This is an account of what actually happened the first time a formal data access request landed in the inbox of a one-person SaaS with no prior process for handling one, and what got built afterward so the next one wouldn't be another scramble.
The email that started it
The request was polite, specific, and cited GDPR Article 15 directly: a customer wanted a copy of all personal data held about them, and separately wanted to know exactly what third parties that data had been shared with. Nothing about the request was hostile or unusual — it read like someone who simply knew their rights and was exercising them, which is exactly the kind of request GDPR is designed to make routine and unremarkable, even though it didn't feel remotely routine on the receiving end with zero prior process in place.
The first, honest problem: not knowing where all the data actually lived
The immediate difficulty wasn't legal, it was practical: customer data didn't live in one place. The application database held the obvious account information, but a full, honest answer also meant checking the billing provider (payment history and billing address), the email service provider (email engagement history), the analytics tool (usage events tied to the account), and the error-tracking service (any error reports that happened to include user-identifying context in their stack traces). No single document or system had ever listed all the places a given customer's data actually flowed to — which was, in hindsight, precisely the gap the Privacy Policy update covered in writing Terms of Service and a Privacy Policy without a lawyer should have already forced into the open, and hadn't, because nobody had actually been asked to produce the full list until this request forced the issue.
The actual 72 hours
Day one: the application database was queried directly for every record tied to the customer's account, which was straightforward — a single, well-understood system. Day one also involved logging into the billing provider's dashboard to pull payment history, which took longer than expected because the provider's own data-export tooling wasn't built for a single-customer export and required assembling records more manually than anticipated.
Day two: the email service provider and analytics tool each required their own separate lookup, using their own respective interfaces, and the error-tracking service required a manual text search across recent error reports for anything matching the customer's identifying details, since error tracking wasn't set up in a way that let it be filtered by customer in one clean, structured query. Assembling all of it into a single, coherent, human-readable response — not just a raw data dump, since the request specifically asked what had been shared and with whom, which requires actual explanation, not just exported rows — took the better part of the second day.
Day three: reviewing the assembled response for accuracy and completeness before sending it, then actually sending it, comfortably within GDPR's one-month response window but far closer to a full working week of real, direct effort than anyone would want to spend on a single request, especially one that could reasonably recur at any time with no advance warning.
What the checklist built afterward actually contains
The concrete output of this experience wasn't a policy document — it was a literal, actionable checklist, written immediately afterward while the specific gaps were still fresh, listing every single system that holds any customer data at all, in one place, for the first time:
- Application database: exact tables and the query needed to pull every record tied to a given customer ID.
- Billing provider: the specific dashboard section and export method for a single customer's payment history.
- Email service: how to look up a specific customer's send and engagement history.
- Analytics tool: how to filter events down to a single customer's usage history.
- Error tracking: how to search for any error reports that might reference a specific customer's identifying information.
Having this list written down in advance, tested once against a real request, turned what took the better part of three days into something that took under an hour the second time a similar request arrived roughly eight months later — the actual data-gathering work was identical in kind, but no longer required rediscovering, from scratch under time pressure, where everything actually lived.
A second change: reducing what needed to be gathered in the first place
Beyond documenting where data lived, the experience prompted an honest audit of whether all of it needed to be collected and retained at all. The error-tracking service, in particular, was found to be capturing more user-identifying context in stack traces than was actually useful for debugging — full request payloads including email addresses, retained far longer than any debugging use case genuinely required. Scoping that down, both in what got captured going forward and how long it was retained, reduced the surface area any future data request would need to cover, which is a genuinely more durable fix than just getting faster at responding to requests against an ever-growing pile of data that mostly didn't need to exist as long as it did in the first place.
What surprised me most about the actual experience
The request itself, once actually handled, was entirely unremarkable — a reasonable, well-within-rights ask, handled correctly, that resulted in zero further contact or complaint from the customer, who continued using the product afterward without incident. The stress of the first 72 hours came almost entirely from not having a process, not from the request being unusually demanding or hostile in any way. That distinction matters for anyone dreading their own first request: the request itself is rarely the hard part; not having thought about it in advance is.
What I'd tell a solo founder before their first request ever arrives
- Build the "where does customer data actually live" list before you need it, not during a live request with a response deadline already ticking — this single document is what turned three days into one hour the second time around.
- Periodically audit what's actually being collected and retained, not just how to respond to a request about it — reducing the surface area is a more durable fix than getting faster at covering an ever-larger one.
- Treat the first real request as inevitable, not unlikely — for any product with real users, especially any based in or serving the EU/UK, a request like this isn't a hypothetical edge case worth deferring preparation for indefinitely.
If this experience is prompting a closer look at your own Privacy Policy's accuracy about where data actually goes, writing Terms of Service and a Privacy Policy without a lawyer covers getting that document genuinely accurate in the first place, which is most of the groundwork a request like this one draws directly on.
Verifying identity: a step that's easy to skip and shouldn't be
One detail almost overlooked entirely in the rush of the first request: confirming the request genuinely came from the account holder it claimed to be from, before sending any actual personal data anywhere. The request in this case came from the same email address on file for the account, which was a reasonable, low-friction signal of authenticity given the low stakes and small scale involved — but it's worth being deliberate about this rather than assuming every future request will be equally straightforward. Sending a full personal data export to the wrong person because a request wasn't actually verified is a considerably worse outcome than a slightly slower, more careful response, and for any request where the requester's identity isn't already unambiguous — a different email address than the one on file, for instance — a short verification step before proceeding is worth the extra day it costs.
Deciding what counts as "personal data" in an edge case
A genuinely tricky judgment call came up while assembling the response: did internal notes — a private field where the founder had jotted a brief reminder about a specific support interaction with this customer — count as personal data that needed to be included in the export? After some research, the honest answer leaned toward yes: personal data under GDPR is defined broadly, covering essentially any information relating to an identifiable person, which a note referencing a specific customer's specific situation clearly qualifies as, even though it lived in an informal internal field never intended to be customer-facing. The note was included in the final response, and going forward, internal notes about customers are now written with the explicit awareness that they could end up disclosed in a future request — a small but real shift in how that field gets used day to day.
How this changed what gets collected going forward, beyond just error tracking
Beyond the error-tracking scope-down mentioned above, the broader habit that stuck was asking, for any new field or tracked event being added to the product, whether it was something that would be comfortable to hand over in a future data request, worded plainly, to the person it's about. This reframing — from "is this useful to collect" to "is this useful enough to justify being able to explain and hand over later" — quietly raised the bar for what got added without much debate in day-to-day development, in a way that's hard to enforce through a written policy alone but genuinely changed as a habit once the first real request had made the abstract obligation feel concrete rather than theoretical, in a way no amount of reading about GDPR in the abstract had managed to do beforehand.
No comments yet.
Be the first visitor to add a thoughtful comment on this article.