Implementing Data Subject Rights: Access, Erasure, and Data Portability

TL;DR

The GDPR grants data subjects eight central rights: access, rectification, erasure, restriction, data portability, objection, the right to human decision-making, and the right to withdraw consent.
For most requests, the deadline is one month from receipt. In complex cases, the deadline can be extended by two months, but you must communicate the extension within the first month.
Access requests under Art. 15 are the most frequent and most labor-intensive in practice. You must provide a complete copy of all processed data.
Every data subject right has exceptions and limits. The right to erasure does not apply when statutory retention obligations exist.
A standardized process with clear responsibilities, templates, and deadline tracking is essential once requests come in regularly.

Why Data Subject Rights are not a side issue

Chapter III of the GDPR is devoted entirely to the rights of data subjects. This is no coincidence. The entire regulation is built on the principle that people should retain control over their personal data. Data Subject Rights are the tool with which they exercise that control.

For you as an organization, this means: you need functioning processes to handle data subject requests on time, completely, and correctly. A delayed access request or a denied erasure request without justification can quickly escalate — from a complaint to the supervisory authority to court proceedings.

The good news: once you understand the rights and set up the processes, handling requests can be largely standardized. Most requests fall into a few recurring categories, and for each there is a clear workflow.

Overview: The eight Data Subject Rights

Before we dive deep, here is the full overview of all rights from Chapter III GDPR:

Right	Article	Brief description
Access	Art. 15	Copy of all processed data and information about the processing
Rectification	Art. 16	Correction of inaccurate data
Erasure	Art. 17	Deletion of personal data ("right to be forgotten")
Restriction	Art. 18	Marking data for restricted processing
Data portability	Art. 20	Provision of data in a machine-readable format
Objection	Art. 21	Objection to processing based on legitimate interests
Automated decision	Art. 22	Right not to be subject to a purely automated decision
Withdrawal of consent	Art. 7(3)	Withdrawal of a given consent at any time

Additionally, there is the right to information under Art. 13 and 14, which strictly speaking is not an application right but a duty you must fulfill proactively — for example through privacy notices.

Right of access under Art. 15: The classic

The right of access is the most frequently exercised data subject right. A person has the right to learn from you whether you process their personal data and, if so, what data it is and how you process it.

What you must disclose

Art. 15(1) lists the information you must provide:

The purposes of processing
The categories of personal data
The recipients or categories of recipients to whom the data has been or will be disclosed
The planned retention period or the criteria for determining the retention period
The existence of a right to rectification, erasure, restriction, or objection
The right to lodge a complaint with a supervisory authority
If the data was not collected from the data subject: the source of the data
The existence of automated decision-making including profiling, with meaningful information about the logic and significance

Additionally, under Art. 15(3), you must provide a copy of the personal data being processed. This copy is free of charge. You may only charge a reasonable fee for additional copies.

The access process in practice

Receipt and identity verification. An access request can be made informally: by email, letter, phone, or even verbally. You are not entitled to require a specific form. However, you may and must verify the requester's identity. If you have reasonable doubts about identity, you can request additional information. But do not overdo it: if a customer submits a request via their registered email address, identity is usually sufficiently clear.

Gather data. This is the most labor-intensive step. You must search all systems where personal data of the requesting person might be stored: CRM, email, personnel file, accounting, ticketing systems, log files, backups. Do not forget processors: if an external service provider processes data on your behalf, you must include that data too.

Prepare data. The copy must be complete and understandable. Raw data dumps from a database that only a database administrator can read do not meet the requirement. The data subject must be able to understand what data is stored about them. At the same time, you must ensure that the disclosure does not contain personal data of third parties — unless the rights of those third parties are not affected.

Provide the information. The information must be provided within one month of receiving the request. If the request is complex or you are processing many requests simultaneously, you can extend the deadline by two additional months. However, you must inform the data subject within the first month about the extension and state the reasons.

Limits of the right of access

The right of access is not unlimited. You may refuse access if:

The request is manifestly unfounded or excessive, particularly in cases of frequent repetition (Art. 12(5))
The disclosure would adversely affect the rights and freedoms of other persons (Recital 63)
The request is clearly abusive (e.g., access solely for the purpose of preparing litigation against you)

In these cases, you must justify the refusal and inform the data subject of their right to complain to the supervisory authority.

Right to erasure under Art. 17

The "right to be forgotten" sounds more dramatic than it is in practice. It gives the data subject the right to request the erasure of their personal data when certain conditions are met.

When you must erase

The obligation to erase exists when one of the following grounds applies:

The data is no longer necessary for the purposes for which it was collected
The data subject withdraws consent and there is no other legal basis
The data subject objects under Art. 21 and there are no overriding legitimate grounds
The data was processed unlawfully
Erasure is required to comply with a legal obligation under EU or member state law
The data was collected in relation to information society services offered to a child

