GDPR Data Subject Rights
Detailed reference for implementing GDPR data subject rights: access, rectification, erasure, restriction, portability, objection, and automated decision-making rights. Covers process design for handling DSARs at scale, response timelines, and exemptions.
- 1
GDPR establishes eight distinct data subject rights under Articles 12-22, each with specific conditions, exemptions, and operational requirements that demand structured implementation.
- 2
The one-month response deadline under Article 12(3) is extendable by two months for complex requests, but the data subject must be informed of the extension and its reasons within the initial one-month period.
- 3
The right to erasure is subject to significant exceptions — legal obligations, legal claims, public health, and freedom of expression can all override an erasure request.
- 4
Automated decision-making under Article 22 intersects with the EU AI Act, creating layered obligations that require unified governance for organisations deploying AI systems.
- 5
Scaling DSAR handling requires centralised intake, structured triage, data discovery tooling, and workflow automation — treating each request as an ad hoc project is unsustainable.
1. Overview of Data Subject Rights Under GDPR
Chapter III of the GDPR (Articles 12-22) establishes a comprehensive set of rights that empower individuals to control how their personal data is processed. These rights are not theoretical entitlements — they impose concrete operational obligations on controllers, with defined timelines, format requirements, and limited grounds for refusal. The rights framework comprises: the right to transparent information and communication (Article 12), the right of access (Article 15), the right to rectification (Article 16), the right to erasure or 'right to be forgotten' (Article 17), the right to restriction of processing (Article 18), the notification obligation regarding rectification, erasure, or restriction (Article 19), the right to data portability (Article 20), the right to object (Article 21), and rights related to automated decision-making and profiling (Article 22).
Article 12 functions as the procedural backbone for all data subject rights. It requires controllers to provide information and communications relating to data processing in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. Requests must be acted upon without undue delay and in any event within one month of receipt, extendable by a further two months where requests are complex or numerous (with notification to the data subject within the initial one-month period explaining the delay). The exercise of rights must be provided free of charge, though a reasonable fee may be charged for manifestly unfounded or excessive requests.
Implementing data subject rights is not merely a legal compliance exercise — it is an operational capability that requires cross-functional coordination between legal, IT, customer service, and data management teams. Organisations that treat DSARs as exceptional events handled by the legal department on a case-by-case basis will struggle as request volumes increase. The organisations that handle data subject rights effectively are those that have invested in structured processes, trained frontline staff, and built the technical infrastructure to locate, retrieve, and manage personal data across their systems.
Data subject rights are not absolute. Most rights include specific conditions or exemptions. The right to erasure, for example, does not apply where processing is necessary for compliance with a legal obligation or for the establishment, exercise, or defence of legal claims. Understanding both the right and its limitations is essential for correct implementation.
2. Right of Access (Article 15)
The right of access under Article 15 is the most frequently exercised data subject right and the one most likely to expose weaknesses in an organisation's data management practices. Data subjects have the right to obtain confirmation as to whether personal data concerning them is being processed, and, where that is the case, access to the personal data together with specified information: the purposes of processing, the categories of personal data concerned, the recipients or categories of recipients, the envisaged retention period, the existence of rights to rectification, erasure, restriction, and objection, the right to lodge a complaint with a supervisory authority, the source of the data where it was not collected from the data subject, and the existence of automated decision-making including profiling.
The controller must provide a copy of the personal data undergoing processing in a commonly used electronic form where the request is made electronically, unless the data subject requests otherwise. This obligation extends to all personal data held about the individual across all systems — CRM, HR, email, backups, logs, and any other data stores. The scope challenge is significant: organisations that have not maintained a comprehensive record of processing activities (Article 30) will struggle to identify all locations where an individual's personal data may reside. Invest in data mapping and discovery tooling that enables systematic identification of personal data across your technology estate.
Supervisory authorities have issued substantial fines for inadequate access request responses. Common failings include: providing incomplete data (omitting data held in backup systems, email archives, or third-party processors), exceeding the one-month response deadline without valid justification for extension, providing data in unusable formats, and failing to verify the identity of the requester before disclosing data. On identity verification, Article 12(6) permits the controller to request additional information necessary to confirm the data subject's identity where there are reasonable doubts — but identity verification must be proportionate and must not be used as a mechanism to obstruct the exercise of rights.
3. Right to Rectification (Article 16) and Erasure (Article 17)
The right to rectification under Article 16 is straightforward in concept but demanding in execution: data subjects have the right to obtain the rectification of inaccurate personal data without undue delay, and to have incomplete personal data completed. Operationally, this requires the ability to identify all instances of the inaccurate data across your systems, correct them consistently, and notify any recipients to whom the data was disclosed (Article 19). Where personal data has been shared with third parties — processors, joint controllers, or recipients under a legal basis — the controller must communicate the rectification to each recipient unless this proves impossible or involves disproportionate effort.
The right to erasure (Article 17), commonly known as the 'right to be forgotten,' is more complex. It applies in six defined circumstances: where the personal data is no longer necessary for its original purpose, where the data subject withdraws consent and no other legal basis applies, where the data subject objects under Article 21 and no overriding legitimate grounds exist, where the data was unlawfully processed, where erasure is required by EU or Member State law, and where the data was collected in relation to the offer of information society services to a child. However, the right to erasure is subject to significant exceptions under Article 17(3): it does not apply where processing is necessary for freedom of expression and information, compliance with a legal obligation, public health purposes, archiving in the public interest, or the establishment, exercise, or defence of legal claims.
Implementing erasure at scale requires a technical capability that many organisations underestimate. Personal data may reside in production databases, backup tapes, log files, analytics platforms, email systems, document management systems, and third-party processor environments. True erasure means removing the data from all these locations — or, where complete erasure is technically infeasible (e.g., immutable backup archives), implementing measures that prevent the data from being restored to production systems and documenting the residual retention with a justification. Establish a clear erasure methodology that defines what 'erasure' means in each system context, the verification process for confirming erasure, and the timeline for completing erasure across all data stores.
Maintain a lookup table mapping each data system to its erasure method and timeline. Production databases may support immediate deletion, while backup systems may require retention until the next rotation cycle. Document these variations in your DSAR procedures so response teams can set accurate expectations with data subjects.
4. Portability (Article 20), Restriction (Article 18), and Objection (Article 21)
The right to data portability under Article 20 enables data subjects to receive their personal data in a structured, commonly used, and machine-readable format and to transmit that data to another controller without hindrance. This right applies only where processing is based on consent (Article 6(1)(a) or Article 9(2)(a)) or contractual necessity (Article 6(1)(b)), and the processing is carried out by automated means. The data that must be provided is limited to personal data that the data subject has 'provided to' the controller — which, per the Article 29 Working Party's guidelines (now endorsed by the EDPB), includes both actively provided data (form submissions, uploaded content) and observed data (usage history, activity logs), but not inferred or derived data (credit scores, analytics profiles).
The right to restriction of processing under Article 18 is an interim measure that applies in four situations: where the data subject contests the accuracy of the data (restriction during verification), where processing is unlawful but the data subject opposes erasure, where the controller no longer needs the data but the data subject requires it for legal claims, and where the data subject has objected under Article 21 pending verification of overriding grounds. When restriction is in effect, the controller may store the data but may not otherwise process it except with the data subject's consent, for legal claims, for the protection of rights of another person, or for important public interest reasons. Technically, this requires the ability to flag data as restricted and enforce the restriction across all processing systems — a non-trivial capability in complex data architectures.
The right to object under Article 21 has two distinct branches. Article 21(1) provides a general right to object to processing based on legitimate interests (Article 6(1)(f)) or public interest (Article 6(1)(e)), requiring the controller to cease processing unless it demonstrates compelling legitimate grounds that override the data subject's interests, rights, and freedoms. Article 21(2) provides an unconditional right to object to processing for direct marketing purposes — where this right is exercised, the personal data must no longer be processed for direct marketing. The direct marketing objection right is absolute and admits no balancing test or override. Ensure your marketing systems can implement opt-outs immediately and comprehensively across all channels.
5. Automated Decision-Making and Profiling (Article 22)
Article 22 addresses a concern that has grown more pressing with the proliferation of AI and machine learning systems: the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning the data subject or similarly significantly affects them. This right applies where three cumulative conditions are met: there is a decision, the decision is based solely on automated processing (no meaningful human involvement), and the decision produces legal effects or similarly significant effects on the individual. Credit decisions, automated insurance underwriting, algorithmic hiring screening, and automated content moderation affecting access to services are classic examples.
The right under Article 22(1) is structured as a prohibition with exceptions: solely automated decisions with legal or similarly significant effects are prohibited unless they are necessary for a contract, authorised by EU or Member State law, or based on explicit consent. Where an exception applies, the controller must implement suitable measures to safeguard the data subject's rights and freedoms, including at least the right to obtain human intervention, to express their point of view, and to contest the decision (Article 22(3)). The requirement for 'meaningful' human intervention is critical — a human reviewer who rubber-stamps algorithmic outputs without genuine evaluative authority does not constitute meaningful human involvement.
The interaction between Article 22 and the EU AI Act (Regulation 2024/1689) creates a layered regulatory framework for automated decision-making. While GDPR Article 22 focuses on the individual's right regarding specific decisions, the AI Act imposes systemic obligations on high-risk AI systems used for decisions in employment, credit, essential services, and other domains listed in Annex III. Organisations deploying AI systems that make or support decisions about individuals must comply with both frameworks: GDPR Article 22 for the individual rights dimension, and the AI Act for the system-level requirements including risk management, data governance, transparency, and human oversight. A unified governance approach that addresses both frameworks simultaneously is more efficient and more effective than parallel compliance workstreams.
A human reviewer who merely confirms algorithmic outputs without genuine authority to override does not satisfy the 'meaningful human intervention' requirement. Supervisory authorities assess whether the human involvement is substantive, not merely procedural.
6. Process Design for Handling DSARs at Scale
Handling data subject access requests at scale requires a structured intake, triage, and fulfilment process supported by appropriate technology. The intake process should provide multiple submission channels (web form, email, in-app, postal) while routing all requests to a central queue managed by the privacy team. Each request should be logged with a unique identifier, timestamp, the specific right(s) being exercised, and the data subject's identity verification status. Automated acknowledgement within 24-48 hours sets expectations and confirms receipt, while internal SLAs should target completion well within the statutory one-month deadline to accommodate review cycles and edge cases.
Triage is where operational efficiency is determined. Classify each request by type (access, erasure, portability, objection, etc.), complexity (standard vs. complex requiring extension), and scope (single system vs. multi-system). Standard access requests where the individual is an authenticated user with a limited data footprint can follow an expedited path with pre-built data export routines. Complex requests — those involving large data volumes, multiple systems, third-party processors, or requiring legal review of exemptions — should be flagged early for the two-month extension procedure under Article 12(3), with the data subject notified within the first month.
Invest in tooling that reduces manual effort in the fulfilment phase. Data discovery and mapping tools that can locate an individual's personal data across databases, file systems, email, and SaaS applications dramatically reduce the time spent on the most labour-intensive part of the process. Automated redaction tools help when access request responses require removal of third-party personal data. Workflow automation ensures deadline tracking, escalation, and audit trail creation happen without relying on individual memory. The goal is a repeatable, auditable process that delivers consistent quality regardless of the team member handling the request — because supervisory authorities assess systematic compliance, not individual heroics.
Track DSAR metrics — volume, type distribution, average response time, extension rate, and refusal rate. These metrics inform resource planning and identify process bottlenecks before they result in missed deadlines.
Can we charge a fee for responding to data subject requests?
Article 12(5) establishes that information and actions taken under Articles 15-22 must be provided free of charge. However, where requests are manifestly unfounded or excessive, particularly if repetitive, the controller may either charge a reasonable fee taking into account the administrative costs, or refuse to act on the request. The burden of demonstrating that a request is manifestly unfounded or excessive lies with the controller. In practice, charging fees is rare and risky — supervisory authorities scrutinise fee decisions closely. For the right of access specifically, a reasonable fee may be charged for additional copies beyond the first, but the first copy must be free.
How do we verify the identity of the person making a DSAR?
Article 12(6) allows controllers to request additional information necessary to confirm the identity of a data subject, but only where there are reasonable doubts about identity. The verification measures must be proportionate to the risk — requesting a notarised affidavit for a simple access request is disproportionate. Where the data subject is an authenticated user (logged into their account), their authenticated session may provide sufficient verification. For requests received via email or post, matching against existing account information (email address, account number, date of birth) is usually proportionate. Do not request more personal data for verification than you already hold about the individual.
What is the difference between erasure and anonymisation?
Erasure under Article 17 requires the destruction or permanent removal of personal data such that it can no longer be associated with an identified or identifiable person. Anonymisation is a technique that irreversibly transforms personal data so that the data subject is no longer identifiable, directly or indirectly — once data is truly anonymised, it falls outside GDPR scope entirely (Recital 26). In practice, some organisations satisfy erasure requests through irreversible anonymisation rather than physical deletion, particularly where aggregate data has analytical or statistical value. This approach is permissible provided the anonymisation is truly irreversible — pseudonymisation, which retains the possibility of re-identification using additional information, does not satisfy an erasure request.
Can we refuse a data subject request, and on what grounds?
Yes, but only in limited circumstances. Article 12(5) permits refusal where a request is manifestly unfounded or excessive. Each specific right also includes its own conditions and exemptions — for example, the right to erasure under Article 17(3) does not apply where processing is necessary for legal obligations or legal claims. Where you refuse a request, Article 12(4) requires you to inform the data subject without delay and within one month of the reasons for not taking action, and of the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy. Document the refusal rationale thoroughly in your DSAR register — a refusal without adequate justification is treated as non-compliance with the relevant right.
How does the right to data portability work in practice?
The data subject can request their personal data in a structured, commonly used, and machine-readable format — JSON, CSV, and XML are commonly accepted formats. The right applies only to data processed on the basis of consent or contract, and only to data the data subject 'provided to' the controller (including observed data like usage logs, but excluding inferred or derived data). Where technically feasible, the data subject may also request direct transmission to another controller (Article 20(2)). Build portability export functionality into your application, ideally as a self-service feature that generates a downloadable data package. This reduces manual processing burden and demonstrates proactive compliance.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.