A well-run GDPR data subject access request (DSAR) process gives your team a consistent way to receive, verify, search, review, redact, and answer requests without losing deadlines or audit context. This practical DSAR template explains the workflow, assigns responsibilities, and identifies the recurring metrics and checkpoints that keep privacy operations reliable as systems, processors, and request volumes change.
Overview
A DSAR is a request from an individual to access personal data held about them and, where applicable, receive related information about how that data is processed. The request may arrive through a privacy inbox, support ticket, web form, postal mail, or another channel. It does not need to use legal terminology to require attention. A message such as “What information do you have about me?” may need to enter the same workflow as a formal request.
The operational goal is not simply to send a data export. Your team must identify the requester, locate relevant data across systems, assess whether any information should be withheld or redacted, prepare an understandable response, and retain enough evidence to show how the request was handled. The exact legal analysis can depend on the requester, the data, the organization’s role, and applicable exemptions, so this workflow should be reviewed by the person responsible for privacy or legal advice when a request is complex.
Use the following process as a repeatable baseline:
- Receive and classify: capture the request, date received, channel, requester, and scope.
- Acknowledge and assign: create an internal record, confirm ownership, and communicate next steps when appropriate.
- Verify identity proportionately: request only information reasonably needed to avoid disclosing data to the wrong person.
- Clarify scope if needed: ask focused questions when the request is unusually broad or ambiguous, while avoiding unnecessary delay.
- Search and collect: identify systems, teams, processors, and data stores that may contain responsive information.
- Review and redact: separate the requester’s data from third-party information, privileged material, security-sensitive content, or other potentially restricted material.
- Respond and record: deliver the response securely, document decisions, and close or escalate the request.
For wider privacy operations, connect this workflow to your DPIA and ROPA process, retention rules, and system inventory. A DSAR process is only as dependable as the data map and ownership model behind it.
What to track
DSAR intake form
Use one intake record for every request, even when the request first arrives in another department. Your form or ticket should capture:
- Request ID and date and time received
- Requester name, contact details, and preferred response channel
- Original request in the requester’s own words
- Relevant account identifiers, such as a customer ID or email address
- Whether the request concerns access only or includes correction, deletion, restriction, objection, or portability
- Identity-verification status and the evidence or decision supporting it
- Systems, business units, and processors likely to hold responsive data
- Assigned privacy owner, technical search owners, reviewer, and approver
- Target response date, extension decision if relevant, and communication history
- Final outcome, delivery method, redactions, exemptions considered, and closure date
Keep the original request and later interpretations separate. This helps reviewers distinguish what the individual actually asked from internal assumptions about scope.
Identity-verification decision table
Verification should be proportionate to the risk of disclosure. Avoid collecting a full identity document by default when a lower-risk check can establish reasonable confidence.
| Situation | Possible approach | Decision to record |
|---|---|---|
| Existing authenticated account | Use the logged-in account or an established account-recovery method. | Why the account context was sufficient. |
| Request from a known email address | Confirm through that address and compare available account details. | Checks completed and any residual risk. |
| Unusual channel or conflicting details | Request limited additional information or use a stronger verification step. | Why the stronger step was necessary. |
| Authorized representative | Verify both the individual and the representative’s authority. | Authority evidence and scope. |
| Verification cannot be completed | Explain what is missing and provide a reasonable route to continue. | Attempts made and reason the request remains open or is refused. |
Do not place identity documents or sensitive verification evidence in an unrestricted ticket. Limit access, set a deletion or retention rule, and record the outcome rather than copying unnecessary documents into the DSAR file.
Role matrix
| Role | Responsibility |
|---|---|
| Privacy owner | Interprets the request, monitors the timeline, coordinates decisions, and approves the response. |
| Service or account owner | Confirms customer context and helps identify relevant records. |
| System search owner | Runs documented searches in applications, databases, logs, collaboration tools, and backups where relevant. |
| Security reviewer | Assesses disclosure risks, access controls, and possible exposure of credentials or security-sensitive information. |
| Legal or senior reviewer | Reviews complex exemptions, third-party data, disputes, repeated requests, or high-risk disclosures. |
| Response coordinator | Prepares the response, checks formatting and redactions, delivers it securely, and records closure. |
Search and evidence record
For each data source, record the system name, owner, search terms or identifiers, date searched, search result, reviewer, and any limitations. Include structured systems such as CRM and billing platforms, unstructured sources such as email and support tickets, and relevant processors identified in your records of processing. Do not assume that a single database export represents all personal data.
Before delivery, review whether the response contains another person’s personal data, confidential business information, authentication secrets, or information that could create a security risk. Redaction is a controlled decision, not an opportunity to remove inconvenient records. Note what was withheld or obscured and the reason for the decision.
Cadence and checkpoints
Many organizations use a timeline tracker based on the date the request was received. GDPR response periods are commonly calculated from receipt, subject to the applicable circumstances and rules. Build the workflow to support the generally applicable one-month response period, and route any proposed extension or limitation for a documented privacy review rather than assuming it is available.
| Checkpoint | Action |
|---|---|
| Day received | Create the DSAR record, preserve the original request, classify the rights involved, and assign an owner. |
| Early triage | Assess identity, scope, systems, processors, likely complexity, and whether clarification is needed. |
| Search phase | Send specific tasks to system owners, track responses, and follow up on missing evidence. |
| Review phase | Validate completeness, examine third-party information, apply redactions, and obtain required approvals. |
| Before target date | Run a quality check, confirm the secure delivery method, and prepare any explanation of scope or limitations. |
| Closure | Deliver the response, record the outcome, retain the case record according to policy, and capture lessons learned. |
Track operational metrics monthly or quarterly. Useful measures include request volume by channel, median and maximum handling time, requests nearing the target date, verification failures, clarification cycles, systems searched, processor delays, redaction frequency, reopened requests, complaints, and recurring causes of delay. Metrics should help improve the process, not encourage teams to close requests prematurely.
How to interpret changes
A rise in DSAR volume may indicate customer growth, a new product, a change in account practices, or a more visible privacy channel. It does not automatically mean the process is failing. Look at volume alongside complexity, response quality, and the amount of manual work required.
Repeated delays from one system owner suggest an ownership or data-discovery problem. Requests requiring searches across many tools may indicate that the data inventory, retention schedule, or application integration needs improvement. A high rate of identity-verification failures may reflect fraud attempts, but it may also show that the verification instructions are unclear or overly demanding.
Frequent redactions should trigger a review of the underlying data flows and access design. If teams regularly find credentials, internal notes, or unrelated third-party data in export files, improve data minimization, role-based access, record structure, and export tooling. If processors respond slowly, update contracts, contact paths, and due-diligence checks. Your vendor risk assessment workflow can include DSAR assistance, search capability, response timing, and deletion support.
Review a sample of closed cases for completeness: Was the request classified correctly? Was identity verification proportionate? Were all likely systems searched? Were decisions and redactions explained? Was the response delivered through a suitable channel? Sampling is often more informative than a single average handling-time metric.
When to revisit
Review this DSAR process at least quarterly and perform a fuller privacy-process review annually. Revisit it sooner when a request arrives that falls outside the normal workflow, a new product or data source is introduced, a processor changes, the organization acquires another business, or a system migration changes where personal data is stored.
Use this update checklist:
- Confirm the response timeline and escalation instructions against current legal guidance and internal privacy advice.
- Recheck identity-verification steps for proportionality, security, accessibility, and data minimization.
- Update the system and processor inventory, including new SaaS applications, archives, backups, and support tools.
- Test that search owners can locate data using the identifiers available to the privacy team.
- Review retention and deletion rules for DSAR records and verification evidence.
- Sample completed requests and document corrective actions.
- Run a tabletop exercise for a broad, repeated, representative, or security-sensitive request.
Keep the current intake form, role matrix, timeline tracker, and escalation list in a controlled location. When the next request arrives, open the tracker immediately, preserve the original message, assign one accountable owner, and set the first review checkpoint. For related retention controls, see the data retention and deletion policy template. A maintained process turns DSAR handling from an improvised search into a repeatable privacy operation.
