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

A Data Subject Access Request gives an individual the right to a copy of their personal data and supplementary information under GDPR Article 15. Here is the deadline, what you must provide, when a fee or refusal is allowed, and a step-by-step workflow.

The Article 15 right of access, in plain terms

A Data Subject Access Request (DSAR) is how a person exercises their right of access under Article 15 of the EU General Data Protection Regulation (GDPR). In plain terms, anyone whose personal data you process can ask you to confirm whether you are processing data about them, to give them a copy of that data, and to tell them certain details about how and why you use it. The same right carries over almost identically into the UK GDPR, so a UK-facing business should read this the same way.

There is no special form a person must use. A DSAR can arrive by email, on a web form, in a letter, through a chat message, or even verbally — and it does not have to mention the words "GDPR," "Article 15," or "subject access request" to count. If a reasonable reader would understand it as a request for the person's own data, the clock starts. That is why front-line staff need to recognise and route these requests rather than treat them as ordinary correspondence.

The right belongs to the individual (the data subject) and is exercised against you as the data controller — the organisation that decides why and how the data is processed. If you act only as a processor for someone else, you generally pass the request to your controller-client and help them respond under your contract, rather than answering directly. Getting that controller-versus-processor distinction right at the outset determines who owns the response.

The one-month deadline — and when you can extend it

Article 12(3) sets the core timing rule: you must respond to a DSAR without undue delay and in any event within one month of receiving the request. In practice the month runs from the day after you receive the request (and, where relevant, from the point you have what you reasonably need to verify identity). It is a calendar month, ending on the corresponding date in the next month, so treat it as a hard deadline rather than "about 30 days."

That one-month period can be extended by up to two further months — giving a maximum of three months — but only where the request is complex or where you have received a number of requests from the same individual. The extension is not automatic and it is not a default buffer; you must be able to justify it by reference to the actual complexity or volume involved. Sheer inconvenience or a busy team does not make a request complex.

Crucially, if you intend to use the extension you must tell the individual within the first month, explaining the reasons for the delay. So even when you take the extra time, you still have a one-month obligation to communicate. The cleanest approach is to log the receipt date immediately, diarise the one-month and three-month dates, and decide early whether the request genuinely warrants more time so you can send the extension notice in good time.

Verifying identity before you disclose

Before you hand over someone's personal data, you need to be confident you are giving it to the right person. Article 12(6) allows you, where you have reasonable doubts about the identity of the person making the request, to ask for additional information necessary to confirm that identity. Identity verification is a legitimate and often essential step — disclosing data to an impostor is itself a personal-data breach.

The key word is reasonable. You should ask only for what is genuinely needed to be satisfied, and proportionate to the sensitivity of the data and the way the request arrived. If the request comes from an email address already firmly associated with the account, demanding a passport scan and a utility bill is excessive and can look like an obstacle designed to deter the request. For higher-risk or special-category data, a more robust check is justified.

Verification also affects timing. Where you reasonably need identity information to proceed, the response clock effectively does not start until you have received what you need — but you cannot sit on a request, so ask promptly and clearly. If a request is made on someone else's behalf (by a parent, solicitor, or agent), you are also entitled to verify both the requester's authority and the data subject's identity before disclosing.

What you must actually provide

A DSAR response has two parts. The first is a copy of the personal data you are processing about the individual. "Personal data" is broad — it includes obvious records like name, contact details, and account history, but also things like notes, emails that reference the person, CRM entries, support tickets, and call recordings, wherever they live across your systems. You are giving them their data, not your entire file verbatim, but you must search the places that data realistically sits.

The second part is the supplementary information listed in Article 15(1): the purposes of the processing; the categories of personal data concerned; the recipients or categories of recipient, especially any in third countries; the envisaged retention period (or the criteria used to set it); the existence of the rights to rectification, erasure, restriction, and to object; the right to lodge a complaint with a supervisory authority; the source of the data where it was not collected from the individual; and the existence of any automated decision-making, including profiling, with meaningful information about the logic involved and the consequences. Much of this overlaps with your privacy notice, which is why a well-maintained notice makes DSARs far easier.

Where the request is made electronically, and unless the person asks otherwise, you should provide the information in a commonly used electronic form. The data must be supplied in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. A data dump of raw database tables the person cannot interpret does not meet that standard.

Fees, refusals, exemptions and redacting other people's data

The default is that responding to a DSAR is free. Under Article 12(5), you may charge a reasonable fee based on administrative costs, or refuse to act, only where a request is manifestly unfounded or excessive — in particular because it is repetitive. The bar is deliberately high, and the burden of demonstrating that a request meets it rests on you, the controller. "Excessive" is about the character of the request, not the effort it costs you; an awkward or large but genuine request is not automatically excessive. You can, however, charge a reasonable fee for further copies of data already provided.

