How to Respond to a Data Subject Access Request (DSAR)

A data subject access request is the only GDPR obligation that arrives with a countdown attached. Article 12(3) gives you one month from the day the request lands, and the clock runs whether or not anyone in your organisation has noticed it yet.

The deadline is rarely the real problem. If you know where the data lives, a month is plenty. The month gets consumed by the harder questions: whose data is tangled up with the requester's, what is privileged, and which systems hold copies nobody mapped.

The clock starts wherever the request lands

A valid DSAR does not need to say "subject access request", cite Article 15, or arrive on your webform. The ICO is explicit that a request can be made verbally or in writing, through any channel, to anyone in the organisation. A reply to a marketing email counts. A message in a support chat counts. All it needs is enough to identify the requester and make clear they want their personal data.

That has a practical consequence: your receptionist, your support team and your social media manager are part of your DSAR process whether you trained them or not. Most blown deadlines die in week one, in a shared inbox, before anyone in compliance knows the request exists.

If the request is genuinely complex or you are handling several from the same person, Article 12(3) allows an extension of up to two further months. You must tell the requester within the first month and explain why. Data spread across many systems with heavy third-party entanglement is complex. A busy quarter is not.

Stopping the clock is legitimate. Stalling is not.

Two things pause the deadline, and both are easy to misuse.

Identity verification, first. If you have genuine doubt about who is asking, you can request proof, and the response period runs from when you receive it. But the check must be proportionate. When the request comes from the email address on the account, demanding a passport is not verification, it is delay, and the ICO reads it that way.

Clarification, second. If you process a large amount of information about the requester, you can ask them to narrow the scope, and the clock stops from the day you ask until the day they answer. The trap is what happens when they decline: you must still respond to the full request, searching everything. Clarification is a scoping tool, not a veto.

In both cases, log the dates. If the response runs close to the wire, the regulator's first question is when the clock actually started and stopped.

You can refuse, but the burden of proof is yours

Article 12(5) lets you refuse a request that is manifestly unfounded or excessive, and the same provision puts the burden of demonstrating that on you. The bar is high. A requester who repeats an identical request weeks after receiving the response may be excessive. One who offers to withdraw the request in exchange for a payout is unfounded. One who is suing you, hostile, or simply hard work is neither. A DSAR made mid-litigation is still a valid DSAR.

If you do refuse, you have one month to tell the requester why, and the notice must set out their right to complain to the ICO and to seek a judicial remedy. Write the internal reasoning down at the time you decide, not when the complaint arrives.

Money follows the same logic. The response is free. You can charge a reasonable fee, based on administrative cost, only for additional copies under Article 15(3), or as an alternative to refusal where a request genuinely is unfounded or excessive.

The hardest part is what you leave out

The requester's data is rarely alone. It sits in email threads with colleagues, grievance files naming witnesses, complaint records quoting other customers. Schedule 2, paragraph 16 of the Data Protection Act 2018 says you do not have to disclose information that identifies another individual unless that person consents or it is reasonable to disclose without consent, weighing confidentiality, any steps taken to seek consent, and any express refusal.

The discipline is to redact the third party, not withhold the document. A grievance outcome with witness names removed is disclosable. Withholding the whole file because one paragraph mentions someone else is the mistake that turns a DSAR into an ICO complaint. This is also where the month actually goes: the search takes hours, the redaction review takes days. Budget for it from day one, not day twenty.

Privilege survives a subject access request

Schedule 2, Part 4, paragraph 19 of the DPA 2018 exempts information covered by legal professional privilege. For law firms the analysis has an extra layer, because the privilege belongs to the client. A former client requesting their own file is in a very different position from an opposing party requesting what your litigation team wrote about them. Apply the exemption document by document, and keep a withholding log that records what was withheld and under which limb of privilege, without waiving it. Our Article 30 guide for law firms covers how client-file processing should be recorded in the first place.

An export is not a response

Article 15 asks for more than a copy of the data. The response must confirm that processing is happening and set out the purposes, the categories of data, the recipients or categories of recipients (including any in third countries), the retention period or the criteria for setting it, the source where the data did not come from the requester, their rights to rectification, erasure, restriction, objection and complaint, and the existence of any automated decision-making with meaningful information about its logic.

Read that list again and it should look familiar. It is your Article 30 record, restated for one person. If your RoPA is current, the narrative section of a DSAR response is a lookup. If it is not, you are drafting legal statements about retention and recipients from memory, under deadline.

Delivery matters too. If the request came in electronically, provide the response in a commonly used electronic format, and send it securely. The most common self-inflicted breach in DSAR handling is the response itself: a bundle sent to the wrong address, or a redaction that was a black highlight over selectable text.

Jersey counts in weeks and answers to the JOIC

If you operate in Jersey, the request falls under the Data Protection (Jersey) Law 2018, not the UK GDPR. The DPJL runs the same machinery on a different clock: four weeks to respond, extendable by up to eight further weeks for complex or numerous requests. Refusal notices must point the requester to the Jersey Office of the Information Commissioner, not the ICO. A pan-jurisdictional template that hard-codes "one month" and "complain to the ICO" is wrong on both counts for Jersey data subjects. Our guide to data protection in Jersey covers the wider regime, including the registration requirement the GDPR dropped and Jersey kept.

The response is built before the request arrives

Put the pieces side by side and a pattern emerges. Every hard step in a DSAR, scoping the search, naming the recipients, stating the retention period, knowing which processor holds a copy, is either read off a maintained register or reconstructed under time pressure. A DSAR is an external audit of your data map with a statutory deadline attached, and it grades work you did months before the request existed.

Teams with a current RoPA treat the search as a lookup: the register names the systems, the processors and the retention rules, so the month is spent on redaction and review, where judgement is actually needed. Teams without one spend the month searching mailboxes for a name and hoping.

That is the premise Clarium is built on. DSARs are handled against the same visual register that records your processing, so scoping a request means reading the map, not rebuilding it. See pricing.