A six-step DSAR workflow

A data subject access request (DSAR) asks a company for access to personal data it holds about the requester. Use the steps below to organize the work; your team still decides the applicable requirements, scope and response.

  1. Record the request. Capture the original wording, date received and a case owner. See the DSAR intake portal guide.
  2. Review identity and scope. Record the checks and any questions before disclosing sensitive data. Read about identity verification.
  3. Track the target date and collection work. Assign system owners and document the basis for suggested dates or exceptions. See deadline tracking.
  4. Prepare and review the response. Select the intended files and have the responsible reviewer approve the packet. Follow the response packet walkthrough.
  5. Deliver securely. Send controlled access to the approved materials. Compare the controls in the secure delivery guide.
  6. Document the outcome. Retain the decision history and delivery evidence according to your organization's policy. See the audit trail guide.

For deletion, correction and other privacy requests, start with the broader privacy request management guide. To evaluate tools for this process, use the DSAR software buyer guide.

The record to carry through each handoff
StageMinimum working recordHuman check
IntakeOriginal wording, receipt time, contact route, ownerWhich request types and jurisdictions need review?
Verification and scopeChecks made, follow-up, outcome, search planIs the check proportionate to the disclosure risk?
CollectionSystems, assignees, search method, result or limitationAre results complete and tied to the right person?
Approval and deliveryCurrent packet, reviewer, decision, controlled access eventsIs this the intended material for this recipient?

What request management means in practice

A privacy request is not just a message asking for data. For the company receiving it, the work usually becomes a coordinated process across support, legal, product, engineering, and operations. Someone has to understand the request, verify the person, find the right systems, decide what can be disclosed or changed, prepare the response, deliver it securely, and preserve a record.

Small teams often start with a shared inbox and a spreadsheet. That can work for the first few requests, but it becomes risky as volume grows. Context gets split across email threads, files are copied into too many places, and it becomes difficult to explain why a request was handled a certain way.

Start with workflow control

Before broad automation, make sure each request has an owner, status, due date, and record of actions taken. A clear process helps the team answer basic questions: who is responsible, what is waiting on verification, which systems need review, whether the response is approved, and how the final materials were delivered.

The process needs to be simple enough for a lean team to run, but structured enough to support review later.

Build a repeatable intake path

A hosted portal gives customers a consistent way to submit a request. It can collect the request type, contact information, and the details your team needs to begin review. It also gives people a clearer experience than sending a message to a generic inbox.

Keep the requester's own words and the received time even when the request arrives through support or another channel. The intake checklist covers the minimum record without asking the requester to make legal classifications.

Keep identity verification explicit

Verification is a human judgment step. Teams should be able to record what was reviewed, whether additional information was needed, and why a request moved forward or paused.

Match the check to the risk. An authenticated account can provide useful evidence, while a request involving a former address or sensitive records may need focused follow-up. Avoid collecting a government ID by default when existing account information can resolve the question.

Assign evidence work instead of forwarding threads

Most privacy requests need input from more than one team. Support may know the customer account history, engineering may know where exports live, product may understand feature-specific records, and legal may need to review the response. Assigning tasks keeps those handoffs visible.

For each system, record the assignee, search terms or identifiers used, time range, result, and any limitation. The system-search worksheet provides a portable starting point.

Avoid email attachments for sensitive exports

Response files can contain sensitive personal data. Ordinary email attachments are hard to revoke, hard to audit, and easy to forward. Use controlled delivery links with expiration, revocation, passcode support where needed, and access logs instead.

Preserve an audit trail as the work happens

The best time to build the record is during the work, not after the request closes. Status changes, owner changes, verification outcomes, task completion, response approval, delivery events, and closure notes should be captured while the team is doing the work.

Use automation carefully

Automation can help with reminders, routing, exports, cleanup, and repetitive preparation work. It should not remove human review from high-impact decisions.

Automate notifications and repeatable preparation only after the team can explain the manual decision points. Keep verification, scope, exceptions, deletion treatment, disclosure, and final approval assigned to an authorised person.

For supported ways to connect your tools, see MCP and client API integrations.

Jurisdiction examples are starting points

The EU GDPR says controllers should act without undue delay and generally within one month, subject to the conditions in Article 12. UK ICO guidance explains how to calculate a calendar month and how identity or authorised-representative information can affect timing. California guidance distinguishes requests: the CPPA describes confirmation within 10 business days and a substantive response within 45 calendar days for requests to know, delete, or correct. Other request types, laws, exceptions, and facts can produce different steps. Record the rule and assumption your team reviewed rather than applying one global deadline.

Sources

Sources checked September 20, 2026. This is general operational information, not legal advice.

Common questions

What is DSAR management?

DSAR management is the workflow a company uses to receive, verify, fulfill, respond to, deliver, and document data subject access requests and related privacy requests.

Can DSAR management software provide legal advice?

No. It can organize workflow, suggested targets, tasks, files, and audit history, but legal conclusions and exceptions should remain human-reviewed.

What is the safest way to deliver DSAR response files?

Sensitive response files should be delivered through controlled links with expiration, revocation, optional passcodes, and access logs rather than ordinary email attachments.

Run the next request in a dedicated workspace

Privacy Requests helps growing teams move from scattered handling to a clear, reviewable process for intake, follow-up, secure delivery, and records.

Start free