GDPR Data Subject Rights

GDPR grants individuals eight rights over their personal data, set out mainly in Articles 15 through 22 (with the right to be informed in Articles 13–14). Organizations must implement processes to honor these rights and respond within one month. Rights failures are among the most common sources of GDPR complaints and enforcement — not because the rights are conceptually hard, but because fulfilling them requires knowing where every scrap of a person's data lives and being able to act on it under deadline.

For a founder or compliance lead, the test is simple: if a user emailed support tomorrow saying "send me everything you have on me, then delete it," could your team produce a complete, accurate response within 30 days without heroics? This lesson covers each right, the operational process behind them, and the hard cases.

The Eight Rights at a Glance

None of these rights is absolute except the marketing objection — each has conditions and exemptions, covered below.

The Rights in Detail

Right to Be Informed (Articles 13–14)

Individuals must be told, in clear and plain language, who you are, what you process, why, on what lawful basis, who receives it, whether it leaves the EEA, how long you keep it, and what rights they have. When you collect data directly, the notice is due at collection. When you obtain data from another source (enrichment vendors, public scraping, referrals), Article 14 requires notice within one month — the requirement that has tripped up data-enrichment businesses in enforcement actions.

Right of Access (Article 15)

The most exercised right. The individual is entitled to confirmation that you process their data, a copy of the personal data itself, and supporting information: purposes, categories, recipients, retention, source, and the existence of automated decision-making. "A copy of their data" means data across all systems — production database, CRM, support desk, analytics, call recordings, email threads, backups policy permitting. It does not mean every document that mentions them; it means their personal data. You may withhold data that would adversely affect others' rights (redact third parties) and protect trade secrets, but you cannot refuse wholesale on that ground.

Right to Rectification (Article 16)

Correct inaccurate data and complete incomplete data without undue delay. Straightforward technically; the compliance obligation is also to notify recipients of the data (Article 19) where feasible.

Right to Erasure (Article 17)

The "right to be forgotten" applies when one of the grounds is met: the data is no longer necessary, consent is withdrawn (and no other basis applies), the person objects and you lack overriding grounds, processing was unlawful, or erasure is legally required. It is not an unconditional delete-everything button. You may retain data needed for legal obligations (tax records, for example), legal claims, or freedom of expression. Best practice: fulfill the erasure, retain the minimum needed under a clearly documented exemption, and tell the individual exactly what was kept and why.

Right to Restriction (Article 18)

A pause button. While an accuracy dispute or objection is being resolved, you store the data but stop otherwise processing it. Systems need a way to flag and suppress records without deleting them.

Right to Data Portability (Article 20)

Applies only to data the individual provided to you, processed by automated means, under consent or contract as the lawful basis. The output must be structured, commonly used, and machine-readable — JSON or CSV is fine. Where technically feasible, transmit it directly to another controller on request. Observed and derived data (your analytics, your scores) fall outside portability, though they may still be covered by access.

Right to Object (Article 21)

Individuals can object to processing based on legitimate interests or public task; you must stop unless you demonstrate compelling legitimate grounds overriding their interests. For direct marketing, the objection is absolute — no balancing, no exceptions, stop immediately and suppress the contact (keep a minimal suppression record so you do not re-add them).

Rights Around Automated Decision-Making (Article 22)

Individuals have the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects — think automated loan denials, algorithmic account terminations, automated hiring rejections. Exceptions exist for contract necessity, legal authorization, and explicit consent, but even then you must offer human intervention and the ability to contest. If your product makes consequential automated decisions, document your Article 22 analysis before a regulator asks for it.

Timelines, Fees, and Verification

• One month from receipt to respond, extendable by two further months for complex or numerous requests — but you must notify the individual of the extension, with reasons, within the first month.
• Free of charge. You may charge a reasonable fee or refuse only for manifestly unfounded or excessive requests (for example, abusive repetition) — and you carry the burden of proving that, so use it sparingly and document the reasoning.
• Verification must be proportionate. For a logged-in user, an in-app request needs little extra verification. Do not demand government ID by default — regulators have criticized excessive ID demands as a rights barrier. Match verification strength to the sensitivity of what is being released.
• No required format for requests. A right exercised in a support chat, a tweet, or a phone call counts. Staff must recognize requests wherever they arrive — you cannot force people through your official form, only encourage it.

Building the DSAR Process

A workable process has five stages:

