The GDPR DSAR Deadline: "One Month" Is Trickier Than It Sounds

Article 12(3) of the GDPR gives a controller "one month" to respond to a data subject access request. One month sounds like the easiest deadline in the regulation to calculate. It is not, because a month is not a fixed number of days and because the clock starts earlier than most organisations think.

A month is a calendar month, not thirty days

The period runs to the corresponding date in the following month. A request received on 3 March is due 3 April. A request received on 15 November is due 15 December. Thirty days would give you a different answer in every month except one, and in February it would give you a materially longer deadline than you actually have.

The corresponding-date rule needs a fallback when there is no corresponding date. A request received on 31 January has no 31 February to run to, so the deadline is the last day of the following month — 28 February, or 29 in a leap year. The same applies to a request received on 31 March, which is due 30 April. This is the same convention English law uses for periods expressed in months, and it is the one European regulators apply.

The practical effect is that a January request gets 28 days and a March request gets 31. If your internal SLA is a flat "30 days", it is too generous in short months and you will breach.

The clock starts on receipt, by anyone

Day zero is the day the request is received by the controller — not the day it reaches the privacy team, not the day it is logged in a case system, and not the day someone decides it qualifies as a DSAR.

This is the failure that produces most late responses. A customer writes "please send me everything you hold about me" in a reply to a support ticket. It sits in a queue for eleven days before anyone recognises it as an access request. The deadline did not move; you simply spent a third of it.

Two related points follow. A request does not have to use the words "subject access request", cite the GDPR, or arrive through a designated channel — a request made verbally to a shop assistant is still a request. And where a processor receives it on the controller's behalf, the controller's clock starts then.

Identity verification does not stop the clock — usually

Where you have reasonable doubts about the identity of the requester, you may ask for information to confirm it, and the period does not begin until you have it. That is a genuine and important qualification.

It is also routinely over-used. It applies where you have reasonable doubt, not as a matter of course, and not where the request comes from an authenticated account you already know. Demanding a passport scan from a logged-in customer to buy an extra fortnight is the kind of thing regulators notice, and it creates a fresh data-minimisation problem of its own.

The two-month extension is conditional and must be announced

Article 12(3) allows the period to be extended by a further two months where necessary, taking account of the complexity and number of the requests. Two things about that are frequently missed:

• You must tell the requester within the first month, and tell them why. An extension you decide on internally in week three and communicate in week six is not an extension; it is a breach with a letter attached.
• It is not a default. The threshold is genuine complexity — large volumes, extensive third-party data requiring redaction, information spread across legacy systems. Volume of requests generally is not, on its own, a reason: under-resourcing your DSAR process is your problem, not the requester's.

Where the extension applies, it runs from the original deadline, so a request received 3 March that would have been due 3 April becomes due 3 June.

What "responding" means

The deadline is to provide the information, not to acknowledge the request or to promise it soon. If you are refusing — because the request is manifestly unfounded or excessive, or because an exemption applies — the refusal, its reasons, and notice of the right to complain to a supervisory authority and to a judicial remedy all have to be communicated within the same period.

The response must also be in a commonly used electronic form where the request was made electronically, and the first copy must be free.

UK GDPR runs the same clock

Post-Brexit, the UK GDPR retains the same one-month period with the same two-month extension, supervised by the ICO rather than an EU authority. The date is identical; the regulator you answer to is not. Organisations operating in both need to track which requests fall under which regime, because the correspondence and the complaint route differ even though the arithmetic does not.

Build the buffer into the process, not the deadline

The pattern in almost every late DSAR is the same: the deadline was calculated correctly from the wrong start date. Log the date of receipt at the point of receipt, across every channel a request could plausibly arrive through, and calculate from that. If your process needs a fortnight of slack, take it out of the middle, not out of the front.

The GDPR DSAR Deadline calculator applies the corresponding-date rule, handles the short-month fallback, and shows the extended date alongside the standard one so you can see both at once.

General information about how the response period is calculated, not legal advice. Whether an extension or an exemption applies to a particular request depends on its facts — take advice from a qualified data protection practitioner before relying on either.