What is a DSAR and how do you respond within GDPR's deadline?

A Data Subject Access Request (DSAR) gives individuals the right to see every piece of personal data you hold about them. Here's the practical IT admin's guide to responding on time.

A Data Subject Access Request (DSAR) is a formal request from an individual asking your organisation to tell them what personal data you hold about them, why you hold it, and who you've shared it with. Under GDPR Article 15, you must respond within one calendar month - extendable by a further two months for requests that are complex or numerous.

GDPR gives individuals the right to obtain a copy of the personal data you process about them, free of charge, within one calendar month. In UK GDPR the timing rules were moved into Article 12A by the Data (Use and Access) Act 2025, so a reference to Article 12(3) for the deadline now points at the wrong place.

Who can submit a DSAR?

Any living individual whose data you process can submit a DSAR - employees, customers, ex-customers, website visitors, or even third parties whose details appear in your records. Requests don't need to use the phrase 'data subject access request'. Any email, letter, or web form submission asking what personal data you hold is legally a DSAR and starts the clock.

What must your response include?

Your response must cover every system in scope, not just your CRM. Under Article 15, you must provide:

• Confirmation that you process the subject's personal data
• A copy of the data itself (in a commonly used electronic format if requested)
• The purposes of processing
• The categories of data held
• Recipients or categories of recipients the data has been shared with
• The retention period (or criteria used to determine it)
• The subject's rights to rectification, erasure, and restriction
• The right to lodge a complaint with a supervisory authority
• The source of the data, if not collected directly from the subject

How the clock actually runs

The ICO states the position plainly: an organisation must respond as quickly as possible and no later than one calendar month, starting from the day it receives the request. A calendar month starts on the day of receipt, even if that is a weekend or public holiday, and ends on the corresponding date of the next month. A request received on 3 September is due by 3 October.

Two things move that start date, and both are easy to get wrong in the direction that costs you time.

• If you reasonably need something from the requester to deal with the request, such as identity documents, the month begins when you receive it rather than when they first wrote.
• Where you reasonably require further information to identify what the request relates to, UK GDPR now allows the response time to pause while you seek that clarification, resuming once you have it.

Neither is a licence to delay. Asking for identification you do not need, or for clarification you could resolve yourself, is not a reasonable request and will not stop the clock. But where the need is genuine, recording when you asked and when you received the answer is what establishes the real deadline.

For a complex request, or where an individual has made several, the period can be extended to a maximum of three calendar months in total from the day of receipt. That extension is not automatic: you have to tell the requester within the first month that you are relying on it, and why.

The ICO notes that its guidance on time limits is under review following the Data (Use and Access) Act 2025. Check the current position before relying on a deadline calculation, including this one.

Why the clock is not your real constraint

The legal deadline is one calendar month, extendable by two more months for complex or numerous requests. But most DSAR failures don't happen because teams run out of time - they fail because identifying and gathering the data takes too long. Endpoint devices are the most commonly overlooked source. Files on laptops, shared drives, and email archives regularly contain names, email addresses, national ID numbers, and financial details that were never catalogued anywhere.

Setting an internal three-day discovery target gives you the remaining 25 or so days to review, redact third-party data, and format the response properly. Teams that don't have a discovery process in place are the ones submitting extension notices at day 29.

A practical DSAR workflow

1. 1Verify the requester's identity. You may ask for reasonable verification, but don't delay unreasonably. A follow-up email to their account address is usually sufficient for customers.
2. 2Log the request formally. Record the date received, the requester's identity, and any identifiers they've provided (email, employee ID, account number). This record is itself subject to retention obligations.
3. 3Identify every system that might hold the subject's data. Work from your Record of Processing Activities (ROPA). Common sources: CRM, HR system, email, ticketing, analytics, shared file storage, and endpoint devices.
4. 4Search endpoint devices and file shares. This is where most teams hit their bottleneck - unstructured data on laptops is rarely indexed. A data discovery tool that scans endpoints for personal data can compress this from days to hours.
5. 5Gather and review the data. Redact any personal data relating to third parties before including it in the response. If you're uncertain whether data is in scope, err on the side of inclusion.
6. 6Draft and send the response. Include all required Article 15 fields. Use plain language - avoid legal jargon where possible.
7. 7Close and document the request. Record the outcome, any exemptions you relied on, and the date of your response. Retention: keep this record for at least three years.

