What Is a Data Subject Access Request (DSAR)? A Practical Guide

Short answer: A Data Subject Access Request (DSAR) is a request, made under Article 15 of the UK GDPR, for a copy of the personal data an organisation holds about someone, along with the context behind it: why it's held, who it's shared with, and how long it's kept.

Any individual can make one, by almost any method, and the clock starts the moment anyone in your organisation receives it.That last point catches a lot of organisations out. A DSAR doesn't have to use the word "DSAR." It doesn't have to go to your DPO or a named contact. A current employee, an ex-employee, a customer, a patient or someone acting on their behalf, such as a solicitor or parent, can raise one verbally, by email, by letter, or even on social media. If it lands in a junk inbox and nobody reads it for three weeks, the clock is still running.

Who has to respond, and how fast

Once received, you have one calendar month to respond, starting the day after you get it. Many organisations work to 28 days internally to leave a safety margin. If the request is complex, or someone has sent several requests, you can extend by up to two further months, but you have to tell the requester within the first month, and explain why.

You can pause ("stop the clock") while you genuinely need to verify the requester's identity or ask a clarifying question. The Data (Use and Access) Act 2025, which received Royal Assent in June 2025, puts this stop-the-clock principle on a firmer statutory footing and confirms organisations only need to carry out searches that are "reasonable and proportionate" useful clarity for anyone who's ever faced a DSAR against years of email archives.

What happens if you get it wrong

The maximum fine for failing someone's access rights sits in the top tier of UK GDPR enforcement: up to £17.5 million, or 4% of annual global turnover, whichever is higher. Outright fines for DSAR failures alone are still relatively rare, but public reprimands from the ICO are not, and a court can separately order a response and award compensation.

The clearest recent example is Uber. In January 2024, the Dutch data protection authority fined Uber €10 million after 170 drivers complained they couldn't get hold of their own personal data. The request process was buried deep in the app, and when data did come back, it was in a format drivers couldn't make sense of. The lesson isn't just "respond on time"; it's that a DSAR process which is hard to find or hard to understand is a compliance failure in itself.

Building a DSAR process that holds up

A defensible process usually looks like this: log every request the moment it arrives, so the deadline is tracked centrally rather than sitting in one person's inbox; triage it to confirm who the individual is and what role they have (employee, ex-employee, customer, patient); verify identity proportionately, without creating unnecessary barriers; and respond within the deadline, documenting your rationale for any search scope or exemption decisions along the way. That last point matters more than people expect — if a request is ever scrutinised by the ICO, having a documented rationale for how you scoped the search is usually what keeps an organisation safe.

It's also worth checking who owns the obligation in the first place. If you're a data processor acting on behalf of a controller common in healthtech, where a supplier processes patient data on behalf of an NHS organisation the obligation to respond to the DSAR typically sits with the controller, not you.

FAQs