1. Intake. Offer a clear channel (privacy@ address or in-app form), and train support, sales, and social teams to recognize and route requests received elsewhere. Log every request with its received date — the clock starts then.
2. Verify and triage. Confirm identity proportionately, identify which right(s) are being exercised (one email often bundles access plus erasure), and check whether you are controller or processor for the data in question.
3. Locate the data. This is where unprepared companies fail. Maintain a data map listing every system holding personal data and, for each, how to search and export by identifier. Include shadow systems: spreadsheets, ticketing tools, call recordings, data warehouses.
4. Fulfill. Compile, redact third-party data, apply exemptions with documented reasoning, and deliver securely. For erasure, propagate to processors — Article 17 and your DPAs require you to instruct processors to delete too.
5. Record. Keep a log of the request, dates, actions, exemptions applied, and the response. This log is your accountability evidence and your defense if the individual complains to a supervisory authority.

For companies at any scale, privacy management and compliance automation tools can automate discovery and fulfillment across connected systems — worth evaluating once volume passes a few requests per month.

Common Failure Modes

Reviewing enforcement decisions and complaint statistics, the same patterns recur:

• The invisible request. A rights request arrives in a sales inbox or social DM, nobody recognizes it, and the deadline lapses before privacy ever hears about it. Fix: recognition training plus a routing rule, not a better form.
• The partial response. The team exports the CRM record but forgets the support desk, the analytics warehouse, and the call recordings. The individual notices the gap (they know what they told you) and complains. Fix: fulfillment driven from the data map, with a per-system sign-off.
• The verification wall. Demanding passports for a newsletter unsubscribe-and-delete request. Regulators treat disproportionate verification as obstruction. Fix: tiered verification matched to sensitivity.
• The zombie contact. Data is erased, then the person is re-imported from a marketing list or enrichment vendor three months later and emailed again. Fix: a durable suppression list that survives erasure and is checked on every import.
• The processor short-circuit. A vendor answers your customer's end user directly, or you fulfill an erasure locally but never instruct processors. Fix: propagation steps built into the workflow, and DPA routing clauses your team actually knows about.
• The silent extension. The team quietly takes four months on a complex request without ever sending the extension notice. The lateness is defensible; the silence is not. Fix: a day-20 checkpoint that forces a fulfill-or-notify decision.

None of these are technology problems first — they are process gaps that tooling can then automate away.

DSAR Readiness Checklist

• Data map current, listing every system that stores personal data and how to query it
• Dedicated intake channel published in the privacy notice; requests logged with receipt dates
• Frontline teams trained to recognize rights requests in any channel
• Proportionate identity verification procedure documented
• Export tooling able to produce a complete copy of an individual's data
• Deletion workflow covering production, analytics, backups policy, and processor propagation
• Marketing suppression list that survives erasure requests
• Restriction (freeze) capability in core systems
• Template responses covering fulfillment, extension, and lawful refusal
• Request log maintained with dates, actions, and exemption reasoning
• Deadline tracking with escalation before day 30

Frequently Asked Questions

Do these rights apply to B2B contact data and employees?

Yes. GDPR protects natural persons regardless of context. Your prospect database, your customers' named users, and your own employees all hold these rights. Employee DSARs — often filed during disputes or dismissals — are among the most burdensome because relevant data sprawls across email and HR systems.

What if a request comes to us as a processor?

You do not answer it yourself. Your Article 28 DPA obliges you to forward the request to the relevant controller (your customer) promptly and assist them in fulfilling it. Responding directly to your customer's end users can itself breach your processor obligations. Build a routing procedure and note it in your DPA.

Do we have to delete data from backups?

Regulators accept a pragmatic approach: delete from live systems immediately, ensure backups expire on a defined schedule, and guarantee that restored backups have deletions re-applied (a re-deletion procedure). Tell the individual how backup deletion works. What is not acceptable is using "it's in a backup" as a reason to keep data live indefinitely.

Can we refuse a request from someone acting on another person's behalf?

Agents (lawyers, parents, third-party DSAR services) can submit requests, but you may — and should — verify their authority, such as a signed mandate, before releasing data. For children's data, verify parental responsibility.

What happens if we miss the one-month deadline?

The individual can complain to a supervisory authority, which can investigate, order compliance, and fine you; they can also seek damages in court. Regulators have fined organizations specifically for slow or incomplete DSAR responses. If you realize you will be late, communicate: a documented, good-faith extension notice is vastly better than silence.

How many requests should we expect?

Most B2B SaaS companies see low volumes — a handful per quarter — spiking after breaches, price changes, or press coverage. B2C companies, especially in advertising, dating, fitness, and finance, can see hundreds per month, and organized campaigns or DSAR-as-a-service platforms can multiply volume overnight. Build the process before the spike.

In the next lesson, we will cover the lawful basis for processing — the Article 6 decision that determines which of these rights apply to each of your processing activities.

Handling data subject requests at scale is much easier with the right tooling. AuditXYZ helps you compare compliance automation platforms and find auditors so you can pick the stack that fits your data footprint and budget.