When does the UK subject access request time limit start?

It normally starts when the organisation receives the SAR. Where it reasonably needs information to verify identity, confirm a representative's authority or receive a fee requested for responding to a manifestly unfounded or excessive request, the ICO says the month can run from receipt of that information[2]. The organisation should ask promptly, record the relevant date and respond without undue delay, rather than treating one month as permission to wait.

Does a weekend delay the start of the SAR clock?

No. The ICO says the start is the actual date of receipt, even on a non-working day. Count to the same date in the next month. If the response date lands on a weekend or public holiday, the deadline moves to the end of the next working day. A request received on 31 January uses February's final day.

Can clarification stop the clock under the DUAA?

Yes, but only where clarification is reasonably required to identify the information or processing activity covered by the request. The Data (Use and Access) Act 2025 provides that basis, and the ICO says the controller must be able to justify it. A routine question about preferred response format does not pause the time limit.

When does a paused subject access clock resume?

It resumes on the day after the controller receives the requested clarification. The pause begins on the day clarification is requested. Add the stopped days to the original deadline. The ICO's example starts with a 14 May request, pauses from 15 to 18 May, resumes on 19 May and moves the deadline from 14 to 18 June.

When can a UK SAR deadline extend by two months?

A further two months may be necessary where the request is complex or the person has made a number of requests. The ICO says the resulting deadline is calculated as three months from the original start date. The controller must tell the person about the extension and its reasons within the initial one-month period.

Does a manifestly unfounded or excessive request change the SAR clock?

It can affect the start if the controller requests a fee for responding to a manifestly unfounded or excessive request: the ICO says the time limit runs from receipt of that fee[2]. The ICO also says a controller may instead refuse to comply with such a request[1]. This is a specific rule, not a general charge for every SAR; record why the request meets that description and the date of any fee receipt.

Must the organisation explain a SAR extension?

Yes. The ICO says the requester must be told both that the time limit is extended and why, within one month of the relevant start date. A workload label alone does not establish complexity. The organisation should record what made this request complex or how the number of requests affected its response, then give the person a clear revised deadline.

Subject access request time limit under UK GDPR: DUAA

Quick Answer: The subject access request time limit is one calendar month from receipt. After the Data (Use and Access) Act 2025, justified clarification can pause it until the day after the reply arrives. Identity checks can affect the start; complexity or multiple requests can justify two further months, with notice and reasons¹^,2^,3.

Summary in a mind map

Subject access request time limit under UK GDPR: DUAA
│
├─ Start and count
│   ├─ Receipt normally starts the one-month period
│   ├─ Count to the same date next month
│   └─ Necessary identity checks may affect the start
│
├─ Justified pause
│   ├─ Clarification must be reasonably required
│   ├─ Stop on the day it is requested
│   └─ Resume the day after the reply arrives
│
├─ Possible extension
│   ├─ Complexity or multiple requests can justify it
│   ├─ Add up to two further months
│   └─ Tell the person why within the first month
│
└─ Evidence
    ├─ Log each event and date
    └─ Keep the notice and final calculation

What starts the one-month SAR time limit?

Record the date on which the organisation receives the subject access request (SAR). The ICO says the response must come without undue delay and, at the latest, within one month of receiving the request¹; that is the ordinary starting point. The date belongs in a request log alongside the channel in which it arrived and the colleague responsible for coordinating the response. The ICO lists UK GDPR Articles 12 and 15 as provisions for the right-of-access guidance³.

The clock can instead run from receipt of information reasonably sought to confirm the person's identity, a third party's authority to act, or a fee requested for responding to a manifestly unfounded or excessive request¹^,2. Those are distinct events. A general request for more convenient formatting does not belong in that list. If identity is already clear, the ICO says a demand for formal documents may be unreasonable¹. Staff should record the reason for a check as well as the date it was satisfied.

The request need not use the words "subject access request" to raise an access issue. An organisation first needs to recognise what the person is asking for; the general explanation of a subject access request gives the wider context. For this deadline exercise, work from the actual request and the specific timing events shown by the ICO's guidance¹.

Calculating a calendar month

The ICO measures the month from the actual receipt date to the end of the same date in the following month. A non-working day does not postpone the start¹. For example, a request received on 1 January is due at the end of 1 February. If the matching date does not exist in the following month, use that month's last day¹.

Receipt date	Ordinary one-month end	Reason
1 January	End of 1 February	Same date next month¹
31 January	End of 28 February, or 29 in a leap year	February has no 31st¹
Date whose deadline is a holiday	End of next working day	ICO working-day adjustment¹

The adjustment for weekends and public holidays applies to the deadline, not the starting event. This distinction matters in a recruitment agency receiving a request in an unattended inbox on a Sunday. It should record the Sunday as receipt and calculate from there. A standard "30-day" task timer can give the wrong result, because calendar months vary in length¹.

Identity and authority checks

