Table of contents
- A subject access request, commonly shortened to DSAR, is a request by an individual to obtain the personal data an organisation holds about them, along with information on how and why it is used.
- It is a core data-protection right, set out in Article 15 of the GDPR and mirrored in the UK GDPR and many other privacy laws worldwide.
- Organisations must usually respond within one month, extendable by two further months for complex or numerous requests, and the response is normally free.
- A DSAR can be refused or a fee charged only in limited cases, such as requests that are manifestly unfounded or excessive.
- The biggest operational burdens are finding all the data across scattered systems, verifying the requester's identity, and protecting other people's data in the response.
- Holding less personal data, and holding it in a structured, retrievable way, makes responding to a subject access request faster, cheaper and lower-risk.
A subject access request, often abbreviated to DSAR, is a request by an individual to receive a copy of the personal data an organisation holds about them, plus supporting information such as why it is processed, who it is shared with and how long it is kept. It is a right under Article 15 of the GDPR and equivalent laws.
TL;DR
A subject access request, or DSAR, is an individual's request to see the personal data an organisation holds about them and how it is used. It is a right under Article 15 of the GDPR and equivalent laws. Organisations must generally respond within one month, free of charge, with a possible two-month extension for complex or numerous requests, and can refuse or charge only in narrow cases such as manifestly unfounded or excessive requests. The hard parts are locating data across systems, verifying the requester, and redacting other people's information. Holding less data, in a structured and retrievable form, makes responding far easier.
What is a subject access request?
A DSAR is the mechanism through which an individual exercises their right to know what personal data an organisation holds about them. The person, known in data-protection law as the data subject, asks the organisation, the controller, for a copy of their data and for context about how it is being used. The right exists so people can understand, verify and, where appropriate, challenge how their information is processed.
The right is most associated with Article 15 of the GDPR in Europe, but the concept is far broader: the UK GDPR contains the same right, and comparable rights of access exist under laws such as California's privacy regime and many others around the world. A request does not have to use any special form or even the words the request; if an individual asks for their data, the organisation must treat it as one. That informality is part of what makes handling these requests operationally demanding.
What can someone request in a DSAR?
Through a a DSAR, an individual is entitled to confirmation of whether their data is being processed, a copy of that personal data, and supplementary information that puts it in context. That context typically includes the purposes of the processing, the categories of data involved, who the data has been or will be shared with, how long it will be kept, and the source of the data where it was not collected from the person directly.
The right of access covers personal data, meaning information relating to an identifiable individual, across the organisation's systems, not just a single database. It does not, however, give a person the right to documents as such, or to information that is not their personal data, and it is qualified by exemptions and by the rights of others. A common misconception is that a request entitles someone to every document mentioning them; in reality it entitles them to their personal data, which the organisation must extract and provide, drawing on whatever identity verification and records it holds.
How long do you have to respond to a subject access request?
Under the GDPR and UK GDPR, an organisation must respond to a DSAR without undue delay and at the latest within one month of receiving it. The clock starts when the request is received, or when any necessary identity verification is completed, and the response must be provided in an accessible format, commonly electronically where the request came in electronically.
The one-month period can be extended by up to two further months where the request is complex or where the individual has made a number of requests, but the organisation must tell the person about the extension, and the reason for it, within the original month. Missing the deadline is a compliance failure that can attract complaints to a regulator and, potentially, enforcement, so organisations need a process that reliably identifies, logs and tracks each request from the moment it arrives. This is one reason a connected, audit-ready compliance stack matters for privacy as well as for financial crime.
Can you charge for or refuse a DSAR?
In most cases an access request must be handled free of charge. An organisation can charge a reasonable fee, based on administrative cost, or refuse to act, only in limited circumstances: principally where a request is manifestly unfounded or excessive, for example because it is repetitive. It may also charge a reasonable fee for additional copies beyond the first.
Refusal is the exception, not the norm, and the bar is high. If an organisation refuses, it must explain why, inform the individual of their right to complain to the relevant supervisory authority, and tell them they can seek a judicial remedy. There are also exemptions that allow certain information to be withheld, such as data that would reveal another person's identity, or information covered by specific legal exemptions, but these must be applied narrowly and on a case-by-case basis rather than as a blanket reason to decline.
How should an organisation handle a DSAR?
A sound process has a few consistent steps. First, recognise and log the request, remembering it can arrive informally through any channel. Second, verify the requester's identity, so personal data is not disclosed to the wrong person, while taking care not to demand excessive information just to delay. Third, locate the relevant personal data across all systems where it may live, which is often the most time-consuming step.
Fourth, review the data and apply any exemptions or redactions, particularly to protect the personal data of third parties who appear in the same records. Fifth, provide the response within the deadline, in an accessible format, with the required contextual information. Finally, record what was done, because being able to demonstrate a compliant response is part of accountability. The difficulty of steps three and four scales directly with how much data the organisation holds and how scattered it is, which is where data minimisation pays off.
What are the main challenges of DSARs?
The first challenge is discovery. Personal data is often spread across many systems, backups, spreadsheets and inboxes, and finding all of it for one individual, within a month, is hard, especially at organisations that have collected data freely over years. The second is identity verification of the requester: the organisation must be confident it is giving data to the right person, without using verification as a delaying tactic.
The third is third-party data. Responses frequently contain information about other people, which must be redacted or withheld to protect their rights, a manual and error-prone task. The fourth is volume: high request volumes, sometimes coordinated, can overwhelm teams. Underlying all of these is a simple truth: the more personal data an organisation holds, and the more places it holds it, the harder, slower and riskier every request becomes. Reducing what is held, and structuring it, attacks the problem at its root, which is the logic behind decentralised PII storage.
How does holding less data reduce the DSAR burden?
The single most effective way to make a DSARs manageable is to hold less personal data and to hold it in a structured, retrievable form. Every record an organisation does not keep is a record it does not have to find, review, redact or risk disclosing incorrectly. Data minimisation, a core principle of data-protection law, is therefore not only a compliance duty but an operational advantage when responding to access requests.
This is where modern identity architecture helps. Verifying customers without warehousing raw documents, as in KYC without storing passports, and keeping only the minimal verification evidence required, shrinks the volume of personal data subject to access requests in the first place. Architectures that shard data so no single store holds a complete record, the basis of decentralised KYC, reduce both breach risk and the sprawl that makes a DSAR painful. In short, the privacy-by-design choices that reduce breach exposure also make every access request faster and cheaper to satisfy.
The bottom line
A subject access request is an individual's right to see the personal data you hold about them and understand how it is used, a right under Article 15 of the GDPR and equivalent laws worldwide. The rules are clear: respond within a month, free in most cases, refuse only in narrow circumstances. The difficulty is operational, finding scattered data, verifying the requester, and protecting third-party information, and it scales with how much data you hold. The most durable fix is to hold less: minimise personal data, structure it, and avoid central sprawl, and every DSAR becomes faster, cheaper and safer to answer.
Related resources
- Decentralised PII storage
- KYC without storing passports
- What is a KYC passport?
- Building an audit-ready compliance stack
- Zyphe decentralised KYC