What exemptions can you rely on?

You may withhold or redact data where disclosure would adversely affect the rights and freedoms of others (e.g. other employees' personal data), where legal professional privilege applies, or where the request is manifestly unfounded or excessive. You must inform the subject that you're withholding data and give them the right to challenge that decision. Exemptions are narrow - 'it would be inconvenient' is not a legal basis.

Common mistakes to avoid

• Forgetting endpoint devices and file shares - most DSAR failures involve unstructured data on laptops
• Treating verbal requests as informal - any channel starts the clock
• Delaying identity verification for more than a few days
• Redacting so heavily that the response is useless
• Failing to keep a record of the request and response
• Missing data held by processors on your behalf - their data is your responsibility

How hard you have to look

The Data (Use and Access) Act 2025 settled a question that used to be argued. An organisation dealing with a subject access request only has to carry out reasonable and proportionate searches for the relevant information.

That is a real limit and it is not a loophole. It does not let you decline to search somewhere merely because it is inconvenient, and it does not reduce the obligation to find what a competent search would find. What it does is recognise that the duty has an outer edge, and that the edge is set by proportion rather than by exhaustiveness.

In practice the standard rewards being able to describe your search rather than defend its completeness. If you can say which systems and locations you searched, what terms you used, and why that set was the sensible one for this request, you are arguing about reasonableness from a position of evidence. If you cannot say what you searched, the question of whether it was proportionate does not arise, because nobody can assess it.

The corollary is uncomfortable. A location you have never searched, and could not describe if asked, is hard to characterise as outside a reasonable search. Not knowing what is on your endpoints is not the same as having decided they were disproportionate to search.

What a complete response contains

A copy of the data is the part everyone remembers. Article 15 asks for more than that, and the supplementary information is where responses are most often thin.

Most of that column is answerable once from your record of processing and reused for every request. Teams that assemble it fresh each time are doing avoidable work, and it is the part most likely to be omitted under time pressure.

Requests that arrive in awkward forms

There is no prescribed format. A request is valid whether it arrives by email, letter, phone call, or in a message on a social media account you operate, and it does not have to use the words subject access request or mention data protection at all.

• Through a solicitor or other representative. Valid, provided you are satisfied the representative is authorised. The response goes to the representative unless the individual says otherwise.
• From an employee, often during a grievance or dispute. Motive is generally irrelevant to whether the right applies, and treating a request differently because you dislike its timing is not available to you.
• About a child. Children have the same rights, and where the child does not have sufficient understanding a person with parental responsibility may exercise them on their behalf. The judgement is about the child's understanding rather than a fixed age.
• Buried in a longer complaint. If the letter asks what data you hold, it is a request, whatever else it says.

The practical defence is a single route into the organisation. Requests reaching a personal inbox and sitting unread for three weeks is the most common way a month becomes impossible, and it is a routing problem rather than a legal one.

Charging, and refusing

The first copy is free. You may charge a reasonable fee based on administrative costs for further copies of the same information, and where a request is manifestly unfounded or excessive, in particular because of its repetitive character, you may charge a reasonable fee or refuse to act.

The burden of demonstrating that character falls on you, and it is a high bar. A request that is large, inconvenient, or made by someone in dispute with you is none of those things by itself. If you refuse, you must tell the person why, and that they can complain to the ICO and seek a judicial remedy.

How endpoint scanning helps

Manual DSAR responses at scale are operationally painful. For organisations with more than 50 employees or regular B2C customer contact, automated discovery is effectively a requirement. An agent running on each endpoint can surface every file containing a given email address, name, or ID number within minutes - turning the 72-hour discovery target from a stretch goal into a routine process.

Amendments

2 September 2026. Updated for the Data (Use and Access) Act 2025. The one-month deadline was attributed to Article 12(3); in UK GDPR the timing rules now sit in Article 12A, and the citation has been corrected. Added how the clock starts and when it can pause, and a section on the reasonable and proportionate search standard the Act introduced. The deadline itself is unchanged. Two headings that used 72 hours for an internal target were retitled, because 72 hours is the statutory breach-notification figure under Article 33 and the reuse was open to misreading.