Skip to main content
Regulatory Council
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: Privacy & Data Protection

Data Subject Request

Also known as: DSR, Data Subject Access Request (DSAR)
Simply put

A Data Subject Request (DSR) is a formal request that an individual makes to an organization to exercise their rights over the personal data the organization holds about them. These requests typically ask the organization to give the person access to their data, correct it, delete it, or transfer it. The term is often used broadly to cover any such privacy-rights request.

Formal definition

A Data Subject Request (DSR) is a formal request submitted by an individual to an organization to exercise privacy rights over personal data concerning them. In industry usage the term is applied broadly to encompass the range of associated rights requests, commonly including access, rectification (correction), erasure (deletion), and portability (transfer) of personal data. The narrower term Data Subject Access Request (DSAR) is frequently used, sometimes interchangeably, to denote requests focused specifically on access. The precise rights available, applicable conditions, response timelines, and enforcement mechanisms are governed by the specific data protection law or regulation applicable in a given jurisdiction; those statutory particulars fall outside the scope of this definition and should be verified against the relevant primary legal source.

Why it matters

Data Subject Requests operationalize the privacy rights that individuals hold over their personal data, transforming statutory or regulatory rights into concrete obligations that an organization must be able to receive, verify, and act upon. For compliance functions, the ability to handle DSRs reliably is a visible indicator of an organization's broader data governance maturity: fulfilling a request to access, correct, delete, or transfer personal data requires the organization to know what personal data it holds, where it resides, and on what basis it is processed. Where that underlying data inventory is weak, DSR handling tends to expose the gap.

DSRs also sit at the intersection of compliance and operational risk. Because the specific rights available, the conditions attached to them, and the timelines for response are set by the data protection law applicable in a given jurisdiction, the same categories of request may carry different obligations depending on where the individual and the organization are situated. Mishandling or failing to respond to a valid request can expose an organization to enforcement action and reputational harm, and the applicable enforcement mechanisms vary by jurisdiction. Organizations should verify the statutory particulars against the relevant primary legal source rather than relying on a general definition.

Because the term DSR is used broadly in industry to cover the full range of privacy-rights requests, while the narrower Data Subject Access Request (DSAR) is often used interchangeably and sometimes limited to access requests, clarity of terminology matters. Ambiguity about which rights a given request invokes can lead to incomplete responses, and treating an access-focused label as if it excluded correction, deletion, or portability rights may leave obligations unmet.

Who it's relevant to

Privacy and compliance officers
These professionals own the design and operation of the processes by which DSRs are received, verified, and fulfilled. They must map the organization's obligations to the applicable data protection laws in each relevant jurisdiction and ensure the response process addresses the full range of requests, including access, correction, deletion, and transfer, rather than access alone.
General counsel and legal teams
Because the rights available, applicable conditions, response timelines, and enforcement mechanisms are set by jurisdiction-specific law, legal teams are typically relied upon to interpret which obligations apply to a given request and to advise where matters of legal interpretation arise. General definitions do not substitute for verification against the relevant primary legal source.
Data governance and information management teams
Fulfilling a DSR depends on knowing what personal data the organization holds and where it resides. These teams maintain the data inventories and mapping that make it possible to locate, correct, delete, or export an individual's personal data, and weaknesses in that foundation tend to surface when requests are processed.
Risk managers and internal auditors
DSR handling represents an operational and compliance risk area that can be assessed and monitored. Auditors and risk managers may evaluate whether the controls around request intake, requester verification, and timely response are functioning, and whether the process reflects the obligations applicable in the organization's operating jurisdictions.

Inside DSR

