How to Respond to a Data Subject Access Request, Step by Step

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.

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 DSAR response deadline 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. Here is the whole sequence at a glance.

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.