Category: Privacy & Data Protection
Data Subject Rights
Also known as: DSR, Individual Rights
Simply put
Data subject rights are the legally recognized abilities that individuals have to exercise a degree of control over how organizations handle their personal data. Depending on the applicable law, these can include being told when your data is processed, seeing what data an organization holds about you, correcting errors, and in some cases asking for your data to be deleted. The specific rights available, and how they must be honored, vary by jurisdiction and by the legal framework that applies.
Formal definition
Data subject rights are the enforceable entitlements granted to natural persons ('data subjects') that allow them to influence the processing of their personal data by controllers and, where relevant, processors. Under the EU General Data Protection Regulation (GDPR)—which sources here treat as the reference framework—these commonly enumerated rights include the right to be informed, the right of access (typically associated with Art. 15), the right to rectification (Art. 16), the right to erasure/'right to be forgotten', and the right to restrict processing, among others. The precise scope, applicable exemptions, response timelines, and enforcement mechanisms are jurisdiction- and instrument-specific; the evidence here documents the GDPR and UK data protection context, and these rights should not be assumed to apply identically under other legal regimes. Note that data subject rights are a data protection concept and are distinct from AI governance or model risk management controls, though the exercise of such rights can create obligations for organizations deploying AI systems that process personal data.
Why it matters
Data subject rights are a central mechanism through which data protection law gives individuals a measure of control over how their personal data is handled. For organizations, honoring these rights is not optional where the applicable law grants them: under the EU GDPR and the UK data protection framework documented in the sources here, controllers are expected to respond to requests such as access, rectification, erasure, and restriction of processing. Failing to operationalize these rights can expose an organization to regulatory scrutiny and enforcement, and it can erode the trust of the individuals whose data is being processed.
Who it's relevant to
Privacy and Data Protection Officers
Those responsible for data protection compliance must design and maintain processes to receive, verify, and respond to data subject requests within the timelines and scope set by the applicable law. They also assess which exemptions apply and coordinate the organization's response across business functions.
Compliance and Legal Professionals
Legal and compliance teams interpret how rights such as access, rectification, erasure, and restriction of processing apply under the specific framework governing the organization—for example the EU GDPR or the UK data protection regime documented here—and advise on jurisdiction-specific scope, exemptions, and enforcement exposure. They should avoid assuming that rights defined under one regime transfer identically to another.
Data Scientists and AI System Owners
Teams deploying AI systems that process personal data may need to support the exercise of these rights, since requests to access, correct, or delete personal data can require locating and modifying that data within model pipelines and datasets. While data subject rights are a data protection concept rather than an AI governance or model risk control, their exercise can create concrete operational obligations for AI systems.
Auditors and Second-Line Reviewers
Reviewers assessing an organization's data protection posture examine whether processes for handling data subject requests exist, function as intended, and align with the requirements of the applicable legal framework. They also evaluate whether controls appropriately account for personal data held within AI and analytics systems.
Inside DSR
Right of Access
The entitlement of an individual (data subject) to obtain confirmation of whether their personal data is being processed and, where it is, to receive a copy of that data along with related information about the processing. In data protection regimes such as the EU GDPR, this is a core subject right; its precise scope and exceptions vary by jurisdiction.
Right to Rectification
The ability to have inaccurate personal data corrected and incomplete data completed. In an AI context, this typically concerns input or training-relevant records rather than model parameters themselves, and the practical mechanics differ from correcting a conventional database record.
Right to Erasure
Often described as the 'right to be forgotten,' this allows individuals to request deletion of personal data under defined conditions. It is not absolute and is subject to exceptions; how it applies to trained models is an evolving and contested question rather than settled practice.
Right to Restriction of Processing
The ability to limit how personal data is used in specified circumstances, for example while the accuracy of data is being contested. This restricts processing without necessarily requiring deletion.
Right to Data Portability
In some frameworks, the entitlement to receive personal data in a structured, commonly used, machine-readable format and, where feasible, to have it transmitted to another controller. Its availability and scope are jurisdiction-dependent.
Right to Object
The ability to object to certain processing, including processing for direct marketing or, in some regimes, processing based on particular legal bases. The effect of an objection depends on the grounds and applicable exceptions.
Rights Related to Automated Decision-Making
In some data protection regimes, provisions addressing decisions based solely on automated processing that produce legal or similarly significant effects, which may include safeguards such as human involvement. The precise triggers, thresholds, and remedies vary by framework and are subject to interpretation.
Common questions
Answers to the questions practitioners most commonly ask about DSR.
Does responding to data subject rights requests fall under model risk management?
Not primarily. Data subject rights are principally an obligation arising from data protection and privacy law, and handling them typically sits within privacy governance and legal functions rather than model risk management as commonly framed by guidance such as SR 11-7. There can be overlap where an AI system processes personal data or produces automated decisions, but treating data subject rights as a model risk management task conflates a distinct legal obligation with the identification, measurement, and control of model risk. The two should be coordinated without being collapsed into one.
Do data subject rights apply equally everywhere and in the same form?
No. The specific rights available, their conditions, and the exceptions vary by jurisdiction and legal instrument, so it is a mistake to assume a single universal set of rights applies globally. What a data subject can request, and how an organization must respond, depends on the applicable law and its scope. Because regulatory treatment differs across jurisdictions and continues to evolve, organizations should scope obligations to the specific legal regimes that apply to them rather than assume interchangeability.
How should an organization operationalize the intake and routing of data subject rights requests?
In many programs, organizations establish a defined intake channel, verify the requester's identity in a manner proportionate to the request, and route requests to the functions that own the relevant data and systems. Clear ownership, tracking against applicable response timelines, and documented handoffs between privacy, legal, and technical teams help ensure requests are handled consistently. The precise process should be aligned to the requirements of the applicable jurisdiction rather than a generic template.
What role does data mapping play in fulfilling these rights?
Fulfilling requests such as access or erasure typically depends on knowing where personal data resides across systems, including copies held in training datasets, backups, logs, and downstream models. Without adequate data mapping and inventory, an organization may be unable to locate all relevant data or to demonstrate that a request was fully actioned. Maintaining current records of data flows is therefore commonly treated as a prerequisite for reliable request fulfillment, though the depth required varies by context.
How do data subject rights interact with AI systems and automated processing?
Where an AI system processes personal data, requests may touch that data used in training, inference, or logging, and some regimes provide specific rights related to automated decision-making. Organizations often need coordination between privacy teams and those responsible for AI governance and model risk management to identify affected systems and assess feasibility of actions such as removing an individual's data. The specific obligations depend on the applicable law and the nature of the processing, so this interaction should be assessed case by case.
What should an organization document to demonstrate it handled a request appropriately?
Common practice is to retain records of the request, the identity verification performed, the systems and data searched, the actions taken or the basis for any refusal, and the date of response. Such documentation supports accountability and can help evidence compliance if challenged. What must be retained, and for how long, depends on the applicable legal regime, and organizations should confirm requirements against the laws that apply to them rather than assume a single standard.
Common misconceptions
Data subject rights are absolute and must always be honored on request.
As commonly defined in data protection regimes, these rights are typically subject to conditions, exemptions, and balancing tests. A request can be lawfully refused or partially fulfilled in defined circumstances, and the applicable exceptions differ across jurisdictions.
An erasure request straightforwardly requires deleting an individual's influence from a trained AI model.
How erasure obligations apply to trained models is an evolving and unsettled area. Deleting a source record is conceptually distinct from removing that data's effect on model parameters, and treating the two as equivalent overstates what is currently established.
Data subject rights and AI governance are the same compliance obligation.
Data subject rights are individual legal entitlements defined under data protection law, while AI governance refers to the organizational structures, policies, and oversight applied to AI systems. Governance processes may help operationalize the handling of rights requests, but the two concepts should not be collapsed.
Best practices
Confirm which data protection regime(s) apply to a given system before defining request-handling procedures, since the specific rights, exceptions, and timelines are jurisdiction-dependent and should not be assumed to be uniform.
Maintain data mapping and records of processing so that access, rectification, and erasure requests can be located and actioned accurately across datasets, pipelines, and any AI training inputs.
Establish a documented, auditable intake and response workflow for rights requests, including identity verification, applicable exemptions, and escalation paths, so decisions to grant or refuse are defensible.
Coordinate rights-handling with model risk management and AI governance functions without conflating them, so that data subject requests affecting model inputs or outputs are routed to the appropriate accountable owners.
Track the evolving treatment of erasure and automated decision-making obligations as they apply to AI systems, and use qualified internal guidance rather than presenting unsettled positions as settled requirements.
Describe controls for handling rights requests as measures that reduce compliance and individual-harm risk, not as guarantees that eliminate it, and document residual limitations explicitly.