A data subject request gets harder when the person's data sits in more places than the process expects. The work is not complicated, but it is easy to drop: one request touches intake, identity, search, drafting, and sign-off, and those steps can live with different people.
Why data subject requests get messy
A request gets messy when intake, identity checks, data location, and the response record live in different places and nobody owns the thread between them.
The requester asks one question and then waits. Internally, the work splits across a support inbox, an engineering export, a legal review, and a manager's approval.
If you have traced one person's records across several systems, you know the shape of it. A support ticket, a marketing list, a billing export, a shared drive, a chat archive, and a log table, each held by a different team, each with its own idea of what a customer record includes. Nobody set out to make this hard. The systems were built to serve a process, not to answer a question about one individual.
That gap is what turns a routine request into a fire drill. The fix is not more effort at the end. It is a process that starts building the answer the moment the request arrives. The documentation habits behind a solid data lifecycle record point the same way.
Step 1: Capture the request in one intake record
Give each request a single home: the date it arrived, who asked, what they want, and which systems might hold their data. From that record, anyone can see the state of the case without chasing email threads.
Requests arrive by email, through a web form, over the phone, or in a message to an account manager. When each channel keeps its own list, the same request gets logged twice or missed altogether. One intake record ends that, and it gives you a clean start date for tracking.
Keep the intake record short. Name the requester and a contact route, the date received, the type of request, the systems worth searching, and the owner. Everything else is detail that belongs in the case notes, not in the intake.
A written intake form also settles a quieter question: who is allowed to decide that something is not a request at all. When the answer depends on whoever reads the message first, a genuine request can be answered informally and left without a record, which is the hardest kind of gap to find later.
Step 2: Verify identity before touching the data
Confirm the requester identity before you pull records, using details you already hold rather than prompts a stranger could answer.
The risk runs both ways here. Release records to the wrong person and you have created an incident. Refuse a genuine request and you have failed the person you are meant to serve, and handed them a reason to escalate.
Match the strength of the check to the sensitivity of the data. For an account holder with a live login, one further detail that only they would know is a reasonable starting point. For an email list or a support archive with no account behind it, ask for something you can verify against your own records. Write down what you checked and when, because that note is what turns an identity decision into evidence.
Ask for no more identity detail than the check requires. Collecting extra documents to feel safe creates a new store of personal data that you then have to protect, and it slows the case while you wait for paper that adds nothing.
Step 3: Locate the person's data across systems
Locating the data is the hardest step, because a person's records sit in systems built to serve a process, not to answer a question about one individual.
Work from a map. A data catalog or working inventory that lists systems, owners, and the identifiers each one uses turns a hunt into a checklist. Where a formal inventory does not exist, build a working one from the systems your team already touches, then imshow it after each request.
Start with the identifiers. An email address, an account number, a phone number, and an employee ID each unlock a different set of systems, and the same person may appear under several of them. Sensitive data discovery helps surface copies you did not know about, in exports, archives, and shared folders. Discovery finds candidates. Someone still has to confirm the match.
| System type | What to search | Who to ask |
|---|---|---|
| CRM or support desk | Contact record, tickets, notes, attachments | Support operations |
| Billing or payments | Invoices, transactions, billing contacts | Finance systems owner |
| Marketing or email | Subscriber lists, consent records, campaign logs | Marketing operations |
| Product or analytics | Account identifiers, event history, device records | Data or platform team |
| Files and chat | Shared drives, chat archives, meeting notes | IT and the owning team |
| Logs and archives | Access logs, retention copies | Infrastructure team |
The table is a starting point. Ask the owner of each system to confirm whether the person appears there, and record a "searched, nothing found" result as carefully as a hit, because the absence of data is part of the answer.
Step 4: Assemble the response and the record
The response is the answer you send; the record is the evidence of what you sent, on what basis, and what you withheld and why. Both grow from the same case file as the work happens.
Write the reply so a person can act on it. If you are providing a copy of their data, say what the format is and where redactions were made, with the reason for each one. If part of the request is refused, name that part and the ground you relied on, and keep the reasoning with the case.
The record is what carries the decision forward. A reviewer may read it months later, after the people involved have moved on, and the audit trail practices that apply to other compliance work apply here too. A complete case file answers the follow-up questions before they are asked.
What a defensible response record holds
A response record should let a reader reconstruct the case without asking you a single question. The record is not a summary written at the end; it accumulates as the request moves.
| Field | Why it belongs in the record |
|---|---|
| Date received and channel | Sets the start of the response clock and shows how the request reached you |
| Identity check and result | Shows the basis on which you released or withheld data |
| Systems searched | Shows the search covered more than one place, or explains why one was sufficient |
| Data found, and where | Links the response to its source |
| Redactions and grounds | Explains anything withheld, at the time it was withheld |
| Response sent and format | Closes the loop with a dated, verifiable artifact |
| Owner and reviewer | Names who decided and who signed off |
Where the process breaks down
Requests go wrong for repeatable reasons: an intake that misses a channel, an identity check that is too weak or too heavy, a search that stops early, and a record that lives only in an inbox.
A channel nobody watches is the first problem. If requests can arrive in a chat thread or a sales inbox, someone has to sweep those places and log what they find, or the clock starts late and the case is already behind.
Inconsistent identity checks are the second. The same team may interrogate one requester and wave another through, because the check depends on who picks up the ticket. A written rule about what counts as enough keeps the decision even, and gives the next person a standard to follow.
A search that stops at the obvious system is the third. The customer record is easy. The warehouse copy, the analytics export, and the marketing list are where the gaps hide. Data classification practices help here, because knowing how data is grouped and handled tells you where copies collect and how long they linger.
A record split across inboxes is the fourth. When the case notes live with four different people, nobody can reconstruct the decision, and the work of proving the response starts again from scratch.
What changes when you track requests as a running process
Tracked as a running process, requests can become easier with each cycle: the inventory gets better, the wording settles, and the response stops being an improvisation.
The first request for a person is expensive because you are also building the map. The second one benefits from what the first taught you: which systems held data, which owners replied, which searches returned nothing. That knowledge is worth keeping in a form the next person can reuse.
A quarterly look at the requests you handled is enough to spot the pattern. Which systems take the longest? Which owners do not reply? Which request types recur? Those answers point to the searches worth automating and the records worth tidying.
This is compliance work with a visible shape. It covers a operational obligation, it produces a record, and it can be improved in small steps without a reorganisation. Treating it as ongoing operations rather than an occasional emergency is the whole difference.
FAQ
How quickly should we respond to a data subject request?
Set an internal target that leaves room for an identity check and a real search, then track how sometimes you hit it. The useful measure is the gap between the date received and the date you acted, not the date someone noticed the request.
What counts as a valid request?
A request does not need particular wording or a form. If someone asks what you hold about them, or asks you to correct or delete it, treat that as a request and log it. Then work out what you can do with the identity evidence in hand.
Do we have to search archives and backups?
Archives and backups may not be a live source for answering a request, provided you can show that nobody looks people up from them. The decision is worth writing down once and applying consistently. Either way, record which systems you searched and which you did not.
Who owns a request that spans several systems?
One named owner per request, with a named contact in each system. The owner does not run every search alone; they keep the thread, chase the handoffs, and hold the case file together.
How do we handle a request that touches several systems?
Treat that as the normal case. Work from the inventory, and record every system that returned data alongside every system that returned none. Breadth is a sign the inventory is doing its job, not a failure of the process.
Running data subject requests with CASK
CASK keeps the intake record, the systems searched, and the response you sent together in one workspace, so the next case starts from a worked example rather than a blank page. The point is continuity: the person who answers the next request can see how the last one was handled.
What CASK does not do is decide who a requester is, choose a ground for refusal, or approve a disclosure. That judgment stays with your team and your reviewers. CASK by Truvara is built for the part that follows, keeping the work grounded in the records you already hold.