Skip to main content
DataRidge
Category: Data Subject Rights

Subject Rights Request

Also known as: SRR, Data Subject Request, DSR, Subject Access Request, SAR, Data Subject Access Request, DSAR, Data Subject Rights Request
Simply put

A subject rights request is when a person asks an organisation to act on the rights they have over their own personal information, such as getting a copy of the data an organisation holds about them or learning how it is being used. Anyone can make such a request, and you generally do not need a lawyer to do so. One common type is a subject access request, where a person asks for a copy of their personal data.

Formal definition

A subject rights request is a request made by an individual (a data subject) to exercise one or more of their rights over the processing of their personal data. The most commonly encountered form is the right of access, exercised through a subject access request (SAR or DSAR), which under the EU GDPR and UK GDPR entitles the individual to obtain confirmation of processing, a copy of their personal data, and supplementary information including the purposes of processing, the categories of personal data concerned, and the recipients or categories of recipients. The term is often used more broadly to encompass requests engaging other data subject rights (for example rectification, erasure, restriction, portability, or objection), though the specific rights available, their conditions, and applicable exemptions differ by legal regime; the terminology and scope under regimes such as the CCPA and CPRA are not equivalent to those under the GDPR. Note that acronym usage varies in practice: 'SAR'/'DSAR' typically denote access requests specifically, while 'DSR'/'SRR' are broader. This entry defines the request concept and does not cover response timescales, permitted charges, verification requirements, exemptions, or enforcement, which are governed separately and vary by jurisdiction and instrument.

Why it matters

Subject rights requests are the primary mechanism through which individuals exercise control over their personal data, and they translate abstract data protection principles into concrete operational obligations for organisations. The most commonly encountered form, the subject access request, allows a person to obtain confirmation that their data is being processed, a copy of that data, and supplementary information such as the purposes of processing, the categories of personal data involved, and the recipients or categories of recipients. Because anyone can make such a request and generally does not need legal representation to do so, organisations should expect to receive them from a wide range of individuals, not only those with legal support.

For organisations, the ability to locate, retrieve, and disclose an individual's personal data on request is a practical test of underlying data governance. Handling these requests depends on knowing where personal data resides, understanding how it flows across systems, and being able to demonstrate accountability rather than merely asserting it. Weak data mapping, poor lineage, or fragmented records tend to surface first when an access request cannot be answered accurately or completely.

The rights that a subject rights request may engage, and the conditions attached to them, differ by legal regime. The rights available under the EU GDPR and UK GDPR are not equivalent to those under the CCPA and CPRA, and terminology varies in practice, with 'SAR' and 'DSAR' typically referring to access requests specifically while 'DSR' and 'SRR' are broader. Organisations operating across jurisdictions should not assume a single process satisfies every applicable regime.

Who it's relevant to

Data Protection Officers and Privacy Leads
DPOs and privacy leads are typically responsible for ensuring the organisation can receive, triage, and respond to subject rights requests in line with the applicable regime. This requires understanding which rights are engaged, how terminology maps to specific requests, and how obligations differ across jurisdictions where the organisation operates.
Data Governance and Stewardship Teams
The ability to answer an access request accurately depends on knowing where personal data resides and how it moves across systems. Governance and stewardship functions that maintain ownership, lineage, and catalogues provide the foundation that makes complete and defensible responses possible.
Legal and Compliance Professionals
Because the rights available and their conditions differ by legal regime, legal and compliance teams should assess which instrument applies before treating a request as routine. The rights under the EU GDPR and UK GDPR are not equivalent to those under the CCPA and CPRA, and this entry does not address exemptions or enforcement, which are governed separately.
Individuals Exercising Their Rights
Anyone can make a subject rights request, and a solicitor is generally not required to do so. Individuals can request a copy of the personal data an organisation holds about them along with information about how it is being processed, subject to the specific rights and conditions of the applicable regime.

Inside SRR

Data Subject Identification and Verification
The process of confirming that the individual making the request is who they claim to be before disclosing personal data. Controllers generally bear responsibility for verifying identity proportionately, avoiding both unauthorized disclosure and excessive collection of additional data.
Scope of Rights Covered
The specific rights a request may invoke, which vary by regime. Under the EU GDPR and UK GDPR these typically include access, rectification, erasure, restriction, portability, and objection; under the CCPA and CPRA they typically include access, deletion, correction, and opt-out of sale or sharing. The available rights and their conditions are not interchangeable across regimes.
Controller Obligation to Respond
The accountability of the data controller (not the processor) to receive, assess, and act on the request within the applicable timeframe. Processors generally assist the controller but do not independently determine how to respond.
Applicable Response Timeframe
The period within which the controller must respond, which differs by jurisdiction and by the nature of the request. Timeframes and any permitted extensions depend on the governing instrument and should be confirmed against the specific regime rather than assumed to be uniform.
Assessment of Exemptions and Limitations
Evaluation of whether a request can be lawfully refused or partially fulfilled, for example where fulfilling it would adversely affect the rights of others or where an exemption applies. The availability and grounds for such limitations vary by jurisdiction.
Record of the Request and Response
Demonstrable documentation of the request, decisions made, and actions taken, supporting the accountability principle under governance frameworks, which generally requires evidence rather than stated intent.

