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 gives the same answer only for requests received in a 30-day month — April, June, September or November — and a different one in the other eight; 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 February request gets 28 days (29 in a leap year) 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 end of the period can move, though, and only later. The EDPB says the period is calculated under Regulation 1182/71, and that “if the last day of this time period falls on a weekend or a public holiday, the controller has until the next working day to respond” (Guidelines 01/2022, para 161). The ICO applies the same rule to UK GDPR. A request received on Saturday 31 January 2026 runs to Saturday 28 February and is due Monday 2 March; one received on Wednesday 25 November 2026 runs to Christmas Day and, with the UK's Boxing Day substitute on Monday 28 December, is due Tuesday 29 December. Treat the moved date as a fallback, not a target.

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, the ICO tells controllers to “calculate the extension as three months from the original start date”, so a request received 3 March becomes due 3 June. That matters at month ends: a request received on 31 January has a one-month deadline of 28 February but an extended deadline of 30 April, not the 28 April you get by adding two months to the original deadline. The EDPB's guidelines do not say which method to use, so a cautious controller outside the UK can work to the earlier date. A weekend or holiday at the end of the extended period moves it to the next working day too.

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, moves a deadline that lands on a weekend or a public holiday of the country you pick to the next working day, 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.