The right of access under Article 15 of the GDPR is the most frequently exercised data subject right. A data subject access request — commonly called a DSAR — is a request from an individual to find out whether an organisation processes their personal data and, if so, to receive a copy of that data along with certain supplementary information.
The right sounds straightforward. In practice, it is one of the most operationally demanding GDPR obligations. A single DSAR can require searching across multiple systems, reviewing potentially thousands of documents, redacting third-party data, and compiling a comprehensive response — all within a tight deadline.
This article explains what the right of access requires, how to handle requests efficiently, and where the common pitfalls lie.
Any individual whose personal data you process can make a DSAR. This includes employees (current and former), customers, website visitors, job applicants, suppliers’ employees, and anyone else whose personal data you hold.
There is no required format for a DSAR. A request does not need to mention the GDPR, use the words “subject access request”, or be made in writing. An email asking “what data do you have about me?” is a valid DSAR. A verbal request to your receptionist is a valid DSAR. Your organisation needs to be able to recognise a DSAR regardless of how it arrives.
Requests can also be made by authorised third parties — a solicitor acting on behalf of a client, a parent on behalf of a young child, or a person holding a valid power of attorney. In these cases, you must verify the authority of the person making the request before responding.
When you receive a valid DSAR, you must confirm whether you process the individual’s personal data. If you do, you must provide a copy of that personal data together with the following supplementary information: the purposes of the processing, the categories of personal data concerned, the recipients or categories of recipients to whom data has been or will be disclosed, the retention period or criteria used to determine it, the existence of the right to request rectification, erasure, or restriction, the right to lodge a complaint with a supervisory authority, the source of the data where it was not collected directly from the data subject, and information about any automated decision-making including profiling.
The copy of the personal data must be provided in a commonly used electronic format if the request was made electronically. For most organisations, this means a structured document — PDF, spreadsheet, or similar — rather than raw database exports.
You must respond to a DSAR without undue delay and in any event within one month of receipt. This is one calendar month, not 30 days. If the request is received on 15 January, the deadline is 15 February.
The deadline can be extended by a further two months where the request is complex or where you have received a large number of requests from the same individual. But you must inform the data subject of the extension and the reasons for it within the original one-month period.
In practice, the one-month deadline is challenging for organisations that do not have established processes. Searching across email systems, CRM platforms, HR databases, paper files, and archived records takes time. Identifying and redacting third-party data takes more time. The earlier you start, the better your chances of meeting the deadline.
Before responding to a DSAR, you need reasonable confidence that the person making the request is who they claim to be. The GDPR does not prescribe how to verify identity, but it does require that you do not disclose personal data to the wrong person.
The verification measures should be proportionate to the risk. If a current employee makes a request from their work email address, that may be sufficient. If a request arrives from a generic email address claiming to be a former customer, you will need additional verification — perhaps asking for a copy of identification or asking the person to confirm specific details that only the genuine data subject would know.
Do not use the verification step as a way to delay or discourage requests. The measures must be proportionate and you must not ask for more information than is necessary to confirm identity.
A thorough response requires searching everywhere personal data might be held. This typically includes email systems (the individual’s name, email address, and other identifiers should be searched), CRM and customer management platforms, HR and payroll systems (for employee requests), file servers and document management systems, archived and backup systems where reasonably accessible, paper files, and any third-party platforms where you process data about the individual.
One of the most common complaints about DSAR responses is incompleteness. Data subjects — particularly former employees or dissatisfied customers — often know that data exists in systems the organisation has overlooked. A comprehensive search strategy, documented in advance, reduces this risk.
Your Records of Processing Activities (RoPA) should be your starting point. If your RoPA accurately maps where personal data is held across your organisation, it serves as a checklist for DSAR searches.
DSAR responses frequently contain personal data about other individuals. An email thread between a data subject and a colleague contains both parties’ personal data. A customer complaint file may reference third parties by name.
The GDPR does not require you to disclose the personal data of third parties in response to a DSAR. Where the data of other individuals is intermingled with the data subject’s data, you should redact the third-party data unless the third party has consented to disclosure or it is reasonable in all circumstances to disclose it without consent.
Redaction is time-consuming, particularly in email-heavy responses. Automated redaction tools can help, but manual review is almost always necessary to catch names, identifiers, and contextual information that automated tools miss.
There are limited circumstances in which you can refuse a DSAR or restrict the information you provide.
Manifestly unfounded or excessive requests. Article 12(5) allows you to refuse to act on a request or charge a reasonable fee if the request is manifestly unfounded or excessive, particularly where requests are repetitive. The threshold for this is high. A large or time-consuming request is not automatically excessive — the data subject is entitled to all their personal data regardless of volume. The request must be genuinely abusive or vexatious.
Legal privilege. Data that is subject to legal professional privilege is exempt from disclosure in a DSAR response. This is particularly relevant in employee DSARs where legal advice about the data subject may exist.
Rights of others. As noted above, you are not required to disclose information about third parties.
Regulatory investigations. Certain exemptions apply where disclosure would prejudice regulatory or criminal investigations, though these are narrowly construed.
If you refuse a request, you must inform the data subject of the reasons, their right to complain to the supervisory authority, and their right to seek a judicial remedy.
DSARs from current or former employees are among the most complex and sensitive to handle. Employee data is typically spread across multiple systems — HR platforms, email, internal messaging, shared drives, performance management tools, and paper files. The volume of personal data can be substantial, and the context is often adversarial: employee DSARs frequently arrive during or after a dispute.
Key considerations for employee DSARs include ensuring you search management emails and internal communications about the employee (not just the employee’s own mailbox), carefully redacting references to other employees, considering whether legal privilege applies to any documents, and being aware that the DSAR deadline continues to run regardless of any ongoing employment dispute or litigation.
The best approach is to treat employee DSARs with the same rigour as any other, while being particularly attentive to privilege and third-party redaction issues.
Organisations that handle DSARs well have established processes rather than treating each request as a one-off project. An effective DSAR process includes a single point of contact or team responsible for receiving and managing requests, a documented search strategy that lists all systems to be searched, clear procedures for identity verification, templates for acknowledgement letters, response letters, and extension notices, a relationship with IT to facilitate efficient data extraction, trained staff who can recognise a DSAR when it arrives through any channel, and regular review and improvement based on lessons learned from previous requests.
The investment in process design pays for itself quickly. Without a process, every DSAR is a scramble. With a process, it becomes a routine operational task.
At Pitch, we help organisations design and implement DSAR handling processes, and provide hands-on support for complex or sensitive requests. This includes building DSAR response frameworks tailored to your organisation’s systems and data landscape, advising on exemptions, redaction strategies, and privilege issues, supporting employee DSARs where the legal and HR dimensions intersect, and training your teams to recognise and handle requests efficiently.
Where DSARs form part of a broader dispute — as they often do in employment and commercial contexts — we integrate DSAR management with our wider legal strategy to ensure consistency and protect your position.
Pitch is the law firm for innovators and creatives. If you need help managing data subject access requests, get in touch or schedule a meeting with our team.
%402x.svg){kind=small}
%402x.svg){kind=icon}
%402x.svg){kind=icon}
