GDPR Data Subject Rights: How to Handle Requests

The General Data Protection Regulation (GDPR) grants individuals — referred to as data subjects — a comprehensive set of rights over their personal data. These rights are codified in Articles 12 through 22 and represent one of the most significant aspects of the regulation. For any organisation that processes the personal data of individuals in the European Economic Area (EEA), understanding and operationalising these rights is not optional — it is a legal requirement with direct enforcement consequences.

When a data subject exercises one of these rights, the resulting communication is known as a data subject request (DSR). Organisations acting as data controllers must respond to DSRs without undue delay and, in any event, within one calendar month. That deadline may be extended by a further two months where requests are complex or numerous, but the data subject must be informed of the extension within the first month.

Failure to handle DSRs correctly is one of the most common sources of GDPR complaints to supervisory authorities — and one of the most avoidable.

Overview of the eight data subject rights

The GDPR establishes eight distinct rights. Some apply universally to all processing activities, while others depend on the lawful basis under which data is processed or the nature of the processing itself. The table below provides a summary before each right is examined in detail.

Right to be informed (Articles 13–14)

The right to be informed is the foundation of GDPR transparency. It requires controllers to provide data subjects with clear, concise information about how their personal data is being processed — before or at the time of collection.

Article 13 applies when data is collected directly from the data subject. Article 14 applies when data is obtained from a third party. The information that must be provided differs slightly between the two scenarios, but both require disclosure of:

• The identity and contact details of the controller and, where applicable, the data protection officer (DPO).
• The purposes of processing and the lawful basis relied upon. Where the lawful basis is legitimate interests, those interests must be specified.
• The recipients or categories of recipients of the personal data, including any transfers to third countries and the safeguards in place.
• The retention period or the criteria used to determine it.
• The existence of each data subject right, including the right to withdraw consent (where consent is the lawful basis) and the right to lodge a complaint with a supervisory authority.
• Whether the provision of data is a statutory or contractual requirement, and the consequences of not providing it (Article 13 only).
• The source of the data and whether it came from publicly accessible sources (Article 14 only).

This information is typically delivered through a privacy notice or privacy policy. The GDPR requires that it be provided in a concise, transparent, intelligible, and easily accessible form, using clear and plain language.

Practical considerations

Many organisations treat privacy notices as a legal formality — dense documents buried in website footers. This is a compliance risk. Supervisory authorities have consistently emphasised that transparency means genuine accessibility, not merely availability. A layered approach — with a short summary up front and detailed information available on request — is widely recognised as best practice.

Right of access (Article 15)

The right of access — often called a subject access request (SAR) — entitles data subjects to obtain confirmation of whether their personal data is being processed and, if so, a copy of that data together with supplementary information about the processing.

The supplementary information mirrors much of what must be disclosed under Articles 13 and 14: purposes, categories of data, recipients, retention periods, the existence of other rights, the source of the data (where not collected directly), and whether automated decision-making is applied.

Controllers must provide the first copy of the data free of charge. For additional copies, a reasonable fee based on administrative costs may be charged. The data must be provided in a commonly used electronic format where the request is made electronically, unless the data subject requests otherwise.

Scope and proportionality

Subject access requests can be broad, spanning multiple systems, databases, and email archives. Controllers are expected to conduct a reasonable search across systems where personal data is likely to be held, but are not required to search every conceivable location if doing so would be disproportionate. Where a request is very broad, the controller may ask the data subject to specify the information or processing activities their request relates to — but this must be a facilitation measure, not a barrier.

Right to rectification (Article 16)

Data subjects have the right to obtain the rectification of inaccurate personal data without undue delay. Where the data is incomplete, considering the purposes of the processing, the data subject has the right to have the data completed — including by providing a supplementary statement.

This right is relatively straightforward to implement. Organisations should have a process for receiving rectification requests, verifying the claimed inaccuracy, updating the relevant records, and notifying any third parties to whom the data has been disclosed (as required by Article 19).

In some cases, whether data is “inaccurate” is not clear-cut — for example, a medical opinion recorded in a healthcare context. Where the accuracy of data is contested, the data subject may instead request restriction of processing (under Article 18) until the matter is resolved.

Right to erasure (Article 17)

The right to erasure — widely known as the “right to be forgotten” — entitles data subjects to request the deletion of their personal data. However, this right is not absolute. It applies only where one of the following grounds is met:

