Access request handling: stages and deadlines

An access request under data protection law moves through five fixed stages: intake, verification, scoping, response preparation, and closure. The controller must act within the deadline the law sets, extendable once for complex cases. Missing that deadline turns a manageable task into a compliance failure with its own consequences.

What changes once a request lands

Once a request is logged, a clock starts that the organisation does not control and cannot pause at will. Every calendar day counts toward the deadline, including days spent chasing internal records, waiting on a supplier, or deciding who owns the file. Silence is not a safe default: an unanswered request is treated in law the same way as a refusal, and a refusal carries its own notice requirements that a delay does not excuse.

The practical shift is from "find the data eventually" to "account for every day spent looking." A request that touches several systems, several departments, or several countries runs on the same clock as a request confined to one file. The deadline does not stretch to match the complexity of the search; only the single permitted extension does, and it has to be used deliberately, not discovered on the last day. Treat the first day of the clock as the day the request is understood well enough to act on it, not the day it happens to be opened or forwarded.

Two consequences follow from this. First, the file needs a visible owner from the first hour, because a request with no owner drifts until someone notices the deadline is close. Second, every step taken — and every step skipped — needs a timestamp, because a dispute about timing is decided on the record, not on memory.

What to do

1. Log the request the day it arrives, and assign a named owner — usually the privacy lead — so the clock has one visible custodian rather than several people assuming someone else has it.
2. Verify the identity of the requester before touching any record connected to them; a request answered to the wrong person is a separate incident on top of the original one.
3. Map every system and contractor that could hold the requested data, including open-source components that process personal data as part of the product; the inventory habit mirrors Open source compliance review: stages and deadlines.
4. If a supplier holds part of the data set, notify them under the existing processing agreement rather than asking informally; the same coordination model runs through Supply change procedure step by step in practice.
5. Screen for exemptions, third-party data mixed into the same record, and confidentiality limits before drafting anything, since removing material after drafting is slower and riskier than excluding it from the start.
6. Draft, review, and send the response within the deadline, or issue a reasoned extension notice before the original deadline runs out, then close the file with a dated record of exactly what was disclosed.

Who decides

The actors below typically own each stage, though the exact allocation shifts with the size of the organisation and how many teams touch personal data day to day.

Escalation moves the decision outside the organisation entirely. Once a complaint reaches the supervisory authority, the internal timetable that governed the first four stages stops controlling the outcome, and a separate procedure with its own pace takes over.

Common forks

Three recurring situations change the shape of the file and are worth flagging before they arrive rather than after.

If the requested data sits inside a dataset licensed from a third party, check whether that licence is still in force before disclosing anything drawn from it. Disclosing data under a licence that has already lapsed creates a second problem layered on top of the first. The same close reading of licence terms applies when How termination and wind-down IP licence runs in practice.

If the requester disputes the response and takes the matter to a regulator, the internal clock stops being the relevant measure and a different procedure, with different stakes, begins. The same shift in stakes shows up when When the other side files revocation first: the deadline.

If the volume of data is unusually large, or the request repeats one already answered in full, document the reasoning for any delay or refusal at the moment the decision is made. Reasoning written after the fact reads differently, and a regulator asked to review it will notice the gap.

What this page does not cover

This page sets out stages, actors, and the point where a delay turns into a missed deadline. It does not state the exact number of days available to respond, because that figure depends on the specific law that applies to the organisation and can change over time. It does not list every category of data that may be lawfully withheld, and it is not a substitute for someone reading the actual request before deciding how to answer it. Two similarly worded requests can require very different handling depending on what they actually ask for.

Verified

Reviewed: December 2024. Primary sources: internal procedural checklists used across the data and security practice, together with published guidance from the national supervisory authorities responsible for data protection in Lithuania and Estonia.

Related reading

The same stage-by-stage discipline applies to keeping the underlying data inventory current, which is what makes a fast response possible in the first place. See How retention schedule design data protection runs in practice.

FAQ

How long does access request handling take in practice?

The exact number of days depends on the law that applies to the organisation, and it is not fixed on this page because it varies by jurisdiction and can be revised. What stays constant is the logic: the clock starts once the request is properly logged, one extension is normally available for genuinely complex cases, and that extension has to be communicated to the requester before the original deadline runs out, not after it has already passed.

Which documents are needed to start?

Three things, at minimum: a dated record of receipt, proof of the requester's identity, and a written note of exactly what is being asked for. Without these, the clock is running, but the file has nothing to show for it if the timing is later questioned by the requester or by a regulator.

What happens if the other side does not respond?

If the requester does not provide the identity documents asked for, the clock pauses until verification is complete — it does not keep running against the organisation while the request sits unverified. If a supplier or contractor fails to respond to an internal request for data, escalate through the existing processing agreement rather than waiting. If the deadline is genuinely at risk as a result, tell the requester about the delay and the reason before the deadline passes, not after it has already gone.

Related situations

These situations tend to surface around the same file once an access request is underway.

• When source code escrow is demanded in practice
• When the contract term outlives the product in practice
• Security duties reach you as a supplier data protection

— Rasa Tumenaite, AURELIS