A data subject access request, or DSAR, is a person asking what data you hold about them and, often, asking you to do something with it. Under GDPR you generally have thirty days to respond. Under CCPA it is forty-five. The clock starts when the request lands, and missing the deadline is a compliance failure on its own. The good news is that a DSAR is very manageable when you have a process. Here is one.
Day zero: log the request
The moment a request arrives, record it. Do not let it sit in a personal inbox. Capture who asked, what they asked for, the date received, and the deadline.
- Note the request type. Access, correction, deletion, and portability are all different.
- Start the clock from the day you received it, not the day someone noticed it.
- Acknowledge receipt so the person knows you are on it.
A request can arrive anywhere, by email, through a form, even in a support chat. Train your team to forward anything that smells like a rights request to one tracked place.
Days one to three: verify identity
You must not hand personal data to the wrong person. Identity verification protects everyone, including the requester.
- Confirm the request comes from the actual data subject or an authorized agent.
- Ask for reasonable proof, but do not demand more than you need.
- If you cannot verify, document your good-faith attempt and the reason.
Over-collecting identity documents is its own privacy risk. Verify enough to be confident, then stop. You do not need a passport scan to confirm an email address you already have on file.
Days three to fifteen: find the data
This is the work. You need to gather everything you hold about the person across every system. The better your data map, the faster this goes.
- Search your main database, your CRM, your analytics, your email tool, and your backups.
- Include data held by processors acting on your behalf.
- Note anything you can lawfully withhold, such as data that would expose another person.
If you have never mapped your systems, the first DSAR is painful. Use it as the push to build that map so the next one is quick.
Days fifteen to twenty-five: prepare the response
Now you turn raw data into a clear, usable answer.
- Assemble the data in a readable format the person can actually understand.
- For deletion requests, remove the data and confirm what was removed.
- For correction requests, update the record and note the change.
- Redact information about other people that happens to sit alongside theirs.
Be plain in your reply. A wall of database exports is not a good answer. Explain what you hold, why, and what you did.
Days twenty-five to thirty: send and record
Deliver the response securely, then keep proof that you did.
- Send through a channel the person can access safely.
- Record the date you responded and what you provided or did.
- Keep the full trail in case the person or a regulator asks later.
That record is your defense. If anyone questions whether you handled the request properly, the log answers for you.
Make the next one easy
The first DSAR tests your process. After that, the goal is to make each one routine. A tracked intake, set deadlines, a known place to search, a templated response, and an audit trail turn a stressful scramble into a checklist.
If you want DSAR intake, SLA timers, a fulfilment workflow, and an audit trail in one place, get started free with ConsentX and stop dreading the next request.