• The data is no longer necessary for the purpose for which it was collected.
• The data subject withdraws consent (where consent was the lawful basis) and there is no other legal ground for processing.
• The data subject objects to processing under Article 21 and there are no overriding legitimate grounds.
• The data has been unlawfully processed.
• The data must be erased to comply with a legal obligation under EU or Member State law.
• The data was collected in relation to the offer of information society services to a child (Article 8).

Even where one of these grounds is met, the controller may refuse erasure if the processing is necessary for one of the exemptions listed in Article 17(3) — including exercising the right of freedom of expression, compliance with a legal obligation, public health purposes, archiving in the public interest, or the establishment, exercise, or defence of legal claims.

Technical erasure versus anonymisation

Supervisory authorities expect controllers to erase data in a meaningful sense — removing it from live systems, backups, and any derived datasets. Where full deletion is technically impracticable (for example, in immutable backup systems), controllers should implement measures to ensure the data is placed beyond use and is deleted at the earliest opportunity when the backup cycle completes. Some organisations choose to anonymise data rather than delete it, which is acceptable provided the anonymisation is irreversible and meets the standard set out in Recital 26.

Right to restriction of processing (Article 18)

The right to restriction allows data subjects to request that their data be stored but not actively processed. This right applies in four specific circumstances:

• The accuracy of the data is contested — restriction applies for a period enabling the controller to verify accuracy.
• The processing is unlawful and the data subject opposes erasure, requesting restriction instead.
• The controller no longer needs the data for the original purpose, but the data subject requires it for the establishment, exercise, or defence of legal claims.
• The data subject has objected to processing under Article 21, and restriction applies pending verification of whether the controller’s legitimate grounds override the data subject’s objection.

When processing is restricted, the data may only be stored. Any other processing requires the data subject’s consent or must be for the establishment, exercise, or defence of legal claims, for the protection of the rights of another person, or for reasons of important public interest.

Controllers must inform the data subject before lifting the restriction.

Right to data portability (Article 20)

The right to data portability allows data subjects to receive a copy of their personal data in a structured, commonly used, and machine-readable format, and to transmit that data to another controller without hindrance.

This right has two important limitations:

1. It applies only where the lawful basis for processing is consent or contract. Data processed on the basis of legitimate interests, legal obligation, or any other lawful basis is not subject to portability.
2. It applies only to processing carried out by automated means. Paper records are excluded.

The data covered by portability is limited to data the data subject has provided to the controller. This includes data actively provided (such as form submissions) and data generated through the data subject’s use of a service (such as activity logs), but does not include data derived or inferred by the controller through analysis.

Where technically feasible, the data subject may request that data be transmitted directly from one controller to another. Controllers are not obliged to adopt or maintain technically compatible systems, but they must not create artificial barriers to transmission.

Recommended formats

While the GDPR does not prescribe specific formats, the European Data Protection Board has endorsed CSV, JSON, and XML as appropriate machine-readable formats. Proprietary formats that require specific software to read are unlikely to satisfy the requirement.

Right to object (Article 21)

The right to object allows data subjects to object to the processing of their personal data where the processing is based on legitimate interests (Article 6(1)(f)) or the performance of a task in the public interest (Article 6(1)(e)), including profiling based on those provisions.

When a data subject objects, the controller must stop processing unless it can demonstrate compelling legitimate grounds that override the interests, rights, and freedoms of the data subject, or the processing is necessary for the establishment, exercise, or defence of legal claims.

Direct marketing

There is one scenario where the right to object is absolute: where personal data is processed for direct marketing purposes. The data subject has an unconditional right to object to direct marketing processing, including any profiling related to direct marketing. No balancing test applies. When an objection to direct marketing is received, processing must cease immediately.

Controllers must bring the right to object to the data subject’s attention explicitly and clearly, separately from any other information, at the latest at the time of first communication with the data subject.

Rights related to automated decision-making (Article 22)

Article 22 provides data subjects with the right not to be subject to a decision based solely on automated processing — including profiling — which produces legal effects or similarly significant effects on them.

This means that where a decision is made entirely by automated means (with no meaningful human involvement) and that decision has a legal effect (such as denial of a credit application) or a similarly significant effect (such as automated rejection of a job application), the data subject has the right to:

• Obtain human intervention from the controller.
• Express their point of view regarding the decision.
• Contest the decision.

The prohibition on solely automated decision-making does not apply where the decision is necessary for the performance of a contract, is authorised by EU or Member State law, or is based on explicit consent. However, even in these cases, the controller must implement suitable safeguards, including the rights listed above.

What counts as meaningful human involvement

Supervisory authorities have clarified that “human involvement” must be genuine and substantive. A process where a human simply rubber-stamps an automated decision does not satisfy the requirement. The human reviewer must have the authority and competence to change the decision and must actually consider all relevant data before reaching a conclusion.

