The DSAR Process: From Intake to Response, Explained

The DSAR process is the repeatable sequence an organization follows to fulfill a data subject access request: intake, identity verification, deadline tracking, data discovery, manifest review, redaction, human approval, and delivery of the response. Treating it as a defined process rather than an ad hoc scramble is what keeps requests on time, complete, and free of accidental disclosures.

This is general information, not legal advice. Below is each stage of the process, why it matters, and where the common failure points are.

Stage 1: Intake

The process begins the moment a request arrives, and a valid request can arrive anywhere: an email, a web form, a phone call, or a chat message. It does not have to use the phrase "data subject access request" to count. The two goals at intake are to log the request in one place and to timestamp it, because the statutory deadline generally starts on receipt. A single queue for privacy request management prevents requests from sitting unnoticed in a support inbox while the clock runs.

Stage 2: Identity verification

Before any data is disclosed, you confirm the requester is who they claim to be. Disclosing personal data to an impostor is a breach, so this stage is not optional. Keep it proportionate: match the request to known account details or ask for limited confirming information rather than demanding excessive documents. Streamlined identity verification protects both the data and the deadline, since a slow verification eats into your window. Where the line sits between proportionate and excessive, and what each regime lets you ask for, is set out in the guide to verifying a DSAR requester's identity.

Stage 3: Deadline tracking

Set the due date as soon as the request is logged. Under the GDPR you have one month; under the CCPA you have 45 days. Both can be extended in limited cases, but you should plan for the original deadline and reserve time at the end for review. Automated deadline tracking keeps the countdown visible so it does not slip. The extension rules are covered in the DSAR response deadline guide.

Stage 4: Data discovery

This is the stage that decides whether the whole process succeeds, and it is where most of the time goes. A single person's data is spread across many systems: CRM, help desk, billing, email, marketing platforms, product databases, spreadsheets, and backups. Searching each by hand is slow and error-prone, and a missed system means an incomplete response. Automated personal data discovery searches your connected systems for the requester's identifiers at once, so completeness stops depending on someone remembering every tool.

Stage 5: Manifest review

Discovery produces a lot of raw material, so the next stage is to 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 a dozen separate exports. This is where you decide what is genuinely in scope for an access request, flag anything exempt or under legal hold, and mark items that will need redaction.

Stage 6: Redaction

An access request covers the requester's own personal data, not other people's. Third-party names, other customers' details, and exempt or privileged material have to be redacted before disclosure. This stage should be careful and consistent, and it should be auditable so you can show what was removed and why. Our guide on how to redact a DSAR response covers the categories, and a purpose-built redaction step keeps it reliable.

Stage 7: Human approval

Automation can find data, compile a manifest, and draft a response, but a person should approve what is actually disclosed. A human review gate before delivery catches the stray third-party detail or out-of-scope item that a machine missed. This is the stage that keeps you in control: nothing goes out until someone signs off on it.

Stage 8: Delivery and record

Deliver the response through a secure channel, then record what you disclosed, when, and to whom. That record is your evidence that you handled the request properly if the requester or a regulator asks later.

Where the process usually breaks

Knowing the stages is not the same as running them well. A defined process fails at predictable points, and it helps to know them in advance.

• The handoff at intake. A request that reaches a front-line inbox but never gets forwarded to the privacy team loses days before the process even starts.
• The gap between discovery and review. Raw exports pile up and nobody turns them into a scoped manifest, so the request stalls halfway.
• The rush at the end. When discovery starts late, redaction and approval get compressed, and that is exactly when mistakes slip through.

Each of these is a timing problem more than a knowledge problem. The teams that run the process smoothly are the ones that front-load it: log fast, verify fast, and start discovery immediately, so the careful stages at the end are never squeezed.

Why a defined process beats improvising

Handled ad hoc, every DSAR feels like an emergency: someone scrambles across systems, misses a tool, and runs out of time to redact carefully. Handled as a defined process, the same request is routine. The stages are the same each time, the deadline is visible from the start, and review is built in rather than skipped. If you want a step-by-step version to hand your team, the DSAR checklist turns this process into a working list, and it applies whether you are meeting GDPR or CCPA obligations.

Want the whole process in one place? Obtainer runs a request from intake to a reviewable manifest, drafts the response from templates, and tracks the deadline. DSAR automation handles the discovery and drafting while you review, redact, and approve everything before it is disclosed.