How to Respond to a Data Subject Access Request With a 10-Step DSAR Checklist

To respond to a data subject access request, you log the request and start the statutory clock, verify the requester's identity, discover every place their personal data lives across your systems, compile it into a reviewable manifest, redact third-party and exempt data, and send a clear response before the deadline. Each step matters, and skipping one, such as verification or redaction, is where teams get into trouble.

This is general information, not legal advice. Below is a practical, repeatable sequence you can follow for any incoming request.

What counts as a DSAR, and what you owe the requester

A DSAR, or data subject access request, is a person asking you for a copy of the personal data you hold about them and how you use it. It can come from a customer, a former customer, an employee, a job applicant or a member of the public, and it does not need formal wording. "Can you send me everything you have on me" in a chat window counts. Under the GDPR and the US state laws modeled on it, a complete response usually covers:

• a copy of the personal data itself, not just a description of it;
• the purposes you process it for and the categories involved, such as contact details, orders or support tickets;
• who it has been shared with, including processors and other third parties;
• how long you keep it, or the criteria you use to decide;
• where it came from, if not from the person directly.

Four beliefs cause most of the trouble. A request does not have to be formal. Access is free in the ordinary case, and a fee is allowed only when a request is manifestly unfounded or excessive. A raw export is rarely a safe answer, because other people's data has to come out first. And the deadline starts on receipt, not when someone gets around to opening the ticket. Requests from staff are their own case, covered in the employee subject access request guide.

Step 1. Log the request and start the clock

The moment a request arrives, log it. A DSAR can come by email, web form, phone, or chat, and it does not have to use formal language to be valid, so train anyone who touches customer messages to recognize and forward one. The deadline generally starts on the date of receipt, so a request that sits unlogged for a week has already lost a week. Centralizing intake through one queue for privacy request management prevents requests from getting lost in a support inbox.

Step 2. Verify the requester's identity

Before you disclose anything, confirm the person is who they say they are. Disclosing personal data to the wrong person is a breach in its own right. Keep verification proportionate to the sensitivity of the data: match the request to known account details, or ask for limited confirming information rather than demanding excessive documentation. Getting this balance right is exactly what identity verification is for. If you cannot verify identity, document your reasonable attempts before declining.

Step 3. Track the deadline from day one

Under the GDPR you have one month; under the CCPA you have 45 days. Both clocks can be extended in limited circumstances, but you should plan to meet the original deadline. Set the due date the day the request lands and work backward, leaving room for review and sign-off at the end. Automated deadline tracking keeps the date visible so it does not creep up. For the extension rules, see the data subject request deadlines by state guide.

Step 4. Discover where the data lives

This is usually the hardest and most time-consuming step. A single person's data can be spread across your CRM, help desk, billing platform, email, marketing tools, product database, spreadsheets, and backups. Searching each system by hand is slow and easy to get wrong, and a missed system means an incomplete response. Automated personal data discovery searches your connected systems for the requester's identifiers and pulls the results into one place, so completeness stops depending on someone remembering every tool.

Step 5. Compile a manifest and decide scope

Once you have found the data, compile it into a single manifest: a structured list of what was found, where, and in what category. Reviewing a manifest is far easier than sifting through raw exports from a dozen tools. This is where you decide what is genuinely in scope for an access request and what falls outside it, and where you flag anything that may be exempt or under legal hold.

Step 6. Redact third-party and exempt data

An access request covers the requester's own personal data, not other people's. If a support ticket mentions another customer, or an internal note names a colleague, that third-party data usually has to be redacted. Some material is also exempt, such as legally privileged content or information covered by another exemption. Redaction should be applied carefully and consistently. Our guide on how to redact a DSAR response covers the categories in detail, and a purpose-built redaction step keeps it auditable.

Step 7. Draft the response and get approval

Draft a clear cover letter and response that tells the requester what data you hold, why you process it, who it is shared with, and how long you keep it. Working from a consistent set of response templates saves time and keeps your language accurate and compliant. A starting point is in the DSAR template guide.

Before anything goes out, a human should review and approve it. Automation can find and draft, but a person should sign off on what is disclosed. A human review gate is what keeps you in control of the final disclosure.

Step 8. Deliver and record

Send the response through a secure channel, and keep a record of what you disclosed, when, and to whom. That record protects you if the requester or a regulator asks questions later.

The DSAR checklist

Here is the whole sequence as a ten-line checklist. Each line has a plain "done when" test, so anyone on the team can tell whether a request is actually ready to move on or only looks ready.

For discovery in particular, a short list keeps the search honest:

• Search every connected system, not just the obvious ones.
• Include backups and archived data where they hold personal data.
• Flag anything that may be exempt or under legal hold as you go.
• Mark items that will need redaction so the next step is faster.

Where the DSAR process usually breaks

The steps above only work if you follow every one. A few get skipped more than others, and each skip has a predictable cost.

• Skipping the timestamp. If nobody records the receipt date, the deadline is a guess, and guesses run late.
• Verifying too slowly. Dragging out identity checks eats into your window; keep them proportionate and prompt.
• Searching only the obvious systems. The one tool nobody remembers is usually the one holding the data you miss.
• Redacting under time pressure. Rushed redaction is where third-party data leaks. Reserve time for it by starting discovery early.
• Auto-sending without sign-off. A response that goes out unreviewed is the fastest route to an accidental disclosure.

Almost every one of these traces back to starting the discovery-heavy steps too late. Protect the front of the process and the back takes care of itself.

A quick self-check before you send

Before the response leaves your systems, ask three questions. Have I found data in every system this person could appear in? Have I removed everything that belongs to someone else? Has a person actually approved this disclosure? If any answer is no, the request is not finished, however close the deadline is. This last pass is the cheapest safeguard you have, and it catches the mistakes that are expensive to fix later.

Leave room for review at the end

The single most useful habit in responding to a DSAR is to plan backward from the deadline and protect the final stretch. Redaction and human approval are the steps most likely to be rushed, and rushing them is exactly where accidental disclosures happen. Reserve the last few days of your window for review, then fit discovery and drafting into the time that remains. If you find yourself starting discovery late, that is the signal to check whether an extension genuinely applies, rather than compressing the review that keeps you safe.

A note on requests you can refuse or charge for

You can refuse or charge a reasonable fee only in limited cases, mainly when a request is manifestly unfounded or excessive, for example a clearly repetitive request. This is the exception, not the rule, and you should document your reasoning carefully. See DSAR exemptions before you rely on it.

Want to run this sequence without stitching together a dozen exports by hand? Obtainer takes a request from intake to a reviewable manifest, drafts the response from templates, and tracks the deadline, while DSAR automation keeps you in control of what gets redacted and approved before anything is disclosed.