Data Subject Rights

Data subject rights are the legally enforceable entitlements that individuals hold over personal data processed about them. This reference provides lookup specifications for rights under the General Data Protection Regulation (GDPR) and equivalent frameworks, covering response requirements, exemptions, and verification procedures. For rights specific to survivors in protection contexts, see Survivor Data Rights.

Rights Enumeration

Right of access

The entitlement to obtain confirmation of whether personal data is being processed and, if so, to receive a copy of that data along with supplementary information about the processing.

Right to rectification

The entitlement to have inaccurate personal data corrected and incomplete data completed.

Right to erasure

The entitlement to have personal data deleted when specific conditions are met, commonly known as the “right to be forgotten”.

Right to restriction

The entitlement to limit processing of personal data to storage only, suspending other processing activities.

Right to data portability

The entitlement to receive personal data in a structured, commonly used, machine-readable format and to transmit that data to another controller.

Right to object

The entitlement to prevent processing based on legitimate interests, direct marketing, or research and statistics.

Rights related to automated decision-making

The entitlement not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects, and to obtain human intervention.

GDPR Rights Specifications

Equivalent Framework Comparison

Organisations operating across multiple jurisdictions encounter variations in rights frameworks. The following table maps GDPR rights to equivalent provisions in other major data protection laws.

Response deadlines by jurisdiction:

Response Requirements

The response to a data subject request must satisfy both content and format requirements. Content requirements define what information the response must include. Format requirements specify how that information must be delivered.

Access Request Response Content

A response to an access request under GDPR Article 15 must include all of the following elements when applicable to the processing activities:

Response Format Specifications

For portability requests specifically, the format must be structured, commonly used, and machine-readable. Acceptable formats include JSON, XML, and CSV. Proprietary formats that require specific software to read do not satisfy the requirement.

Fee and Charging Rules

The default position is that responses are provided free of charge. Fees are permitted only in specific circumstances.

Manifestly unfounded applies when the individual has no intention of exercising their rights, such as requests intended solely to cause disruption. Mere inconvenience to the organisation does not qualify.

Excessive requests applies when an individual submits requests more frequently than reasonable. The threshold depends on context: monthly requests for slowly-changing data are excessive, while monthly requests during an active dispute are not.

Reasonable administrative cost means the direct cost of providing the response, including staff time and materials. Organisations must be prepared to justify any fee charged. A worked example: if providing a second copy requires 2 hours of staff time at £25/hour plus £5 for secure postage, a fee of £55 is justifiable.

Exemptions and Limitations

Not all requests must be fulfilled. Legal exemptions limit or disapply certain rights in specific circumstances. Organisations must assess each request against applicable exemptions and document the justification when an exemption is applied.

GDPR Exemptions by Right

UK-Specific Exemptions

The UK Data Protection Act 2018 provides additional exemptions not present in the GDPR:

Humanitarian and NGO-Specific Considerations

Organisations operating in humanitarian contexts encounter circumstances where standard exemption analysis requires additional considerations.

Safeguarding investigations: During active safeguarding investigations, access requests from subjects of complaints may be restricted to prevent prejudice to the investigation. The restriction applies only for the duration of active investigation and must be documented. Once the investigation concludes, the exemption no longer applies.

Protection data: Data processed for protection purposes (child protection, GBV response, trafficking) may engage exemptions where disclosure would endanger the data subject or third parties. This requires case-by-case assessment. See Protection Data Principles for the framework.

Whistleblower identity: Access requests must not result in disclosure of whistleblower identities. When the only way to provide meaningful access would reveal a whistleblower, the access right is restricted to the extent necessary to protect the whistleblower.

Third-party safety: In protection contexts, disclosure of certain information may endanger third parties (perpetrators learning of safe house locations through a subject access request, for example). The exemption for third-party data extends to safety considerations, not merely privacy.

Verification Requirements

Before responding to any data subject request, the organisation must verify the identity of the requester. Verification must be proportionate to the sensitivity of the data and the nature of the request.

Verification Methods

Proportionality Assessment

The level of verification required depends on three factors: the sensitivity of the data, the nature of the request, and the risk of impersonation.

For access requests: Verification must be sufficient to prevent unauthorised disclosure. For routine HR data, account authentication suffices. For protection case files, enhanced verification including document checks is appropriate.

For erasure requests: Verification must prevent malicious deletion. The consequence of incorrect erasure (permanent loss of records) justifies stronger verification than access requests for the same data.

For rectification requests: Verification must confirm both identity and the accuracy of the claimed correction. The individual must demonstrate both that they are who they claim and that the data is indeed inaccurate.

Verification for Authorised Representatives

Requests submitted on behalf of data subjects require verification of both the representative’s identity and their authority to act. Acceptable authority documentation includes:

For children’s data, the child’s own capacity to make requests develops with age. Children aged 13 and over generally have sufficient understanding to make their own requests under UK and EU guidance. Parental requests for children over 13 require the child’s consent unless the child lacks capacity.

Request Handling Process

This section provides an overview of the request handling workflow. For detailed procedural steps, see operational documentation in your service management system.

Timeline Calculation

The response deadline runs from the day after receipt of a valid request. A request is valid when it clearly identifies the requestor and specifies the right being exercised. Requests requiring clarification do not start the clock until clarification is received.

Worked example:

• Request received: 15 March 2024
• Clarification requested: 18 March 2024
• Clarification received: 22 March 2024
• Clock starts: 23 March 2024
• Response due: 22 April 2024

If the deadline falls on a weekend or public holiday, it extends to the next working day. Calendar months are used, not 30-day periods: a request received on 31 January is due by 28/29 February, not 2/3 March.

Extension Procedure

Extensions are permitted when requests are complex or numerous. The extension decision must be communicated within the original one-month period and must explain why the extension is necessary.

Extensions cannot be applied routinely. An organisation processing a steady volume of requests cannot claim extension for each one based on general workload. The complexity must be specific to the individual request.

Response Documentation

Every request requires documentation regardless of outcome. The documentation serves three purposes: demonstrating compliance to regulators, enabling internal review, and providing evidence in disputes.

Cross-Border Considerations

Requests involving personal data transferred across borders or processed in multiple jurisdictions require additional analysis.

Determining Applicable Law

The applicable data protection law depends on the establishment of the controller, not the location of the data subject. An organisation established in the UK is subject to UK GDPR regardless of where the data subject resides. An organisation established in Kenya processing data about EU residents is subject to Kenya DPA for local processing and GDPR for processing related to offering services to EU residents.

Multi-Jurisdiction Requests

When a data subject submits requests under multiple frameworks, the organisation must respond to each applicable framework. In practice, responding to the most stringent framework typically satisfies all applicable frameworks.

Worked example: A UK-based NGO with EU operations receives an access request from a German national who interacted with both UK and EU operations. The request engages both UK GDPR (through the UK establishment) and GDPR (through the EU establishment). Responding within 1 month with all Article 15 content satisfies both frameworks.

Transfer Safeguards Information

Access request responses must include information about safeguards applied to international transfers. This requirement applies whenever personal data has been or will be transferred outside the jurisdiction providing protection.

Practical Reference Tables

Quick Reference: Response Requirements by Right

Quick Reference: Common Scenarios

Quick Reference: Exemption Checklist

For each request where an exemption may apply, assess:

See also

• Privacy by Design
• Breach Management
• Survivor Data Rights
• Data Classification
• Protection Data Principles