Data subject rights are not aspirational commitments — they are legally enforceable entitlements with statutory deadlines, mandatory response formats, and prescribed exemption criteria. An organisation that has documented lawful bases, published privacy notices, and built a consent management platform but has no operational procedure for responding to rights requests has left one of the most visible and frequently tested aspects of GDPR compliance unaddressed.
Rights request management is also the area where DPA enforcement actions are most directly triggered by individual data subjects. A single unanswered subject access request can generate a DPA complaint. A complaint generates an investigation. An investigation typically finds that a systemic failure exists, not a one-off error. Building rights fulfilment procedures that consistently deliver within the one-month deadline — with complete, accurate responses and documented exemption decisions — is a basic operational requirement of GDPR compliance.
Overview of Data Subject Rights
GDPR DATA SUBJECT RIGHTS — SUMMARY TABLE
| Right | Article | What It Entitles the Data Subject to | Key Condition or Limitation |
|---|---|---|---|
| Right of access (SAR) | 15 | A copy of personal data held; processing purposes; recipients; retention periods; rights summary; source of data (if indirect) | Cannot adversely affect rights and freedoms of others; commercial confidentiality may limit scope |
| Right to rectification | 16 | Correction of inaccurate personal data; completion of incomplete data | Only applies to factually inaccurate data; opinions and assessments are not subject to rectification |
| Right to erasure (‘right to be forgotten’) | 17 | Deletion of personal data in specified circumstances | Subject to retention obligations, legal claims, public interest, and other grounds; not absolute |
| Right to restriction | 18 | Suspension of processing (but not deletion) while accuracy is contested, objection is assessed, or processing is unlawful but erasure is refused | Data can be stored but not otherwise processed during restriction |
| Right to data portability | 20 | Receive personal data provided to the controller in a structured, commonly used, machine-readable format; transmit to another controller | Only applies to consent or contract basis; only to data the subject provided; not to derived data |
| Right to object | 21 | Stop processing based on legitimate interests or direct marketing at any time | Legitimate interests objection can be overridden by compelling legitimate grounds; direct marketing objection is absolute |
| Rights re automated decisions | 22 | Not to be subject to solely automated decisions with significant effects; human review; explanation; contest | Exceptions for contract necessity, legal authorisation, explicit consent |
Building the SAR Fulfilment Procedure
The subject access request is the most frequently exercised right and the most operationally demanding to fulfil. A complete SAR response requires: identifying all personal data held about the requester across all systems; applying any exemptions; compiling the response; redacting third-party data that would be disclosed; and delivering everything within one month (extendable to three months for complex requests).
SAR FULFILMENT WORKFLOW — STAGE BY STAGE
| Stage | Activity | Responsible | Deadline from Receipt |
|---|---|---|---|
| 1. Intake | Receive request through any channel (email, form, in-person, social media, verbal); log with reference number; assign to handler; send acknowledgement | Privacy team / Customer service | Day 1–2 |
| 2. Identity verification | Verify requester identity if reasonable doubt; request ID only proportionate to the data at risk; do not delay clock pending response if identity clear | Privacy team | Day 1–3 |
| 3. Clarification (if needed) | Where request is unclear or very broad, ask for clarification to locate data; clock pauses only during the clarification wait period | Privacy team | Day 3–5 |
| 4. System search | Search all identified personal data systems; compile list of all data held about the requester; include archived, backup, and processor-held data | Privacy team + IT + all data-holding departments | Days 5–20 |
| 5. Exemption review | Assess each data element for applicable exemptions; document exemption applied; prepare redactions for third-party personal data | Privacy team / Legal | Days 15–25 |
| 6. Response compilation | Compile final data package; draft covering letter explaining what is included, what is excluded and why, rights and complaints route | Privacy team | Days 22–28 |
| 7. Delivery and logging | Deliver securely (encrypted email, password-protected file, secure portal); update log with completion; file exemption decisions | Privacy team | By Day 30 |
| IMPORTANT | The one-month deadline runs from the day after the request is received, regardless of whether it arrives on a Friday or the eve of a public holiday. Where a request requires extension (up to three months total for complex or numerous requests), the extension must be notified to the data subject within the original one-month period, with reasons. Failure to notify within one month — even if the response eventually arrives — is a procedural violation. |
SAR Exemptions: What Can Be Withheld
Not all personal data must be disclosed in response to a SAR. GDPR Article 15 and national implementing legislation provide exemptions that allow controllers to withhold data in specific circumstances. Every exemption decision must be documented — ‘we don’t disclose this because it’s commercially sensitive’ is not sufficient. The specific exemption relied on, the category of data it applies to, and the reasoning must be recorded.
COMMON SAR EXEMPTIONS
| Exemption | When It Applies | Documentation Required |
|---|---|---|
| Third-party personal data | Disclosing the data would reveal personal data about a third party who has not consented to disclosure | Note the data redacted; confirm redaction was applied to protect third-party identity, not controller’s interests |
| Legal professional privilege | Data consists of legal advice from a lawyer or legal correspondence subject to privilege (varies by member state) | Confirm privilege; describe the category of data withheld; note legal basis for withholding |
| Management forecasting / negotiations (UK) | Disclosure would prejudice planned business changes, negotiations, or management decisions (UK-specific exemption) | Describe the prejudice that would result; this exemption is time-limited until decision is made |
| Regulatory / law enforcement investigations | Disclosing data could prejudice a criminal investigation or regulatory process | Confirm investigation context; note that exemption applies only to the extent of the prejudice |
| Disproportionate effort for Art. 14 data | Providing information would involve disproportionate effort (Art. 14 indirect collection exemption) | Document why effort is disproportionate; provide general notice as alternative where possible |
| Confidential references (UK) | References given in confidence for employment, education, or public appointment purposes | Note that reference exists; do not disclose content; confirm exemption applies |
Erasure Requests: Navigating the Conditions and Exemptions
The right to erasure in Article 17 is frequently misunderstood as an absolute right to deletion on demand. It is not. It applies in specific circumstances — when the data is no longer necessary, consent is withdrawn and there is no other basis, a valid objection is upheld, or processing was unlawful — and it is subject to exemptions that allow continued retention for legal claims, compliance with legal obligations, public interest archiving, and other grounds.
ERASURE REQUEST DECISION FRAMEWORK
| Step | Question | If Yes | If No |
|---|---|---|---|
| 1 | Does one of the Art. 17(1) grounds apply? (no longer necessary; consent withdrawn; valid objection; unlawful processing; legal obligation to erase) | Erasure obligation exists — proceed to step 2 | No erasure obligation under Art. 17; inform data subject |
| 2 | Does an Art. 17(3) exemption apply? (legal obligation; legal claims; public interest; research; freedom of expression) | Erasure may be refused or limited to the extent of the exemption; document reasoning | Proceed to erasure |
| 3 | Has data been shared with processors or other controllers? | Notify processors and controllers who received the data; request erasure or restriction from them | Proceed with internal erasure only |
| 4 | Is the data in backup systems? | Erase from live systems immediately; flag backups for deletion at next rotation; document the approach | Complete erasure and log it |
Objection to Processing: Direct Marketing vs. Legitimate Interests
Article 21 creates two distinct objection regimes with very different legal consequences. The right to object to direct marketing processing is absolute — there is no balancing exercise and no grounds on which the objection can be refused. Where an individual objects to direct marketing, processing for that purpose must cease immediately and permanently, and the individual must be added to the suppression list.
The right to object to processing based on legitimate interests or public task (Article 21(1)) is not absolute. The controller may continue processing if it can demonstrate compelling legitimate grounds that override the data subject’s interests, rights, and freedoms, or for the establishment, exercise, or defence of legal claims. Every legitimate interests objection requires a genuine balancing assessment — not a template response — and the outcome must be documented.
OBJECTION REQUEST — RESPONSE PROCEDURE BY TYPE
| Objection Type | Basis for Objection | Default Response | Override Possible? |
|---|---|---|---|
| Direct marketing objection | Art. 21(2): Any direct marketing communication | Cease immediately; add to suppression list; confirm in writing; no further direct marketing | No — absolute right; no grounds can override |
| Legitimate interests objection | Art. 21(1): Processing under Art. 6(1)(e) or 6(1)(f) | Suspend processing; conduct balancing assessment; respond within one month | Yes — if compelling legitimate grounds demonstrated or legal claims involved |
| Profiling objection (automated) | Art. 21(1): Profiling based on LI | Suspend profiling; assess whether human review can be offered; consider if profiling is necessary | Yes — same compelling grounds standard as LI objection |
| Research / statistics objection | Art. 21(6): Processing for research or statistical purposes | Assess whether processing can continue under the public interest exception | Yes — if necessary for public interest purposes and not purely commercial research |
Data Portability: Building the Technical Infrastructure
Article 20 grants data subjects the right to receive personal data they have provided to a controller in a structured, commonly used, machine-readable format, and to transmit that data to another controller. This right applies only to data processed on the basis of consent or contract, and only to data provided by the data subject — not to derived or inferred data.
PORTABILITY REQUEST — SCOPE AND IMPLEMENTATION
| Dimension | Requirement | Implementation Consideration |
|---|---|---|
| Data in scope | Personal data provided by the data subject; data generated through their use of the service (behavioural data, preferences, content they created) | Profile data, purchase history, content uploaded, communication preferences, consent history |
| Data out of scope | Data derived or inferred by the controller; data generated by the controller (credit scores, risk assessments, recommendations) | Cannot be compelled to provide algorithms, scoring models, or proprietary analytical outputs |
| Format | Structured, commonly used, machine-readable format (e.g. JSON, CSV, XML; not PDF or proprietary binary format) | Build a data export function in standard formats; avoid PDF-only exports |
| Direct transmission | Where technically feasible, transmit directly to another controller on request (not just download to data subject) | API-based export endpoints; OAuth-authenticated data transfers to competing services |
| Timeframe | Within one month of request; same deadline as SAR | Can use the same intake and logging system as SARs; may require separate export tooling |
Rights Request Intake: Channel Management
GDPR does not prescribe how rights requests must be submitted. Data subjects can exercise their rights through any channel — email, written letter, phone call, social media message, verbal request in a physical location, or through a dedicated online portal. The organisation must be capable of recognising and processing a rights request regardless of its format or the channel through which it arrives.
RIGHTS REQUEST INTAKE — CHANNEL MANAGEMENT
| Channel | Handling Requirement | Common Failure |
|---|---|---|
| Dedicated online form / portal | Preferred channel; auto-logs request; generates reference; triggers workflow | Form not accessible on mobile; not linked from privacy notice |
| Email to DPO or privacy mailbox | Monitor dedicated address; auto-acknowledge receipt; log manually | Emails not monitored reliably; no acknowledgement sent; stored in personal inbox |
| General customer service email / chat | Staff trained to recognise rights requests and escalate immediately to privacy team | Staff not recognising a SAR embedded in a complaint email; not escalating; handling as a general enquiry |
| Phone call or in-person | Staff trained to recognise and escalate; request logged same day; follow up in writing to confirm receipt | Verbal request not escalated; no record kept; clock never started |
| Social media message | Monitor accounts for rights requests; acknowledge publicly and redirect to private channel; log and process | Social media requests ignored or not recognised as formal requests |
| Letter / post | Date-stamp on receipt; log as incoming request; start clock from date of receipt | Letter sits in post tray unprocessed; clock starts from wrong date |
| BITLION INSIGHT | Organisations that invest in a dedicated rights request management platform — or integrate rights request workflows into their existing GRC or CRM tooling — consistently report faster response times, fewer deadline breaches, and a more defensible audit trail. A spreadsheet tracking SARs manually across a team that handles dozens per month is a compliance risk as much as an operational one. The right tooling for rights request management scales with the volume of requests and the complexity of the processing. |