The request that starts a clock, not a conversation
A data subject access request, universally shortened to DSAR, is a person asking a controller for confirmation of whether personal data about them is being processed and, where it is, for access to that data and a defined list of information about it. That is Article 15 of Regulation (EU) 2016/679, the GDPR. The obligation that breaks operators is not the disclosure itself. It is Article 12(3): the controller must provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request.
Most DSAR failures share one shape. The request arrived in an ordinary inbox, nobody logged a receipt date, and the deadline was discovered when the requester complained. The fix is an intake log, a data map, and a queue with a visible clock. This playbook gives you all three, built from the Regulation text itself.
> [!KEY TAKEAWAY]
> A DSAR is a dated obligation, not a conversation thread. Log the receipt date the day the request arrives, compute the one-month deadline the same day, and treat every day without a log entry as a day the deadline is moving without you.
Who this playbook is for, and who should stop here
This playbook is for controllers: SaaS operators, agencies, marketplaces, and B2B vendors that decide why and how EU personal data is processed, including CRM records, support tickets, billing history, analytics profiles, and email logs. If your product stores a customer record, a support thread, or an event stream keyed to a person, you are the audience.
Stop here and reroute instead if any of these apply. If you are a processor acting only on a customer’s instructions, your duty is to assist that controller and forward the request under your processing contract, not to answer the data subject directly from your own systems. If the request concerns data you do not hold, answer with a confirmation of non-processing rather than a search you cannot evidence. And if the request touches an active investigation or a legal hold, involve counsel before any disclosure, because a DSAR copy sent to the wrong person is a breach, while a delayed copy is a complaint. The first failure is worse than the second.
The one-month clock, worked to the day
Article 12(3) sets the rule in one sentence with one safety valve. The base period is one month from receipt. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. The controller shall inform the data subject of any such extension within one month of receipt of the request, together with the reasons for the delay. Note what the extension is not: it is not automatic, it is not available because the queue is busy, and it is not available retroactively after the first month has already expired.
Count calendar months, not 30 days. A request received on 9 November falls due on 9 December. A complex request that genuinely spans several systems, with the extension notice sent by 9 December, falls due on 9 March. A request received on 31 January falls due on 28 February in a non-leap year, because February has no 31st day and the corresponding date does not exist. Operators that count 30 days from 31 January answer on 2 March and are already late.
$
\text{Due Date} = \text{Receipt Date} + 1 \text{ calendar month}
$
$
\text{Extended Due Date} = \text{Receipt Date} + 3 \text{ calendar months}
$
The queue math matters because DSAR volume is lumpy. One product launch, one press story, or one viral complaint can multiply requests in a week. Size the queue before it spikes:
$
\text{Monthly Handling Hours} = \text{Requests Per Month} \times \text{Hours Per Request}
$
A queue receiving 40 requests per month at 3.5 hours each consumes 140 hours per month, or 0.875 of a full-time operator at 160 working hours. At 80 requests the same queue needs 280 hours, or 1.75 operators, and the extension rule becomes the only lawful way to hold the line. Run this calculation monthly. When the result crosses 1.0 full-time equivalent, hire or automate the search step before the deadline math forces an extension on every request, because a controller that extends everything has stopped meeting the base rule and started announcing it.
What Article 15 actually requires you to hand over
Article 15(1) gives the data subject the right to obtain confirmation of whether personal data concerning them is being processed and, where that is the case, access to the personal data plus the following information: the purposes of the processing; the categories of personal data concerned; the recipients or categories of recipient to whom the data have been or will be disclosed, in particular recipients in third countries or international organisations; where possible, the envisaged period for which the data will be stored, or the criteria used to determine that period; the existence of the right to request rectification or erasure or restriction of processing; the right to lodge a complaint with a supervisory authority; where the data were not collected from the data subject, any available information as to their source; and the existence of automated decision-making, including profiling, with meaningful information about the logic involved and the significance and envisaged consequences for the data subject.
Article 15(3) then adds the copy itself. The controller shall provide a copy of the personal data undergoing processing, and where the data subject makes the request by electronic means, the information shall be provided in a commonly used electronic form unless otherwise requested. In practice that means a CSV or JSON export plus a readable summary, not a screenshot of an admin panel and not a PDF scan of a database dump. The copy is the evidence; the Article 15(1) list is the explanation of the copy. Delivering one without the other is how a compliant-looking response still fails.
The triage sequence
Run every request through the same six steps, in order, with a log entry at each step. Variation between requests is where deadlines die.
1. Log receipt. Record the date, channel, requester identifier, and the exact scope as written. The receipt date is the clock start, not the date someone first read the message.
2. Acknowledge within days, not weeks. Confirm receipt, state the one-month deadline in plain language, and name a single contact. Early acknowledgement also surfaces scope problems while there is still time to fix them.
3. Verify identity only where doubt is reasonable. Article 12(6) permits additional information necessary to confirm identity where the controller has reasonable doubts. A request from the account email address on file, authenticated in the product, rarely meets that bar. A request from a new address claiming a dormant account usually does.
4. Search every system on the data map, not just the CRM. Billing, support, analytics, email, backups metadata, and third-party processors acting for you. A DSAR that searches one system and misses four is a partial response dressed as a complete one.
5. Redact third-party data, then review the redaction. One reviewer searches, a second reviewer checks the copy before release. The wrong-person disclosure is the failure mode that turns a compliance task into a breach notification.
6. Deliver the copy plus the Article 15(1) list, and log the delivery. Record what was sent, to which address, and on which date. If the requester later complains, the log is the defence.
The decision table
| Situation | Response | Deadline | Regulatory Authority |
| :--- | :--- | :--- | :--- |
| Straightforward request, data in two or fewer systems | Full copy plus Article 15(1) list | One month from receipt | GDPR Art. 12(3), Art. 15(1)–(3) |
| Complex request spanning many systems, or a large batch of requests | Extension notice with reasons, then full response | Up to three months from receipt | GDPR Art. 12(3), second sentence |
| Repeat request identical to one already answered | Reasonable fee based on administrative costs, or refusal, with reasons | Inform within one month; Art. 12(4) applies if no action is taken | GDPR Art. 12(5), Art. 12(4) |
| Copy would expose other people’s personal data | Redacted copy plus an explanation of each redaction class | One month from receipt | GDPR Art. 15(4) |
| Reasonable doubt about the requester’s identity | Request additional information necessary to confirm identity, immediately | Work to the original deadline; do not assume a pause | GDPR Art. 12(6) |
| No action taken on the request | Inform the data subject without delay and at the latest within one month, with reasons and the complaint and judicial remedy routes | One month from receipt | GDPR Art. 12(4) |
> [!WARNING]
> The most expensive DSAR outcome is not a late response. It is a copy sent to the wrong person, or an unredacted copy that discloses other data subjects. A late response draws a complaint to a supervisory authority. A wrong-person disclosure creates a personal data breach with its own notification duties. Build the two-person release rule before you build anything else, because speed without a release check is how the worse failure happens.
Excessive requests, unfounded requests, and the burden of proof
Article 12(5) gives controllers two tools against abuse, and one trap. Where requests from a data subject are manifestly unfounded or excessive, in particular because of their repetitive character, the controller may either charge a reasonable fee taking into account the administrative costs of providing the information or communication, or refuse to act on the request. The trap is in the following paragraph: the controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request.
That burden is why a refusal letter must cite the request history, not an attitude. A second identical request two weeks after a complete response, with no new data in between, is a defensible refusal. A first request from an unhappy customer is not, however inconvenient. A fee must track administrative costs; a fee set high enough to discourage requests is a refusal in disguise and will be treated as one. Keep the fee calculation on file: hours, rate basis, and the cost of the copy medium. If you cannot show the arithmetic, you cannot show the fee was reasonable.
Redaction without over-redaction
Article 15(4) is short and frequently over-read. The right to obtain a copy shall not adversely affect the rights and freedoms of others. That sentence justifies redacting other data subjects’ names, addresses, and identifiers from support threads, shared documents, and group records. It does not justify redacting the requester’s own data because it is embarrassing, commercially sensitive, or likely to support a complaint. Over-redaction is a partial refusal, and a partial refusal without reasons is a failure under Article 12(4) logic: the data subject is entitled to know why action was not taken on part of the request.
The working rule is simple. Redact the person, not the event. A support ticket about the requester stays in the copy with other customers’ names removed. An internal note flagging the requester’s account stays unless a specific, documented ground removes it, and that ground is explained in the covering letter. Every redaction class gets one log line: what was removed, why, and under which provision.
> [!FOUNDER]
> "A DSAR queue is an honesty test for your data map. If you cannot find a person’s data in a week, you do not have a privacy problem, you have an inventory problem, and the regulator will find it through the same request you did."
> — Enow A. Jovial, Founder & Chief Executive Officer
Failure modes that repeat
The same four failures appear in DSAR post-mortems. First, the unlogged inbox request, solved only by a single intake channel that every team is trained to forward to within one working day. Second, the single-system search, solved by the data map and the quarterly refresh. Third, the portal-only response, where the controller answers requests made through its form and ignores the same request made by email; Article 12(2) requires facilitating the exercise of rights, and facilitation does not mean channelling. Fourth, the unexplained partial response, where records were withheld or redacted without reasons and the requester’s complaint writes itself. Each failure is operational, each is preventable, and each is cheaper to prevent than to explain to a supervisory authority.
> [!TIP]
> Offer a self-service export in the product, but never treat it as a substitute for the DSAR duty. A self-service download reduces routine volume and gives requesters their core data immediately, which in turn makes the remaining formal requests smaller and faster. It does not extinguish a request made outside the portal, and it does not cover systems the export does not reach, such as support tickets or billing correspondence. Log the formal request anyway, and answer it with the full Article 15(1) list.
When to get counsel involved
Bring counsel in before answering, not after delivering, when any of these appear: the requester is in a dispute or litigation with the company; the data includes special-category material such as health information; a processor or joint controller relationship decides who must answer; or the request opens an organised batch aimed at extraction rather than access. Counsel’s job is narrow: confirm the controller identity, the redaction lines, and the refusal or fee reasoning. The log, the search, and the deadline stay with the operator.
Related reading on this site: the self-hosted analytics guide for PostHog, Plausible, and Umami under GDPR for the analytics side of the same data map, and the LLC and corporate dissolution playbook for what happens to retained personal data when the entity winds up. For the California counterpart, see the CCPA deletion request playbook. To model the staffing cost of the queue before it spikes, run the hours math through the break-even calculator.