Claude, Dsar Response.
A walkthrough of why a data subject access request needs a search across every system and identifier a person has used, then redaction before anything is sent.
When someone asks a company what personal data it holds on them, the easy move is to check the one system where they're an obvious record, like the customer database. That's not enough. This video walks through why a proper response means searching broadly under every identifier a person has used, then narrowing what actually ships.
Why one system misses the rest
A person's data trail rarely lives in a single place. It scatters across support tickets, mailing lists, and old accounts that a single database was never built to see. Checking only the obvious system makes the file look complete when it isn't, because nothing in that one system points to the records sitting elsewhere under a different name or a closed email address.
The anchor: one person, three identifiers
The video follows one requester through the search to make this concrete. The customer database lists them under their current email. Support tickets mention them by name only, with no email attached at all. The mailing list still holds their account under an email they closed two years ago. Search under only the current email, and the mailing list record never turns up, it's filed under an address that no longer exists anywhere else in the system.
A blank result does not mean the person isn't there
A system returning nothing under one identifier hasn't ruled the person out, it's only ruled out that identifier. The complete file needs all three: matched by name, both emails, and the ticket history. Treating a single search as sufficient is how a legitimate DSAR response ends up incomplete without anyone realizing it.
What ships is narrower than what turns up
Finding a record doesn't mean it's automatically ready to send. A support ticket that names a coworker alongside the requester has to be cut back to just the requester's information before it goes out. The response isn't complete until every system has been searched under every name and address the person has used, and what goes back is their data and only their data.
Try it yourself
The video's prompt: list every system your organization stores customer or user data in, plus every name, email, and account identifier one specific person has used. Build a search checklist covering every system and identifier, and flag anywhere a shared record, like a support ticket naming someone else too, would need redacting before it goes out. Running this surfaces the same gap the video is built around: a checklist covering every identifier catches records a single-system search would miss, and catches records that need trimming before they ship.
Key takeaways
- A single database search misses data scattered across support tickets, mailing lists, and old accounts.
- The same person can appear under multiple identifiers: current email, name only, or a closed account.
- A blank result under one identifier only rules out that identifier, not the person.
- A found record isn't automatically ready to send if it names someone else, like a coworker in a shared ticket.
- A complete DSAR response requires searching every system under every known identifier, then redacting before shipping.
Who this is for
Anyone responsible for handling data subject access requests under privacy law, and anyone building a repeatable checklist for searching and redacting personal data across scattered internal systems.
Chapters
Full transcript(auto-generated, with timestamps)
What's in our database about them?
[0:00]Someone asks what data a company holds on them and the easy move is to check the one database with their name in it. That's not enough. The real question, which systems under which name?
One system can't see the rest
[0:10]A person asks a company what personal data it holds on them and where that shows up first is whichever system holds the obvious record, the customer database, say. Ask only that one system and the file looks complete. But someone's data rarely lives in just one place. It scatters across support tickets, mailing lists, and old accounts. A single database was never built to see. Responding to that kind of
The anchor — same person, three identifiers
[0:31]Request means searching every system that could hold a record under every name and address the person has used, not just the one you thought of first. Follow one requester through the search. The customer database lists them under their current email. Support tickets mention them by name only, no email at all. The mailing list still has their account under an email they closed two years ago. Search under only the current email and the mailing list record never
Complete file — and what ships
[0:53]Turns up. It's filed under an address that's gone. The complete file needs all three, matched by name, both emails, and the ticket history. A system that returns nothing under one identifier hasn't ruled the person out. It's only ruled out that identifier. And a record that does turn up isn't automatically theirs to send. A support ticket that names a coworker, too, has to be cut back to their information alone before
Carry-out
[1:16]It goes out. The response isn't complete until every system's been searched under every name and address the person has used and what goes back is their data
Your turn
[1:25]And only their data. Your turn. Here's the prompt. Read it with me. List every system your organization stores customer or user data in, plus every name, email, and account identifier one specific person has used. Ask. Build a search checklist covering every system and identifier and flag anywhere a shared record like a support ticket naming someone else, too, would need redacting before it goes out. Liam Infobear. Claude Desar responds,
Outro
[1:49]Liam Infobear.