Common questions

Answers to the questions practitioners most commonly ask about SRR.

Is a subject rights request always subject to a fixed one-month response deadline that cannot change?
Not necessarily. Response timeframes are defined by the applicable regime rather than being universal, and several frameworks permit extensions in defined circumstances, such as where a request is complex or where a data subject has made numerous requests. The starting point, the permitted extension conditions, and the notice obligations differ between the EU GDPR, the UK GDPR, and the CCPA and CPRA. You should scope your handling to the specific regime that applies and not assume a single deadline applies everywhere. This answer does not address the precise duration or article references for any particular regime.
Does an organization have to fulfill every subject rights request it receives?
No. Rights are generally qualified rather than absolute, and their availability depends on the lawful basis for processing, the regime, and the context. For example, some rights apply only to certain processing activities, and there are recognized grounds on which a request may be refused, limited, or subject to exemption. A controller must typically be able to demonstrate the reasoning behind any refusal, since accountability under governance frameworks requires evidence rather than stated intent. This entry does not enumerate every ground for refusal or exemption, which vary by jurisdiction and instrument.
Who is responsible for responding to a subject rights request when a processor holds the data?
In most frameworks the controller bears primary responsibility for responding to and deciding on the request, because the controller determines the purposes and means of processing. A processor generally must assist the controller in fulfilling requests, typically under the terms of the processing agreement, but does not itself decide the outcome. Where a request is received directly by a processor, it is commonly forwarded to the relevant controller. This describes the general allocation of responsibility and does not address the specific contractual clauses or transfer mechanics involved.
How should an organization verify the identity of a requester before acting?
Identity verification is generally expected to be proportionate to the sensitivity of the data and the risk of disclosure to the wrong person, without collecting excessive additional data solely for verification. Overly burdensome verification can itself undermine the right, while insufficient verification risks unauthorized disclosure. The appropriate approach depends on the regime, the channel through which the request arrived, and the nature of the data involved. This entry does not prescribe specific verification methods or documentation standards, which should be defined in your internal procedures.
What records should be kept to demonstrate a request was handled properly?
Because accountability requires demonstrable evidence rather than stated intent, organizations typically retain records showing when the request was received, what verification was performed, what decision was reached, the reasoning for any refusal or limitation, and when and how the response was provided. Such records support the ability to evidence compliance if challenged. This entry does not specify retention periods for these records, which depend on applicable retention rules and jurisdictional requirements outside this scope.
How can subject rights requests be handled consistently across multiple systems and business units?
Consistent handling generally relies on documented intake procedures, defined roles and ownership, and the ability to locate relevant data across systems, which connects to data governance functions such as data catalogs, lineage, and stewardship. Coordination is often needed between governance, security, legal, and operational teams so that a request can be fulfilled wherever the data resides. Note that having a data inventory or catalog tool is not equivalent to meeting any records of processing obligation, and neither guarantees compliance on its own. This entry does not cover specific tooling selection or workflow platform requirements.

Common misconceptions

The right to erasure means a controller must always delete the requested data.
Erasure rights are generally conditional and subject to exemptions and limitations that vary by jurisdiction. A controller may be permitted or required to retain data in certain circumstances, so a request does not create an absolute obligation to delete.
Subject rights requests are handled the same way under every privacy regime.
The rights available, verification expectations, response timeframes, and permissible exemptions differ across instruments such as the EU GDPR, UK GDPR, and CCPA/CPRA. Treating them as interchangeable can lead to non-compliant handling; each request should be assessed against its governing regime.
The data processor is responsible for deciding how to respond to a request.
Accountability for responding generally rests with the data controller. Processors typically assist the controller in fulfilling requests but do not independently determine the response.

Best practices

Verify the requester's identity proportionately, collecting only the additional data necessary to confirm identity and avoiding both unauthorized disclosure and excessive data collection.
Determine the governing regime for each request and apply the specific rights, timeframes, and exemptions that apply, rather than assuming a single uniform process across jurisdictions.
Clearly assign controller and processor responsibilities in advance, ensuring processors know how to assist while the controller retains decision-making accountability.
Assess each request against applicable exemptions and limitations before acting, documenting the reasoning where a request is refused or only partially fulfilled.
Maintain demonstrable records of each request, the decisions made, and the actions taken to support the accountability principle with evidence rather than stated intent.
Confirm applicable response timeframes and any permitted extensions against the relevant instrument, and track deadlines to ensure timely handling.