When access requests arrive in volume: what to do first
Answer first. Stop before drafting a single reply and triage the batch. Sort every request by validity, by identity evidence, and by whether it is tied to a dispute, then route anything unusual to one decision-maker. A volume spike is a workload problem and, occasionally, a signal that something else has happened. Treat it as both until you know which, and log each request the moment it arrives.
Basis
The right that generates these requests sits in the data protection framework applicable in Lithuania and Estonia, not in an instrument this note tracks by number, so no article reference follows here. What can be said with confidence is procedural, not textual: the response clock the framework sets starts when a request meeting the identification threshold is received, not when it is read, triaged, or passed to another team.
Two adjacent instruments can attach separately, on their own track, and are worth naming precisely. If the spike coincides with signs that systems holding the data were accessed without authorisation, incident-reporting duties under Directive (EU) 2022/2555 (NIS2) apply on their own timetable, for organisations within its scope. If the triage of the batch itself relies on an automated system that scores or profiles requesters, questions under Regulation (EU) 2024/1689 (AI Act) can arise, depending on how that system is classified. Neither instrument is the source of the underlying right of access.
What changes in practice
A single request is a task. A batch is a process, and processes need an owner. Once volume rises, three things change at once: the risk of missing an identity check goes up, the risk of answering the wrong version of "the records held" goes up, and the risk of one disputed request contaminating the handling of the rest goes up.
The fix is sequencing, not speed. A batch answered in the wrong order — disputed requests first, ordinary ones ignored, coordinated requests treated as separate matters — creates more exposure than a batch answered a day later but in the right order.
| Type of request | Typical marker | First move |
|---|---|---|
| Ordinary access request | Single individual, clear identity, no prior contact history | Route to the standard handling queue |
| Disputed or adversarial | Arrives alongside a complaint, grievance, or claim | Flag to the person handling that dispute before any substantive reply |
| Coordinated or mass | Multiple requests, similar wording, same short window | Check for a common source before responding to each one individually |
| Identity unclear | Details supplied do not match records held | Ask for further identification before treating the clock as confirmed |
What to do
- Log every request on arrival — whoever receives it records the date, the channel, and the identity details, before forwarding it anywhere.
- Separate ordinary requests from disputed ones — the person responsible for data protection sorts the batch within one working day.
- Confirm identity before treating the clock as settled — the handler checks the request against records held and asks for further proof if it does not match.
- Route disputed or coordinated requests to one decision point — a single person decides how those are handled, not the whole team acting separately.
- Draft each response against records actually held, not against what the requester assumes exists.
- Keep a written record of every decision, including why a request was refused, narrowed, or delayed.
Who decides
| Question | Who decides | What they need |
|---|---|---|
| Is the request valid and identified? | The person who normally handles access requests, or the data protection lead | Identity evidence matching the records held |
| Is this request disputed rather than ordinary? | The data protection lead, in consultation with whoever handles the underlying dispute | Context on any live complaint, grievance, or claim tied to the requester |
| Does the batch look coordinated? | The data protection lead | Wording, timing, and channel across the batch |
| Does a security incident sit behind the spike? | Whoever owns incident response, separately from access-request handling | Log evidence on system access, not on the requests themselves |
Scenarios
If every request in the batch reads almost identically, treat it as coordinated rather than as separate enquiries, and check for a shared source before replying to each one on its own terms.
If a request arrives from someone already in an active dispute with the organisation, route it to whoever handles that dispute before any substantive reply is drafted.
If the identity behind a request cannot be confirmed against records held, ask for further proof and treat the response clock as unresolved until it arrives.
Limits
This page resolves sequencing and ownership of the decision. It does not resolve disputes about the substance of what a batch of requests is really about, and it does not cover situations that only look adjacent but sit in a different area of the practice entirely.
A dispute over which side contributed an improvement to licensed technology follows a different path: see When improvements are claimed by both sides and the.
Non-payment by a licensee who keeps selling under an arrangement that should have ended is handled separately: see A licensee stops paying and keeps selling patent in.
A migration stalled by the terms of an exit clause raises its own sequencing questions, distinct from these: see When a migration is blocked by an exit clause.
Custody of reserve assets held outside an issuer's own control is a separate line of questions entirely: see When reserve assets are held by a third party.
Cost factors and timing
What drives the effort in a batch like this is not the number of pages requested. It is the number of separate systems the records sit in, whether more than one jurisdiction is engaged, whether a request is disputed rather than ordinary, and whether an opposing party is already involved.
| Factor | Why it matters |
|---|---|
| Number of systems holding relevant records | Each system adds a separate search and a separate accuracy check |
| Number of jurisdictions engaged | Coordination across teams and, sometimes, across supervisory authorities |
| Whether a dispute is already attached | Disputed requests need review before drafting, not after |
| Whether an opposing party is already involved | Changes how much can be said and how it should be phrased |
We answer the first message within minutes during business hours. A fee estimate follows within one working day, once the batch and its factors are understood.
Verified
Checked against current publicly available guidance as of March 2025. Where this page names an instrument directly, it uses: Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2024/1689 (AI Act). Neither is the source of the underlying right of access; both are named only where they attach separately, on their own track.
Related publications
A related situation, closer to this one in cause: When a vulnerability disclosure is published: what to do.
FAQ
What is the first step when access requests arrive in volume?
Triage before drafting. Sort every request by validity, by identity evidence, and by whether a dispute is attached, and route anything unusual to one decision-maker before any reply goes out.
Which deadline is already running?
The response clock set by the applicable data protection framework starts on receipt of a validly identified request, not once triage is finished. Treat every dated request as already running until confirmed otherwise.
Who decides, and on what evidence?
The person responsible for data protection decides, based on the identity evidence supplied and the records actually held, not on what the requester assumes exists.