A controller needs enough assurance that it will disclose personal information to the correct person. The ICO permits proportionate identity checks where needed, including confirmation that a representative is authorised¹. The person who receives the request should send such a question promptly. Delaying an identity request merely to gain time would conflict with the requirement to respond without undue delay.

The start date depends on the information actually needed. A recruitment agency might know a current employee well enough to verify them without a new document, while an unfamiliar representative may need to show authority. These are examples of different verification questions, not a universal document list. The ICO advises using existing verification measures when adequate and seeking formal identification only when necessary¹.

A useful log has separate fields for request receipt, identity question sent, identity information received and verification completed. The original message is still relevant evidence even where the response period begins later. For the UK-specific overview of subject access, the rights question is broader; here the point is to make the calendar calculation reproducible.

A justified clarification pause

The Data (Use and Access) Act 2025 changed the UK GDPR timing rule so that a controller can pause the response period when clarification is reasonably required². The ICO explains that the controller must be able to demonstrate why clarification was needed to identify the information or processing activity requested¹. A blanket question sent with every SAR is not enough.

The test is practical. If the organisation can locate and provide the information through a reasonable search, it may not need clarification. If an unclear request spans several distinct areas and a focused question is necessary for an effective response, the controller should ask promptly and explain what needs clarifying¹. It cannot force the requester to narrow a request for all their information¹.

The pause is tied to the information requested. Asking which delivery format the person prefers does not stop the clock¹. The organisation should log the exact clarification question, why it was reasonably required, when it was sent and when the reply arrived. That record distinguishes a justified pause from an ordinary conversation with the requester.

The day a paused clock resumes

The ICO says the clock stops on the day the controller asks for justified clarification and resumes on the day after the answer arrives¹. Count the stopped days and add them to the original deadline. The unit is days, not hours. The ICO even treats a question and answer on the same day as a one-day pause¹.

The ICO's worked example makes the rule visible. A request arrives on 14 May, so its ordinary deadline is 14 June. Clarification is requested on 15 May and arrives on 18 May. The clock runs again on 19 May. Four paused days move the response deadline to 18 June¹.

Calculate the one-month deadline first, then record any justified pause or extension.

In words, the tree branches like this: after receiving a SAR, calculate its one-month deadline¹. If clarification is reasonably required, ask promptly, pause from that day and resume the day after the reply¹^,2. If complexity or multiple requests justify a further two months, explain the extension to the requester within the initial month¹^,3.

Event	Date in the ICO example	Effect
SAR received	14 May	One-month calculation begins¹
Clarification requested	15 May	Pause begins¹
Clarification received	18 May	Last paused day¹
Time resumes	19 May	Work continues¹
Adjusted deadline	18 June	Four days added¹

This is a calculation, not a reason to postpone the search until the last day. The ICO advises asking for clarification as soon as possible. If the need becomes apparent later, the organisation should be able to explain why it could not ask earlier¹.

Extension by two months

A controller may extend the response time by a further two months where necessary because a request is complex or because the person has made a number of requests¹^,3. The ICO calculates that as three months from the original start date¹. It is a different mechanism from a clarification pause. The reasons and dates should therefore be recorded separately.

Complexity requires a case-specific explanation. The ICO says a large quantity of information does not automatically make a request complex, nor does reliance on a processor¹. A controller should note the particular technical, confidentiality or specialist work that makes this request difficult, if it relies on those factors. A number of requests from the same person can include requests concerning other rights¹.

An extension should not become a default for a busy team. The request still needs a response without undue delay¹. The organisation should decide the reason for the extension, calculate the revised end date and tell the person within the original one-month period. If a lawful clarification pause also occurred, preserve both calculations so the final date can be explained.

Notifying the requester of an extension

The ICO says the organisation must tell the person that it is extending the time limit and explain its reasons within one month of the relevant starting event¹. A clear notice identifies the request, the reason this case qualifies, and the calculated revised date. The reason needs to describe the work or requests involved, rather than simply saying the organisation is busy.

The timing of the notice is part of the control. A team might discover that the request is complex near the ordinary deadline; it must still communicate the decision in time¹. The log should record when the notice was sent and retain its wording. That evidence lets another colleague reconstruct the deadline without guessing what happened during the first month.

What this procedure cannot decide for you

No single template can determine whether verification, clarification or an extension is justified for every SAR. Those judgments depend on the actual request, the information held and what can reasonably be found. The ICO's guidance requires a specific reason for a clarification pause and a specific reason for complexity¹^,2. A vague request is not automatically complex, and a complex request is not automatically unclear.

This procedure also does not decide what information must ultimately be disclosed. That is a separate assessment. Its output is a defensible timeline: original receipt, any qualifying later start, a calculated one-month deadline, any justified stopped days, any extension decision and the notice to the person. A colleague should be able to reproduce every date from the record.

What to do next

For each new SAR, open a timeline record and calculate the ordinary calendar-month deadline first. Record any necessary identity or authorisation information and its receipt date. If clarification is reasonably required, write down the reason and the pause dates. If complexity or multiple requests justify an extension, send the person a reasoned notice within the first month¹^,2^,3.