DSAR Process Guide: A Practical Workflow for Handling GDPR Data Requests

Overview

A data subject access request (DSAR), also called a subject access request, is a request from an individual to access personal data held about them. Depending on the circumstances, the response may also need to explain how the data is used, where it came from, who receives it, how long it is retained, and what rights the individual has.

The quality of a DSAR process depends less on a single privacy tool than on clear ownership and repeatable controls. Your workflow should connect privacy, legal, security, IT, customer support, HR, and relevant business teams. It should also account for data held in cloud applications, email, collaboration platforms, databases, support systems, paper records, and systems operated by processors.

As a general GDPR operating rule, handle a request without undue delay and normally within one month of receiving it. A request may require additional time where the applicable rules permit an extension, but the requester should be informed within the required timeframe. Because deadlines and exceptions can depend on the request and applicable jurisdiction, record the receipt date immediately and confirm the legal position before relying on an extension or restriction.

A practical DSAR process has six stages:

1. Receive and log the request.
2. Verify the requester’s identity proportionately.
3. Clarify scope where clarification is genuinely needed.
4. Locate, collect, and review responsive data.
5. Apply lawful exemptions, redactions, and approvals.
6. Deliver the response securely and close the record.

Keep a central DSAR register even when the request appears simple. The register should capture the requester, receipt date, owner, systems searched, decisions made, response date, and any follow-up work. It becomes both an operational aid and evidence that the organization manages privacy rights consistently.

Checklist by scenario

1. New request received

• Accept requests received through email, web forms, support channels, post, or other established contact routes.
• Record the exact wording, date, time, channel, requester, and recipient.
• Open a case ID and calculate the working deadline using the applicable legal and organizational rules.
• Identify whether the request is clearly a data access request or also includes correction, deletion, objection, portability, or restriction requests.
• Acknowledge receipt and explain the next step without promising an outcome that has not been reviewed.
• Notify the privacy owner and assign one accountable case manager.

Do not reject a request because the individual does not use the organization’s preferred form. A form can improve consistency, but it should not become an unnecessary barrier to exercising a right.

2. Identity verification is needed

• Assess the risk of disclosing the data before requesting evidence.
• Use information already held to verify identity where practical, rather than collecting excessive new information.
• Ask for only proportionate evidence and explain how it will be used and protected.
• Use stronger verification for sensitive data, unusual requests, changed contact details, or suspected account takeover.
• Record what was requested, why it was necessary, when it was received, and who approved the decision.
• Pause disclosure while verification is incomplete, but continue tracking the case and communicate clearly with the requester.

Verification should not be used as a routine delay tactic. If the organization already has sufficient assurance about the person’s identity, asking for additional documents may create unnecessary privacy and security risk.

3. The request is broad or unclear

• Separate genuine ambiguity from a request that is simply broad.
• Ask focused questions about dates, products, accounts, teams, or interactions that would help locate data.
• Explain that clarification is intended to make the search accurate, not to reduce the individual’s rights.
• Continue reasonable preparation while awaiting clarification, including identifying likely systems and custodians.
• Record the clarification request, the response, and how the final scope was agreed.

Do not treat a broad request as permission to search only the easiest system. Define a defensible search scope based on the organization’s data map, the individual’s relationship with the organization, and the wording of the request.

4. Searching internal and cloud systems

• Build a search plan from the records of processing activities, application inventory, data map, and relevant retention schedules.
• Search direct identifiers such as name, email address, customer ID, employee ID, account number, and known aliases.
• Include structured records, email, ticketing platforms, chat, file storage, CRM records, HR systems, call records, and relevant paper files.
• Ask system owners and processors to confirm the search method, date range, and results.
• Document systems searched, search terms, custodians consulted, dates searched, and any systems excluded with reasons.
• Consider archived or backup data according to accessibility, retention, restoration risk, and applicable legal guidance.
• Preserve relevant records while the review is active, especially where routine deletion could remove responsive data.

For cloud services, identify whether the organization is the controller, a processor, or both in the relevant processing activity. Contractual obligations should explain how the provider supports searches, exports, corrections, deletions, and secure transfer. Your DPIA and ROPA guide can help connect the DSAR workflow to processing records and system ownership.