When you do not have to erase

Art. 17(3) defines important exceptions where the right to erasure does not apply:

Statutory retention obligations: Commercial and tax retention obligations under HGB and AO take precedence. Your deletion concept regulates the details. You must retain accounting records for ten years, regardless of an erasure request.
Exercise of the right to freedom of expression and information: Freedom of the press prevails.
Reasons of public interest in the area of public health.
Archiving purposes in the public interest, scientific or historical research purposes.
Establishment, exercise, or defense of legal claims: When you need the data to defend yourself in ongoing or foreseeable litigation.

Processing erasure requests correctly

Identity verification: As with access requests, you must ensure the requesting person is actually the data subject.

Check the prerequisites: Does one of the erasure grounds from Art. 17(1) apply? And does none of the exceptions from Art. 17(3) apply?

Implementation: If you must erase, delete the data in all systems — including at processors. Art. 17(2) obliges you to inform recipients to whom you disclosed the data about the erasure request.

Documentation: Log the erasure. What was deleted, when, in which systems, and on what basis? What was not deleted and why (e.g., statutory retention obligations)?

Response: Inform the data subject within one month which data was erased and which was not (with justification).

Right to data portability under Art. 20

The right to data portability is comparatively new and less established in practice than access and erasure. It gives the data subject the right to receive the personal data concerning them in a structured, commonly used, and machine-readable format, and to transmit that data to another controller.

Prerequisites

The right to data portability applies only under certain conditions:

Processing is based on consent (Art. 6(1)(a)) or on a contract (Art. 6(1)(b))
Processing is carried out by automated means
It concerns data that the data subject has provided

This means: data you process on the basis of legitimate interest does not fall under data portability. And data you have generated through your own analysis or evaluation (e.g., a credit scoring result) also need not be provided in a portable format.

What "provided" means

The term "provided" is interpreted broadly according to the Article 29 Working Party. It covers not only data that the person actively entered (name, address, profile information) but also data observed through the use of a service (activity logs, location data, search history). It does not cover derived or calculated data (analysis results, predictions, segment assignments).

Formats and technical implementation

The GDPR does not prescribe a specific format but requires "structured, commonly used, and machine-readable." In practice, the following have become established:

CSV for tabular data (order history, contact data)
JSON for structured data with hierarchies
XML for complex data structures
PDF is, according to the prevailing opinion, not sufficiently machine-readable for data portability

The data subject can also request that you transmit the data directly to another controller, "where technically feasible" (Art. 20(2)). In practice, direct transmission often fails due to a lack of standardized interfaces between controllers.

Rectification under Art. 16

The right to rectification is conceptually the simplest data subject right but underestimated in implementation. The data subject has the right to obtain without undue delay the rectification of inaccurate personal data concerning them. They also have the right to have incomplete data completed.

Typical cases: Incorrect name after marriage, outdated address, wrong date of birth, erroneous contract data, incomplete contact information.

Challenge in practice: You must carry out the rectification in all systems where the incorrect data is stored. And you must inform the recipients to whom you disclosed the data about the rectification (Art. 19). This can be complex in distributed IT landscapes.

Restriction of processing under Art. 18

The right to restriction is the "moratorium" among Data Subject Rights. It allows the data subject to temporarily restrict the processing of their data while certain questions are being resolved.

When restriction applies

The data subject contests the accuracy of the data: restriction for the duration of the review
The processing is unlawful but the data subject wants restriction instead of erasure
You no longer need the data but the data subject needs it for the establishment of legal claims
The data subject has objected under Art. 21: restriction for the duration of the review of whether your legitimate grounds override theirs

Technical implementation

Restricted data may only be stored. Any other processing (use, transmission, analysis) is only permitted with the data subject's consent or for the establishment of legal claims. Technically, you typically implement this through a flag in the database that ensures the restricted records are excluded from regular processing workflows.

Right to object under Art. 21

The right to object is tied to a specific legal basis: it applies to processing based on legitimate interests (Art. 6(1)(f)) or on public interest (Art. 6(1)(e)).

When a data subject objects, you may no longer process the data unless you can demonstrate "compelling legitimate grounds for the processing which override the interests, rights and freedoms of the data subject." The burden of proof lies with you.

Special case — direct marketing: When the objection targets processing for direct marketing purposes, there is no balancing of interests. The objection is always effective, without ifs or buts (Art. 21(2) and (3)). You must immediately cease processing for direct marketing purposes.

Automated individual decisions under Art. 22

Art. 22 gives data subjects the right not to be subject to a decision based solely on automated processing which produces legal effects concerning them or similarly significantly affects them.

