A well-run GDPR data subject access request process turns a broad privacy obligation into a controlled workflow. This guide explains how to receive, verify, search, review, redact, and answer a DSAR while tracking deadlines, decisions, evidence, and recurring process improvements.
Overview
A data subject access request (DSAR) is a request from an individual to access personal data held about them. Under the GDPR, the right of access generally includes confirmation of whether personal data is being processed, access to that data, and information about how it is used. The response should be understandable and should not expose another person’s personal data or confidential information without appropriate review.
The process begins when a request reaches any channel—not only a privacy inbox. A message to customer support, an account manager, HR contact, or legal team may qualify if it clearly asks for access to personal data. Staff should know where to route these requests and should avoid delaying intake while debating the requester’s wording.
For most requests, the GDPR access request deadline is one month from receipt. The period may generally be extended by up to two additional months when a request is complex or numerous, but the requester should be informed within the initial month and told why an extension is needed. Treat the deadline as an operational control: record the receipt timestamp, calculate the target date, and assign an owner immediately.
This process should sit alongside your broader GDPR and CCPA data subject request workflow, but the rules and response content should be checked for the applicable jurisdiction before using one process for every request.
What to track
1. Intake and scope
Create a DSAR register with a unique case ID and record:
- date and time received, channel, and original wording;
- requester name, contact details, and any account or customer reference;
- the right being exercised and whether the request includes portability, correction, deletion, or restriction;
- the statutory response date, case owner, and escalation contact;
- systems, business units, and processors likely to hold relevant data.
Do not silently narrow a broad request. Ask a clarifying question when it would help locate data, but continue preparing the response and monitor the original deadline. A requester may also ask for “all information,” which requires a structured search rather than a single database export.
2. Identity verification
Verification should be proportionate to the sensitivity of the data and the risk of disclosure. Do not request more identity information than is reasonably necessary. Existing authenticated account controls may be sufficient for some requests; higher-risk cases may require an additional verification step. Record what was requested, why it was considered necessary, when it was completed, and how documents or evidence were securely handled.
If verification remains incomplete, communicate clearly what is needed and keep a record of the interaction. Avoid treating identity verification as an automatic reason to stop the clock without assessing the facts of the case.
3. Search coverage and evidence
Maintain a search plan covering relevant sources, such as production databases, customer relationship systems, support tickets, email, collaboration tools, HR systems, backups where appropriate, and information held by processors. Identify the search terms, date ranges, custodians, export method, and person who performed each search.
Track results separately from conclusions. A system that returns no records is still evidence when the system was reasonably relevant and the search was documented. Ask processors for assistance through the applicable data processing agreement (DPA), and record requests and responses in the case file. Your DPA lifecycle workflow can help establish repeatable vendor cooperation controls.
4. Review, redaction, and response
Review each item for relevance, duplicates, privileged material, confidential business information, and the rights of other individuals. Redact only what is necessary and preserve an internal copy of the unredacted review set. Keep a decision log that states the category of information withheld, the reason, and the approving reviewer. Where an exemption or limitation is being considered, obtain appropriate privacy or legal review rather than applying a blanket rule.
A response package should normally include the accessible personal data, the required processing information, a plain-language explanation of any limitations, and information about the requester’s rights to complain or seek a remedy where applicable. Use a secure delivery method and confirm that the recipient address or account is appropriate.
Cadence and checkpoints
Use the following checkpoints for every case:
- Day of receipt: open the case, preserve the original request, assign an owner, and calculate the response date.
- Early assessment: identify scope, verification needs, likely systems, processors, and any linked rights requests.
- Search checkpoint: confirm that each relevant system has an owner, a defined search method, and a recorded result.
- Review checkpoint: complete duplicate removal, third-party review, redaction, and exemption analysis with documented approvals.
- Pre-send check: verify the requester, attachments, access controls, deadline, explanation of limitations, and complaint information.
- Closeout: record the delivery date, materials supplied, unresolved risks, follow-up actions, and lessons learned.
Review the DSAR register monthly or quarterly, depending on volume. Useful measures include open cases by age, average time to first acknowledgment, cases requiring extensions, search failures, processor delays, redaction rework, and recurring data sources that are difficult to access. These are operational indicators, not automatic measures of legal compliance.
DSAR response template
Initial acknowledgment: “We received your request on [date]. We are reviewing its scope and will respond within the applicable timeframe. To protect your information, we need [proportionate verification step]. Please provide it through [secure method]. Your case reference is [ID].”
Extension notice: “Your request requires additional time because [specific complexity or volume reason]. We will provide the response by [date]. We will continue processing the request and will contact you if we need clarification.”
Completion notice: “We have completed our review. The response and supporting information are available through [secure method]. Some information has been [redacted/withheld] because [plain-language reason]. If you believe the response is incomplete, contact [privacy contact]. Information about available complaints or remedies is included below.”
How to interpret changes
A rise in DSAR volume does not necessarily indicate a compliance failure. It may reflect a product launch, account migration, employee change, or a more visible privacy contact. Look for patterns instead: repeated delays from one system, inconsistent identity checks, missing processor responses, or frequent redactions caused by poor data separation.
When a case exceeds its target date, perform a short root-cause review. Distinguish between a late intake, unclear ownership, incomplete search instructions, technical retrieval limits, review backlog, and delivery failure. Each cause requires a different corrective action. For example, a recurring export problem may justify a new system report; repeated third-party redactions may call for better data design or staff guidance.
Compare the DSAR register with your records of processing activities, retention schedule, vendor inventory, and access controls. If the register says data is held in one place but searches repeatedly find it elsewhere, update the underlying privacy documentation and control ownership. Broader security and audit evidence practices can be aligned with the SaaS compliance control testing calendar.
When to revisit
Revisit this workflow at least quarterly and after any material change to systems, vendors, authentication, retention, organizational structure, or privacy contact details. Perform a focused review after a complex request, missed deadline, complaint, security incident, or regulator communication. Also review it when supervisory-authority guidance, court decisions, or applicable national rules change.
Before each review, sample closed cases and check whether the register contains the original request, deadline calculation, verification record, search plan, system results, processor correspondence, redaction decisions, approval trail, delivery evidence, and closeout notes. Test the process with a tabletop request so technical teams can practice locating data without using a live individual’s records.
To keep the process audit-ready, assign one owner for the DSAR register, one backup owner, and named contacts for major systems and processors. Update templates only after checking the applicable legal basis and jurisdiction. Finally, use the next monthly or quarterly checkpoint to convert recurring defects into tracked actions with an owner and due date. That routine turns a one-off response exercise into a maintainable privacy compliance control.