Requester Identity
Information used to establish who is submitting the request and to verify that they are the data subject (or an authorized representative acting on the data subject's behalf), which is typically required before a controller acts on the request.
Type of Right Invoked
The specific data subject right being exercised, such as access, rectification, erasure, restriction of processing, data portability, or objection. The particular rights available, their scope, and any exceptions vary by applicable law and jurisdiction.
Scope of the Request
The categories of personal data, processing activities, or time periods the request concerns. Some requests are broad and general, while others target specific records or a specific processing purpose.
Response Obligation and Timeframe
The controller's duty to respond within the period set by the applicable regulation. Specific deadlines and any permitted extensions differ across legal regimes and should be verified against the primary source governing the organization.
Verification and Handling Record
Documentation of how identity was verified, how the request was assessed, what data was located, and what action was taken, supporting the organization's ability to demonstrate accountability.
Applicable Exemptions or Limitations
Grounds on which a controller may lawfully decline, restrict, or partially fulfill a request, which depend on the governing law, the nature of the data, and competing legal obligations or rights of others.

Common questions

Answers to the questions practitioners most commonly ask about DSR.

Does a Data Subject Request only apply to requests for access to personal data?
No. While the right of access is one of the most frequently exercised rights, a Data Subject Request is a broader concept that can encompass a range of rights afforded to individuals under applicable data protection laws, which may include rectification, erasure, restriction of processing, data portability, and objection to processing. The specific rights available, and their scope and conditions, vary by jurisdiction and legal framework, so organizations should map incoming requests against the rights recognized under the laws that apply to them rather than assuming every request is an access request.
Is an organization always obligated to fully comply with every Data Subject Request it receives?
Not necessarily. In many frameworks, data subject rights are qualified rather than absolute, and requests may be subject to exemptions, exceptions, or balancing tests. For example, a request may be limited where it would adversely affect the rights of others, where retention is required by another legal obligation, or where an exception applies. Requests can also be refused or subject to a fee if they are deemed manifestly unfounded or excessive under the applicable law. Whether and to what extent a request must be honored is often a matter of legal interpretation that depends on jurisdiction and the specific circumstances, and may warrant professional advice.
How can an organization verify the identity of a person making a Data Subject Request?
Identity verification is typically undertaken to reduce the risk of disclosing personal data to an unauthorized party, and the approach is often expected to be proportionate to the sensitivity of the data and the nature of the request. Organizations commonly establish documented procedures for confirming that the requester is the data subject (or an authorized representative acting on their behalf) before acting on a request. The specific methods considered acceptable can depend on jurisdiction and context, and organizations should avoid collecting more information for verification than is necessary. Where the appropriate standard of verification is unclear, the applicable legal framework and internal policy should govern.
What timeframe typically applies to responding to a Data Subject Request?
Many data protection frameworks impose defined response timeframes, and some permit extensions in specified circumstances, such as where a request is complex or where multiple requests have been received. The exact deadlines, the conditions under which they may be extended, and any notification obligations vary by jurisdiction and framework. Because these specifics differ and can change across editions of the governing law or guidance, organizations should verify the applicable timeframes against the primary source that governs them and track requests against those deadlines.
How should Data Subject Requests be logged and tracked to support accountability?
Maintaining a record of requests received, the date of receipt, actions taken, and the outcome is a common practice that can help demonstrate accountability and support consistent handling. Such records often assist an organization in monitoring response timeframes, identifying recurring issues, and evidencing that requests were assessed against applicable rights and exemptions. The level of detail and retention period appropriate for these records may depend on jurisdiction, sector, and internal policy, and organizations should align their logging practices with the requirements and guidance that apply to them.
How should responsibility for handling Data Subject Requests be assigned within an organization?
Responsibility for receiving, assessing, and responding to requests is often allocated through defined roles and workflows, which may involve privacy, compliance, legal, IT, and relevant business functions given that personal data can reside across multiple systems. Clear decision rights help determine who evaluates whether a request is valid, whether exemptions apply, and who approves the response. The appropriate governance structure varies by organization size, sector, and jurisdiction, and in some frameworks specific roles or functions may carry defined responsibilities. Where legal judgment is required on how to handle a request, involving appropriately qualified advisers is often prudent.

Common misconceptions

A DSR is purely a compliance matter with no governance or risk dimension.
While handling a DSR is driven by compliance obligations, it also depends on governance structures that assign decision rights and responsibilities for responding, and it carries operational and legal risk if mishandled. In practice the term can span more than one GRC pillar.
Every DSR must be fulfilled in full and cannot be refused.
Applicable laws typically provide exemptions and limitations under which a request may be lawfully declined, restricted, or only partially satisfied. Whether an exemption applies is context-dependent and can involve legal interpretation that warrants professional advice.
Any request labeled a DSR must always be actioned exactly as worded without verifying the requester.
Controllers generally need to verify the identity of the requester (or the authority of a representative) before acting, so as to avoid disclosing personal data to an unauthorized party. Verification requirements vary by jurisdiction and by the sensitivity of the data involved.

Best practices

Establish clear roles and decision rights for receiving, assessing, and responding to requests, so that accountability for each step is defined rather than assumed.
Implement a proportionate identity-verification step appropriate to the sensitivity of the data before acting on a request, while avoiding collecting more information than necessary.
Maintain records of how each request was received, verified, assessed, and resolved to support the organization's ability to demonstrate accountability.
Track response timeframes against the deadlines set by the applicable law and monitor for any permitted extensions, verifying specific periods against the primary regulatory source.
Document and review the grounds for any refusal, restriction, or partial fulfillment, and escalate contested or legally ambiguous cases for professional or legal review.
Confirm that the rights recognized, exemptions available, and procedures followed reflect the specific jurisdictions and sectors in which the organization operates, since applicability varies.
Promotional banner for the Pentest Readiness checklist download