Organisations should verify the requester’s identity, locate the relevant personal data, and respond without undue delay and within one month at most. If the request is complex or numerous, they may extend the deadline by two months, but they should explain that extension within the first month. They should also explain any refusal clearly and tell the person how to complain to the regulator.
How to make a DSAR workable without turning it into a barrier
A good DSAR process is built for accuracy, not friction. Organisations should route the request to a clear owner, confirm the requester’s identity only to the level needed to protect the data, and avoid asking for extra information unless it is genuinely necessary to find the right records or prevent disclosure to the wrong person. The process should feel controlled, but not obstructive.
That balance matters because the operational failure mode is usually self-inflicted delay: requests sit in inboxes, teams duplicate effort, or legal review is added too early. A practical response process should preserve evidence of what was searched, what was disclosed, and why any redactions or refusals were applied, while keeping the requester informed if extra time is needed.
For governance teams, the right question is whether the DSAR workflow can consistently identify the data subject, locate the relevant records, and meet the statutory timeline without unnecessary back-and-forth. If those steps are unclear, the organisation is likely to turn a routine privacy right into a service problem.
What “without undue delay” means in practice
Under GDPR, the timeline starts when the organisation has enough information to act on the request, not when every internal team has finished debating ownership. That means the first priority is intake: record the date received, decide who owns the case, and establish whether the request is clear enough to search for data. If clarification is needed, ask quickly and narrowly.
The one-month rule is not a target to work up to, it is the default response window. Complex or numerous requests can justify a two-month extension, but the organisation should not wait until the deadline has passed before explaining that extension. Good practice is to notify the requester within the first month, say why the extension is needed, and keep the explanation specific to the work actually required.
When the request is straightforward, the biggest delay usually comes from over-processing. Teams often add unnecessary review layers, re-open ownership questions, or demand identity evidence that exceeds the risk of mistaken disclosure. The faster path is usually a focused search, a controlled review for third-party data and exemptions, then disclosure in a usable format.
Where friction should be removed, and where control still matters
Friction should be removed from the search and response workflow, not from the safeguards. A DSAR still requires the organisation to verify that it is disclosing data to the correct person, to avoid exposing other people’s data, and to apply exemptions where the law allows or requires it. The control objective is precision, not bureaucracy.
That is why requests should be triaged by data type and source system. Records held in customer platforms, HR systems, ticketing tools, email, logs, and archived files may require different retrieval methods, but the case owner should still maintain one view of the request and one response deadline. The more fragmented the estate, the more important it is to standardise search instructions and review checkpoints.
Organisations that already manage identity and access well will usually handle DSARs more cleanly, because access controls, record ownership, and data retention practices make it easier to find what exists and justify what was not found. NHIMG’s Identity Data Privacy and Consent Guide is useful here because it frames data subject rights, minimisation, retention, and lawful handling as part of the same operational workflow. A broader control lens is also captured in Identity Security Regulatory Map, which helps teams connect privacy obligations with adjacent security and governance controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Article 12 — Transparent information, communication and modalities for the exercise of the rights of the data subject | Directly governs DSAR handling, timing, and clear communication. |
| Article 15 — Right of access by the data subject | Defines the access right the request is exercising. | |
| Article 17 — Right to erasure ('right to be forgotten') | Relevant where requests or responses involve deletion or refusal boundaries. | |
| Recommendation — Use Article 12 to keep DSAR handling timely, transparent, and easy for data subjects to exercise. Use Article 15 to scope what must be searched, reviewed, and disclosed in response. Use Article 17 to distinguish access handling from separate erasure obligations. | ||
| NIST SP 800-53 Rev 5 | AR-8 — Accounting of Disclosures | Supports tracking what personal data was disclosed in response to a DSAR. |
| Recommendation — Maintain an accounting of disclosures so DSAR responses can be evidenced and audited. | ||
Practitioner Guidance
What to verify: Before you trust the process, verify that the organisation can consistently find the records it holds, identify the correct requester, and explain any redactions or exemptions in plain language. If the search path depends on one person’s memory, the process is too fragile.
What good looks like: One intake path, one accountable owner, documented search steps, a tracked deadline, and a response that is complete enough to be useful without oversharing. The best DSAR operations feel calm because the workflow is repeatable, not because the review was superficial.
Common mistake: Treating every request like an exceptional legal event. That usually creates unnecessary approval loops, slow searches, and defensive over-collection of information from the requester. A better approach is to standardise the routine case and reserve escalation for genuinely complex searches, exemption decisions, or third-party disclosure issues.
Decision rule: If the request can be fulfilled from known systems with ordinary effort, keep the process moving and disclose on time. If the request is unusually broad, technically difficult, or raises a real disclosure risk, document the complexity early and issue a timely extension notice rather than letting the deadline slip.
Practitioner takeaway: A low-friction DSAR process is one that is tightly owned, narrowly verified, and deadline-driven, with escalation used for genuine complexity rather than as a default response.
Related resources from NHI Mgmt Group
- How should organisations handle requests to correct inaccurate personal data without creating unnecessary friction for users?
- How should organisations limit SSO access without creating unnecessary friction for employees?
- What happens when organisations try to handle personal data under the GDPR without transparent policies and breach processes?
- How should organisations handle identity verification before fulfilling data subject access requests under state privacy laws?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
