Handling Data Subject Requests Without Losing Track
It usually doesn't announce itself as important. An email lands in a general inbox, or gets forwarded from customer support, and it reads something like “please tell me what personal information you have about me” or “please delete my account and everything tied to it.” Whoever opens it first often isn't sure what to do next. Do they forward it to legal? To IT? To whoever set up the privacy notice two years ago? Is there even a deadline on this?
This moment, small as it looks, is one of the clearest tests of whether an organisation's data protection setup is real or just decorative. Anyone can write a privacy notice promising that individuals have the right to access, correct, or delete their personal data. What actually matters is what happens the moment someone exercises that right.
Why this request is harder than it looks
On the surface, a data subject request seems simple. Someone asks, you answer. In practice, it touches almost every part of an organisation at once. The person handling it needs to confirm the requester actually is who they say they are, since handing over or deleting someone's personal data based on an unverified email is its own serious risk. They need to figure out where that person's data actually lives, which is rarely just one database if the organisation uses several systems, vendors, or departments. They need to track a deadline, because most data protection frameworks expect a response within a defined window, not “whenever someone gets around to it.” And they need to be able to show, afterward, exactly what was found, what was done, and when it was closed.
Miss any one piece of that, and the request either takes far longer than it should, gets answered incompletely, or worse, quietly falls through the cracks entirely. And unlike a lot of internal processes, this one usually has a real person on the other end who's watching to see whether their request gets taken seriously.
What actually needs to happen, step by step
Strip the process down and there are really five things that need to happen for a data subject request to be handled properly, in order.
The request needs an owner the moment it arrives. Not “whoever sees it,” a specific person accountable for seeing it through. Without a named owner, a request can sit in a shared inbox for days while everyone assumes someone else is on it.
The requester's identity needs to be verified before anything is disclosed or deleted. This step exists precisely because acting on an unverified request is how organisations end up handing someone's personal data to the wrong person, or deleting the right person's data based on a request from someone impersonating them.
The deadline needs to be visible and tracked from day one, not calculated later once someone remembers the request exists. A deadline nobody's watching isn't really a deadline.
The actual work, finding the data, correcting it, or deleting it, needs supporting evidence attached as it happens. Not reconstructed from memory afterward, but captured at the moment each step is done.
And finally, the request needs a clear point of closure, a record that says this was resolved, on this date, in this way. Without that closing record, there's no way to prove, months later, that the request was ever properly handled at all.
What happens when this lives in an inbox instead of a system
Picture the same request handled without any structure behind it. It arrives, gets forwarded twice, sits for a few days while people figure out who owns it, gets partially actioned by someone who isn't entirely sure they've found all the data, and eventually gets marked done with nothing more than a reply email as proof. If that person emails back a month later disputing whether it was handled correctly, there's very little to point to. If a regulator or an internal audit asks how many requests came in last quarter and how they were resolved, the honest answer is often “we'd have to go check everyone's inbox.”
This is the exact gap a Data Protection Management System is built to close. Instead of a request disappearing into an inbox, it gets logged as its own tracked item the moment it arrives, carrying an assigned owner, a verification step, a running deadline, and a place for evidence to attach as the work happens. When it's resolved, closure is recorded, not implied. Every part of the process that used to depend on someone's memory or diligence now has a visible trail behind it.
Why this matters even when nothing goes wrong
It's worth being honest about something here: most data subject requests, handled well or badly, end the same way. The person gets their answer, the account gets deleted, and nobody outside the organisation ever thinks about it again. The value of doing this properly isn't mainly about the requester noticing the difference.
It's about what happens when someone eventually asks a bigger question. A new customer's procurement team sends a due diligence questionnaire asking how you handle data subject requests and how many you've processed. An internal audit wants to confirm the organisation is meeting its stated response times. A regulator, following up on an unrelated matter, asks to see evidence of how these requests are typically resolved. In every one of those moments, the difference between “we handle this properly” and “we can show you exactly how we handled every one of these, with dates and evidence” is enormous, and it's a difference that only exists if the tracking happened at the time, not after the fact.
This isn't just a legal department's problem
Data subject requests don't arrive neatly labelled and routed to the right team. They show up through customer support, through a general contact form, through HR if it's an employee asking, through a property manager if it's a tenant. Any organisation holding customer, employee, patient, tenant, member, or user data, regardless of size or industry, is exposed to this exact scenario the moment someone decides to exercise their rights. SaaS companies, e-commerce businesses, healthcare providers, rental and subscription services, property managers, and any multi-branch business handling data across several locations all face the identical version of this problem: a request comes in somewhere unexpected, and what happens next depends entirely on whether there's a real process waiting for it or just good intentions.
Building the habit before you need it
The organisations that handle this well aren't the ones who never make mistakes. They're the ones who built the process before the pressure was on, so that when a request does arrive, whoever opens that email already knows exactly where it goes, who owns it, and how it gets tracked to a clean close. That's not a big ask. It's a structured habit, backed by a system that remembers what a busy inbox never will.
If your organisation's current answer to “how do we handle a data subject request” is “someone forwards it to the right person and we figure it out,” that's worth changing before the next one arrives, not after.