Building a DSR handling process

Having a clear, repeatable process for handling data subject requests is essential. Ad hoc responses increase the risk of missed deadlines, inconsistent decisions, and regulatory complaints. The following framework covers the key stages.

Intake and logging

Establish a centralised intake channel for DSRs. This might be a dedicated email address (such as privacy@organisation.com), a web form, or an integrated privacy management platform. Regardless of the channel, every request should be logged with a unique reference number, the date received, the type of right being exercised, and the identity of the requester.

Organisations should also be prepared to recognise DSRs that arrive through informal channels — a customer email to a support team saying “delete my data” is a valid erasure request, even if it does not use formal language or reference the GDPR.

Identity verification

Before fulfilling a request, the controller must verify that the requester is who they claim to be. The level of verification should be proportionate to the sensitivity of the data and the risk of disclosure to the wrong person.

For existing customers, verification might involve confirming details already held (such as account credentials or answers to security questions). For individuals whose identity cannot be confirmed through existing records, the controller may request a copy of a government-issued identity document. Controllers should avoid requesting excessive documentation — Recital 64 emphasises that verification measures should not lead to the collection of additional personal data beyond what is necessary.

Search and retrieval

Once a request is verified, the controller must conduct a reasonable search across relevant systems to locate the data subject’s personal data. This includes:

• Core databases and CRM systems
• Email and communication archives
• Backup and disaster recovery systems
• Third-party processors operating on the controller’s behalf
• Physical records (where applicable)

Organisations should maintain a record of processing activities (ROPA) under Article 30, which serves as a map of where personal data resides. A well-maintained ROPA significantly accelerates the search phase.

Review and decision

Not every request must be fulfilled in the manner the data subject expects. The review phase involves determining:

• Whether the right applies — for example, a portability request is only valid where the lawful basis is consent or contract.
• Whether an exemption applies — for example, data subject to a legal retention obligation cannot be erased.
• Whether the request is manifestly unfounded or excessive — in which case the controller may charge a reasonable fee or refuse to act.

Decisions to refuse or partially fulfil a request must be documented with clear reasoning. The data subject must be informed of the refusal, the reasons, and their right to lodge a complaint with a supervisory authority or seek a judicial remedy.

Response

Responses must be provided within one calendar month of receipt (or within one month of identity verification, where additional verification was required). The response should:

• Confirm the action taken or explain the reasons for refusal.
• Provide the requested data or information in an accessible format.
• Inform the data subject of their right to lodge a complaint with a supervisory authority.

Where a two-month extension is required, the data subject must be notified within the first month, with an explanation of why the extension is necessary.

Documentation and audit trail

Every DSR should be documented from intake to closure. Records should include the date received, the type of right exercised, the verification steps taken, the systems searched, the decision reached, the date of response, and any communications with the data subject. This documentation serves as evidence of compliance in the event of a supervisory authority investigation or audit.

Common challenges and handling excessive requests

Manifestly unfounded or excessive requests

Article 12(5) allows controllers to charge a reasonable fee or refuse to act where requests are manifestly unfounded or excessive. The burden of proof lies with the controller — you must be able to demonstrate why a request qualifies under this threshold.

Requests are more likely to be considered excessive where the same individual submits repeated, identical requests within a short period with no change in circumstances. Requests are more likely to be considered manifestly unfounded where the data subject has no genuine interest in the data and is using the DSR process to cause disruption.

Controllers should exercise extreme caution before relying on this provision. Supervisory authorities have consistently taken a narrow view of what constitutes “manifestly unfounded or excessive,” and incorrect reliance on this exemption can result in enforcement action.

Third-party data in responses

Subject access requests frequently surface data that relates to multiple individuals — for example, an email thread involving the requester and a third party. Controllers must balance the requester’s right of access against the privacy rights of third parties. Where disclosing the data would adversely affect the rights and freedoms of others, the controller may redact third-party personal data before providing the response.

Requests via authorised agents

Data subjects may appoint a third party — such as a solicitor or advocacy organisation — to submit DSRs on their behalf. Controllers should verify both the identity of the agent and their authority to act, but should not use this as a basis to delay or refuse valid requests.

Summary of all eight rights

Organisations that invest in structured, well-documented DSR processes significantly reduce their regulatory risk and build trust with the individuals whose data they process. The rights themselves are not discretionary — they are enforceable obligations. Building the operational capability to handle them consistently and within statutory timeframes is a core requirement of GDPR compliance.