GDPR data subject rights: what they are and how to handle them

A GDPR request in your inbox. What now?

A customer emails: "I want to know what data you have about me." Or a former employee writes: "Delete all my personal data." Or a job applicant asks: "Send me a copy of everything you hold on me."

These are GDPR data subject requests. And the chance that you will receive one is growing. People are increasingly aware of their rights. The question is: do you know how to handle them?

In this article, we cover all data subject rights under GDPR, with practical guidance for each right on what to do when someone invokes it.

Why data subject rights matter in practice

The rights of data subjects are set out in GDPR (Articles 15 through 22). They give individuals control over their personal data. And they place the obligation on you to handle that properly.

In practice, that means:

• Recognising requests when they come in (they are not always neatly labelled as "GDPR request")
• Responding on time (within one month)
• Documenting what you have done
• Knowing internally who handles this

Having a process matters. The first problem is usually a damaged customer relationship, not a regulatory one. A request that gets ignored or handled badly erodes trust fast.

Let us walk through the rights one by one.

Right of access: what can someone request and how do you respond?

Someone asks which personal data you process about them, and wants a copy. This is the most common GDPR request.

How to handle it: confirm receipt, verify the identity of the requester (more on this shortly), and collect all personal data you hold on this person. Think about your CRM, HR system, email, cloud storage, and potentially your suppliers. Then send an overview in a clear format: what data you hold, why you process it, who you share it with, and how long you retain it.

The deadline: one month from receipt.

More background: right of access (FAQ).

Right to rectification: when and how do you correct data?

Someone indicates that the data you hold is inaccurate or incomplete, and asks for correction.

Check whether the claim is valid, update the data in all systems where it appears, and inform any third parties you have shared the incorrect data with.

An example: a customer moves house and reports that the old address is still in your system. You correct it in your CRM, billing system, and potentially at your accountant.

This is often the most straightforward request. But do not forget to pass the correction to your suppliers if they also process that data.

Right to erasure ("right to be forgotten")

Someone asks you to delete all their personal data. This right is not absolute, but you must take it seriously.

You must delete when:

• The data is no longer necessary for its original purpose
• The individual withdraws consent (and there is no other legal basis)
• The individual objects and there is no overriding legitimate interest to continue
• The data was processed unlawfully

But you may also refuse, for example when:

• You have a legal retention obligation (tax records, for instance)
• The data is needed for an ongoing legal dispute
• There is another legitimate interest that outweighs the request

Good to know: deleting and anonymising are not the same thing. With deletion, the data is gone. With anonymisation, you make the data impossible to trace back to an individual. Anonymised data is no longer subject to GDPR and may be retained for statistics or analysis.

More background: right to erasure (FAQ).

Right to restriction of processing

The data subject asks you to temporarily stop processing their data. Not delete it, but "freeze" it.

This applies when:

• The accuracy of the data is contested (while you are investigating)
• The processing is unlawful, but the individual does not want deletion
• You no longer need the data, but the individual does (for a legal claim)
• The individual has objected and you are still assessing whether you have an overriding interest

In practice, this means: mark the data as "restricted" and stop using it until the situation is resolved. The data may still be stored.

More background: right to restriction of processing (FAQ).

Right to data portability

The data subject asks to receive their personal data in a structured, commonly used, and machine-readable format, so they can transfer it to another service provider.

This applies when the processing is based on consent or a contract, and the processing is carried out by automated means (so digital, not on paper).

What you deliver: a file (CSV, JSON, XML) with the personal data the individual provided themselves. You do not need to include analyses or derived data.

An example: a user of your platform wants to switch to a competitor and asks for an export of their account details and stored data.

More background: right to data portability (FAQ).

Right to object

The data subject objects to a specific processing of their data. This right applies mainly when you process on the basis of legitimate interest or a task in the public interest.

Stop the processing, unless you can demonstrate a compelling reason that overrides the individual's interests. For direct marketing, there is no discussion: always stop, without exception.

An example: a customer objects to their purchase history being used for personalised marketing. If you cannot demonstrate a compelling interest, you stop.

More background: right to object (FAQ).

How to set up an internal process for GDPR requests

Knowing the rights is step one. Having a working process is step two. Here is a blueprint:

1. Choose a point of contact

Who receives GDPR requests? That could be a privacy officer, but at an SMB it is often the director, HR manager, or office manager. Pick someone and communicate it internally and externally (through your privacy statement).

2. Verify identity

You need to check that the requester really is who they say they are. But do not overdo it. Asking for a copy of their passport for every request is disproportionate.

Rules of thumb:

• If the request comes from an email address you already know for this person, that is usually sufficient
• When in doubt: ask for verification through a channel you already use with that person
• Never ask for more identification than necessary

3. Register the request

Record: date received, type of request, name of requester, and deadline for response. This is your proof that you take it seriously.

4. Collect the data

Search all systems where personal data of this person could be stored. Do not forget: also at your suppliers and in your email.

5. Respond within the deadline

One month from receipt. For complex requests, you may extend by two months, but you must let the requester know within the first month that you are extending and why.

6. Document the outcome

Record what you did, when, and what the result was. This is the dossier you can present during an audit.

Common mistakes when handling requests

"That request is probably not serious." Treat every request as if it is serious. Ignoring one is the fastest route to a complaint with the supervisory authority.

No central overview. If requests come in through three different mailboxes and nobody tracks whether they have been handled, something will go wrong. Guaranteed.

Too much identity verification. Asking for a copy of their passport is disproportionate in most cases. Keep it simple.

Missing the deadline. One month sounds like a lot, but if you only pick up the request after two weeks and then need to search all your systems, things get tight. Set a reminder at receipt.

Forgetting to include suppliers. If a customer asks for deletion, you also need to pass that on to the parties that process data on your behalf. It is not done if you only delete it in your own CRM.

Practical example: an employee leaves the company and requests deletion of all personal data. You delete the data from the HR system, but then you need to check: what are you keeping because of tax retention obligations? What is still at the payroll administrator? And what about email backups? Go through all systems, document what you do and do not delete (with reasons), and communicate this clearly to the former employee.

From individual requests to a working system

GDPR requests are not a theoretical scenario. They come from customers, employees, applicants, and sometimes even website visitors. And the difference between a professional response and a chaotic one is almost always the same thing: an internal process that everyone knows about.

Start simple. Choose a point of contact, create a registration template, and practise once with a fictional request. The rest follows naturally when you start doing it in practice.

Also check out the Record of Processing Activities (RoPA) in ComplianceHive to see how you can link requests to your processing overview.

ComplianceHive helps you keep your GDPR documentation in order: processing register, vendor management, and privacy records in one overview. Start free.