I've written before about whether your app can actually delete someone's data when asked. There's a related, quieter request that comes up just as often and gets built even less consistently: someone asking to see everything you actually have stored about them.
Why this is a genuinely different question than deletion
Deleting a user's data can, in the crudest version, mean removing rows without anyone ever having to fully account for what those rows contained. Answering "what do you have on me" requires the opposite: actually knowing, comprehensively, everywhere a specific person's information lives across your entire system, well enough to compile it into something you can hand back. A lot of apps that could technically delete a user's data would still struggle badly to produce a complete, accurate answer to this simpler-sounding question.
Where this typically falls apart
- Data spread across multiple tables that were added at different points in the app's life, with no single place that lists all of them.
- Information sent to third-party tools, an email service, an analytics platform, a support tool, that technically holds a copy but isn't included in any internal accounting of "what we have."
- Backups and logs that contain the same information as the live database but sit completely outside whatever process handles a request like this.
- Fields added quickly for a specific feature, then forgotten about entirely once that feature shipped, with nobody maintaining a running list of what personal data actually lives where.
A simple test worth running on your own app
Pick a real test account with a reasonable amount of activity in it, and try to answer the question yourself: what does this app actually know about this person, everywhere it's stored? If you can't confidently produce a complete answer without a lot of manual digging and guessing, that's the gap, and it's the same gap a real user would run into if they asked you directly.
Why this is worth fixing before someone asks, not after
Being asked this question with no existing process behind it means building the answer under time pressure, digging through tables and third-party dashboards while someone's actively waiting on a response. Having even a simple, maintained list of where personal data lives, updated whenever a new feature touches it, turns this from a scramble into something you can actually answer quickly and confidently.
What's actually worth doing now, regardless of whether anyone's asked yet
- Keep a running, plain list of every place personal data lives: which tables, which third-party services, which exports or backups.
- Update that list as a normal part of shipping any feature that touches user data, not as a separate audit you do occasionally.
- Actually try producing a real answer for a test account, end to end, before you ever need to do it for a real person under real time pressure.
This isn't only relevant if you operate somewhere with a specific law requiring this kind of response. It's a basic question about whether you actually understand your own app's data footprint, and most builders discover they don't, the first time they genuinely try to answer it.