What a DSAR Is — and Why It Matters
A Data Subject Access Request (DSAR) is a request from an individual to exercise their rights over the personal data you hold about them. The best-known is the right of access (GDPR Article 15) — “tell me what data you have about me and give me a copy” — but the same machinery covers the wider set of data subject rights: rectification, erasure, restriction, portability, and objection.
For a website owner, DSARs are not a hypothetical. Any business that collects emails, runs analytics, stores customer accounts, or processes form submissions will eventually receive one. Mishandling it — missing the deadline, demanding an unlawful fee, or ignoring it — is itself a breach. This guide turns the legal obligations into a workable process. For the underlying framework, see what GDPR is and the broader GDPR requirements for websites.
The Rights Behind a Request
A DSAR can invoke any of several rights. You need to recognise which one is being exercised, because the response differs:
- Access (Art. 15) — a copy of their personal data plus supplementary information (purposes, recipients, retention, sources).
- Rectification (Art. 16) — correction of inaccurate or incomplete data.
- Erasure / “right to be forgotten” (Art. 17) — deletion, where one of the specified grounds applies.
- Restriction (Art. 18) — pause processing while a dispute is resolved.
- Portability (Art. 20) — receive their data in a structured, machine-readable format, or have it transmitted to another controller.
- Objection (Art. 21) — object to processing based on legitimate interests, or to direct marketing (which is absolute).
How to Recognise a DSAR
A request does not have to say “DSAR,” quote an article number, or arrive through a special form. A customer emailing “please send me everything you have on me” or “delete my account and my data” is making a valid request, and the clock starts when you receive it — through any channel, including social media or a support chat.
This is why staff awareness matters: the person who first reads the message (often support or sales) needs to recognise it and route it correctly. Build a simple internal rule — “any request about someone’s own personal data goes to the privacy inbox immediately” — so requests are not lost in a ticket queue while the deadline runs.
The Deadline: One Month
You must respond without undue delay and within one month of receiving the request. For complex or numerous requests, you may extend by a further two months, but you must tell the individual about the extension — and why — within the original month. You cannot simply go quiet.
The month runs from the day after receipt. If you need to verify identity first, the clock effectively starts once you have what you reasonably need to confirm who they are — but do not use verification as a stalling tactic; ask only for what is proportionate.
A repeatable DSAR workflow
Log and acknowledge
Record the date received, the requester, and the right being exercised. Acknowledge receipt so the individual knows it is in hand, and note the response deadline.
Verify identity proportionately
Confirm the requester is who they claim to be, using information appropriate to the sensitivity of the data. Do not demand excessive documentation — for an existing account holder, authenticating through the account may be enough.
Clarify scope if genuinely unclear
If you process large volumes of data, you may ask the individual to specify what they want. You cannot use this to delay a clear request, only to focus a vague one.
Search across all systems
Locate the person's data everywhere it lives: CRM, email, analytics, support tickets, backups, and any processors acting on your behalf. This is the step that benefits most from a clear data inventory.
Review and redact third-party data
Remove or redact information that would reveal other individuals' personal data, unless those individuals consent or it is reasonable to disclose. Apply any applicable exemptions.
Respond clearly and securely
Provide the information in a concise, transparent, intelligible form, using clear language. Deliver it securely — encrypted file or authenticated download, not plain email of sensitive data.
Can You Charge a Fee?
Generally, no. You must provide the response free of charge. You may charge a “reasonable fee” based on administrative costs — or refuse — only where a request is manifestly unfounded or excessive, for example a repetitive request for the same data. The bar for this is high, and you must be able to justify the decision. Treat “free, within a month” as the default and a fee as the rare exception.
When You Can Refuse — and How
You can refuse or partially refuse in limited circumstances: where the request is manifestly unfounded or excessive, or where an exemption applies (for instance, disclosure would adversely affect the rights of others, or the data is subject to legal privilege). Erasure requests can also be declined where you have an overriding legal obligation or right to keep the data.
If you refuse, you must still respond within the deadline, explain your reasons, and tell the individual they can complain to a supervisory authority and seek a judicial remedy. Silence is never a lawful response.
Cookie and Analytics Data Counts
DSARs are not limited to account records. Identifiers tied to a person — analytics IDs, advertising identifiers, and consent records — can be personal data within scope of an access request. This is one more reason to keep a complete, categorised inventory of what you collect; see the GDPR cookie compliance checklist and how to audit your website's cookies.
Preparing Before the First Request Arrives
The organisations that handle DSARs calmly are the ones that prepared. Three things make the difference:
- A data map. Know what personal data you hold, where it lives, and which processors touch it. Searching is the slowest step; a map turns days into hours.
- A named owner and inbox. Route every request to one place, with one accountable owner, so nothing falls through support queues.
- A template and log. Standard acknowledgement and response templates, plus a log of every request and its deadline, keep you consistent and demonstrate accountability.
A consent management platform helps on the data-map front: it records consent decisions per individual and centralises the cookie and tracking inventory that a DSAR often touches. See what a CMP is for how that fits into your wider privacy stack.
DSAR Response Checklist
Recognise the request, whatever channel it arrives through
No special wording or form is required; the clock starts on receipt.
Log it and note the one-month deadline
Record requester, right invoked, date received, and due date.
Verify identity proportionately
Ask only for what is necessary to confirm who they are.
Search every system, including processors and backups
CRM, email, analytics, support tickets, and third parties acting for you.
Redact other individuals' data before disclosure
Protect third-party personal data and apply exemptions.
Respond free of charge by default
A fee or refusal only applies to manifestly unfounded or excessive requests.
If refusing, explain and signpost complaint rights
State reasons and the right to complain to a supervisory authority.
Deliver the response securely and in clear language
Use encrypted or authenticated delivery for sensitive data.
Extend by up to two months only when justified
Tell the individual about any extension within the first month.
Maintain a data map and request log year-round
Preparation turns a stressful scramble into a routine task.
Authoritative Sources
The Best DSAR Process Is a Boring One
When you have a data map, a named owner, and templates ready, a DSAR becomes a routine task rather than a fire drill. Build that inventory now — starting with your cookie and tracking data via the cookie audit guide — so the first request you receive is one you are ready for.