The right of access is not absolute. Article 15(4) says the right to obtain a copy must not adversely affect the rights and freedoms of others — most commonly meaning you must redact third-party personal data that appears in the records (other customers, colleagues, or complainants) unless those individuals have consented or it is otherwise reasonable to disclose. Member State and UK law also create specific exemptions, for example around legal professional privilege, certain crime-prevention or regulatory functions, and confidential references, and Recital 63 notes that the right should not adversely affect trade secrets or intellectual property — though that cannot be used to refuse all the information.

Apply these limits surgically, not as a blanket excuse to withhold. Redact only what you are entitled to withhold, disclose the rest, and keep a short internal note of what you removed and why. If you refuse a request in whole or in part, Article 12(4) requires you to tell the individual — within the one-month deadline — the reasons, and to inform them of their right to complain to a supervisory authority and to seek a judicial remedy.

A practical DSAR workflow — and where the GDPR pack fits

A repeatable workflow keeps DSARs from becoming fire drills. Step one: log the request the moment it arrives, record the receipt date, and acknowledge it. Step two: confirm the requester's identity proportionately, and clarify the scope if a broad request is genuinely unclear (you can ask what they are looking for, but you cannot force them to narrow it). Step three: search your systems — email, CRM, HR, ticketing, backups where reasonable, and any processors — to locate the relevant personal data. Step four: review and redact, removing third-party data and applying any exemption that genuinely applies. Step five: compile the copy of the data plus the Article 15(1) supplementary information. Step six: deliver securely within one month (or send the extension notice within that month if the request is complex or numerous), and record what you disclosed, withheld, and why.

Building that process and its templates from scratch is slow, and inconsistency between responses is a common audit and regulator finding. This is where a documentation toolkit helps honestly. The ComplianceDocs GDPR Compliance Pack for Small Business includes an editable Data Subject Rights / DSAR procedure — alongside a data protection policy, privacy notices, a DPIA procedure, a personal-data breach response procedure, and a pre-filled Article 30 Records of Processing workbook — so you start from a structured method, a request log, and a response template rather than reinventing the format under deadline pressure.

Be clear about what the toolkit does and does not do. A template is the documentation layer: a defensible DSAR procedure and the surrounding policies a regulator or assessor expects to see. It does not make your organisation "GDPR compliant," and no document set can. Compliance comes from operating the process — actually finding the data, verifying identity, redacting correctly, meeting the deadline, and answering honestly. The structure speeds the work; the judgement about each specific request, and the legal obligation to get it right, remain yours.

Frequently asked questions

How long do I have to respond to a DSAR?

You must respond without undue delay and in any event within one month of receiving the request, under Article 12(3). That period can be extended by up to two further months — a maximum of three months in total — but only where the request is genuinely complex or where you have received a number of requests from the same person. If you use the extension, you must tell the individual within the first month and explain the reasons for the delay. Where you reasonably need identity verification to proceed, the clock effectively starts once you have what you need to confirm who they are.

Can I charge a fee or refuse a DSAR?

Usually no — responding is free by default. Under Article 12(5), you may charge a reasonable fee based on administrative costs, or refuse to act, only where a request is manifestly unfounded or excessive, in particular if it is repetitive, and the burden of proving that rests on you. "Excessive" relates to the nature of the request, not simply how much work it creates. You can charge a reasonable fee for further copies of data you have already provided. If you do refuse, you must tell the individual the reasons within the one-month deadline and inform them of their right to complain to a supervisory authority.

What information has to be included in the response?

Two things. First, a copy of the personal data you process about the individual, gathered from across your systems and provided in a concise, intelligible, plain-language form. Second, the supplementary information set out in Article 15(1): the purposes of processing; the categories of data; the recipients (including any outside the EU); the retention period or the criteria for it; the rights to rectification, erasure, restriction, objection and to complain to a regulator; the source of the data if not collected from them; and any automated decision-making or profiling, with meaningful information about the logic and consequences. Much of this mirrors your privacy notice.

Do I have to hand over data that mentions other people?

Not automatically. Article 15(4) says the right to obtain a copy must not adversely affect the rights and freedoms of others, so you should redact third-party personal data — other customers, employees, or complainants — unless those individuals have consented or disclosure is otherwise reasonable. Specific legal exemptions can also apply, for example around legal privilege, certain regulatory or crime-prevention functions, and confidential references. Apply these limits surgically: redact only what you are entitled to withhold, disclose the rest, and keep an internal note of what you removed and why.

Does the GDPR pack make my business GDPR compliant?

No. The ComplianceDocs GDPR Compliance Pack for Small Business includes an editable Data Subject Rights / DSAR procedure and the surrounding privacy documents, which gives you a repeatable workflow, a request log, and a response template instead of building the format under deadline pressure. But a template is the documentation layer only. GDPR compliance comes from operating the process — locating the data, verifying identity proportionately, redacting third-party information, meeting the one-month deadline, and answering honestly. No document set can make you compliant on its own; it speeds the readiness work, while the handling of each request and the legal obligations remain yours.

Related guides: GDPR

Toolkits that help

← All articles