5. Reviewing, redacting, and approving the response

• Deduplicate results while preserving enough context to explain the search and review.
• Separate the requester’s personal data from internal notes, business records, and information about other people.
• Review for third-party personal data, legally protected material, security-sensitive information, confidential business information, and applicable statutory exemptions.
• Redact only what is necessary and keep an internal copy of the unredacted record under restricted access.
• Have privacy or legal reviewers approve unusual exclusions, extensive redactions, or a decision to withhold records.
• Prepare a plain-language explanation of the response, including the data categories and relevant processing information.
• Check that the response addresses every part of the request and does not disclose another person’s information unnecessarily.

Exemptions are not a general shortcut. The applicable exemption, its scope, and the reasoning for using it should be checked against the relevant law and documented in the case record.

6. Secure delivery and closure

• Choose a delivery method appropriate to the sensitivity and volume of the data.
• Confirm the destination address or account before sending.
• Use access controls, encryption, expiring links, or a separate verification channel where appropriate.
• Record the response date, delivery method, file inventory, redactions, exemptions, and any unresolved items.
• Retain the case record according to the privacy case-retention schedule, not indefinitely by default.
• Track follow-up actions, such as correcting records, updating suppression lists, notifying a processor, or improving a system search.

What to double-check

Before approving a response, run a short quality review:

• Deadline: Is the receipt date correct, and is the response or extension communication on time?
• Identity: Was verification proportionate and completed before disclosure?
• Scope: Did the search reflect the request and the organization’s actual data environment?
• Processors: Did relevant vendors confirm their searches and provide usable exports?
• Completeness: Were aliases, historic accounts, shared mailboxes, collaboration tools, and offline records considered?
• Redaction: Is each redaction necessary, technically effective, and documented?
• Consistency: Does the response match the organization’s privacy notices, retention practices, and records of processing?
• Security: Can the requester access the material without exposing it to an unintended recipient?
• Closure: Is there a complete audit trail of decisions, approvals, and follow-up tasks?

Test the workflow with a sample request before relying on it during a busy period. A tabletop exercise can reveal missing system owners, unclear escalation paths, broken export processes, or inconsistent identity checks. The same exercise can feed a broader privacy compliance or data governance improvement plan.

Common mistakes

• Starting the clock late: Routing a request between departments before logging it can create avoidable deadline pressure.
• Searching one application: A customer portal or CRM rarely represents the full data environment.
• Over-verifying: Excessive identity evidence increases collection and storage risk without necessarily improving assurance.
• Using blanket redactions: Removing an entire document when only a small portion is protected can make the response incomplete.
• Ignoring informal channels: Support tickets, chat messages, meeting notes, and email may contain responsive personal data.
• Failing to involve processors: Contracts and operational contacts should make it possible to obtain records within the response window.
• Relying on undocumented judgment: If the case file does not explain what was searched and withheld, the organization may struggle to defend its process.
• Sending data through ordinary email without review: Delivery security should reflect the sensitivity of the material.
• Closing without remediation: A DSAR can expose inaccurate records, excessive retention, or an undocumented processing activity that needs correction.

When to revisit

Review the DSAR process before seasonal planning cycles, after major system or organizational changes, and whenever privacy requirements or regulator guidance change. Revisit it when the organization adopts a new CRM, help-desk platform, collaboration suite, identity provider, analytics tool, or cloud storage service. Vendor changes should also trigger a check of processor terms, search support, export formats, and escalation contacts.

At least periodically, test the workflow from intake to secure delivery. Sample closed cases for deadline accuracy, identity verification, search coverage, redaction quality, approval records, and retention. Update the system inventory and records of processing activities when testing identifies a previously missed data store. For related governance work, see the cloud compliance controls mapping guide.

To put this guide into action, assign a DSAR owner, create a central register, publish an intake route, map system custodians, prepare verification and response templates, and run one test request. Treat each completed request as operational feedback: record what took time, which searches failed, and which decisions required escalation. A DSAR process becomes dependable when those lessons are converted into updated controls, training, and documented procedures.