Examples: Automatic rejection of an online credit application, algorithmic applicant pre-screening without human review, automated cancellation of insurance based on risk scoring.

Exceptions: Automated decisions are permissible if they are necessary for entering into or performing a contract, if they are authorized by law, or if the data subject has given explicit consent. In any case, you must implement appropriate safeguards for the data subject, including the right to human intervention, to express their point of view, and to contest the decision.

The handling process: From request to response

Regardless of which right is being exercised, handling follows a uniform basic process:

Phase 1: Receipt and categorization (Day 0)

The request arrives. You document the receipt date (the deadline starts running now), identify the right being exercised, and forward the request to the responsible party. In smaller companies, this is often the Data Protection Officer or management directly. In larger organizations, there is ideally a central mailbox or ticket system for data subject requests.

Phase 2: Identity verification (Day 1 to 5)

Verify whether the requesting person is actually the data subject. If there are reasonable doubts, you can request additional information — but the deadline keeps running. Tip: Define in advance which identity proofs you accept in which situations. A customer writing via their registered account does not need to provide additional identification.

Phase 3: Substantive processing (Day 5 to 20)

This is where the actual work happens: gathering data (access), correcting data (rectification), conducting the erasure review (erasure), creating the export (data portability). Involve all departments that might hold relevant data: IT, HR, accounting, sales, customer service.

Phase 4: Quality review (Day 20 to 25)

Before sending the response, a second person (ideally the DPO) reviews completeness and accuracy. Have all systems been searched? Are the exceptions correctly applied? Are the rights of third parties preserved?

Phase 5: Response (Day 25 to 30)

Send the response to the data subject. The response must be written in clear, simple language (Art. 12(1)). Inform the person of their right to complain to the supervisory authority. Document the response and all steps of the handling process.

Deadlines and extensions

The basic deadline is one month from receipt of the request. "Month" here means a calendar month: a request received on March 15 must be answered by April 15.

For complex requests or a high volume of simultaneous requests, you can extend the deadline by two additional months. Prerequisites:

You inform the data subject within the first month about the extension
You state the reasons for the delay
You inform about the right to complain to the supervisory authority

In practice, you should not use the extension lightly. A routine access request from a single customer does not justify an extension. An access request from a former employee who worked in various departments for ten years and whose data is scattered across dozens of systems, however, does.

Organizational prerequisites

Clarify responsibilities

Define who in your organization is responsible for handling data subject requests. In smaller companies, the Data Protection Officer often takes on this role. In larger organizations, a data protection team or at least designated contacts in each department who assist with data gathering is recommended.

Maintain data mapping

You can only fully answer an access request if you know where all personal data is stored. Your records of processing activities under Art. 30 GDPR is the foundation. Supplement it with a data map that lists the systems and data sources involved for each processing activity.

Create templates

Create response templates for the most common requests: access response, erasure confirmation, rejection notice with justification, extension notification. Templates save time and ensure you do not forget mandatory information.

Maintain a deadline calendar

Set up a system that reminds you of expiring deadlines. ISMS Lite offers integrated deadline management for data subject requests that automatically reminds you of approaching deadlines and documents the processing status. A missed deadline is not just a compliance violation but gives the data subject a concrete reason to complain to the supervisory authority.

Common practical problems

Mass requests: Some individuals submit monthly access requests to put pressure on a company. Art. 12(5) GDPR allows you to refuse manifestly unfounded or excessive requests or to charge a reasonable fee. However, the burden of proof for excessiveness lies with you.

Requests through attorneys: Data subjects can also exercise their rights through an authorized representative. In this case, request a power of attorney and verify its authenticity.

Data in backups: Must you also clean up backups for an erasure request? The prevailing opinion is: yes, in principle. In practice, this is technically complex with incremental backups. A pragmatic approach: document that the data was deleted in the production system and that the backups follow a defined deletion cycle, after which the data will no longer be present there either.

Data at processors: You are responsible, not the processor. When you receive an erasure request, you must ensure that the processor also deletes the data. Your data processing agreement (DPA) should contain corresponding provisions.

Conflicting obligations: A customer requests the erasure of their data, but you must retain invoices for ten years. Solution: delete all data not subject to a retention obligation and inform the customer which data you continue to store on what legal basis.

Penalties for violations

Violations of Data Subject Rights are sanctioned under Art. 83(5)(b) GDPR with the higher fine category: up to 20 million euros or 4% of worldwide annual turnover. A data breach not reported on time can also be sanctioned at this level. In practice, supervisory authorities regularly impose fines for late or incomplete access responses. Even for smaller companies, amounts can reach five figures.

At least equally relevant is the reputational damage. Data subjects who cannot enforce their rights complain not only to the supervisory authority but also publicly. Negative media coverage about data protection violations can be more damaging to business than any fine.