Access request handling: what the decision maker looks at
An access request forces a fixed sequence: log it, confirm the requester's identity, map every system that might hold their data, decide what can be disclosed, and answer inside a set window. The decision maker is judged on two steps — the mapping and the disclosure call — not on the paperwork that surrounds them. Missing the response window is the point of no return; almost everything before that deadline is recoverable, almost nothing after it is.
What changes once a request lands
Once a request is logged, the clock starts regardless of how complete or well-phrased the request is. The organisation cannot wait for clarification before the clock runs; it can seek clarification while the clock keeps running in the background. That distinction trips up more teams than the substance of the request itself.
Scope expands the moment the request lands. Any system, vendor platform, or backup archive holding the requester's data now falls inside scope, including copies kept for reasons that have nothing to do with why the data was originally collected. A record sitting in a decommissioned tool, an old support ticket, or a marketing export counts just as much as the live customer record.
The decision maker's exposure grows with the number of systems and the number of people who can see the data. A request touching one internal database is a different exercise from one touching a customer relationship platform, a marketing tool, and an archived support inbox at the same time. Each additional system adds a mapping task, a redaction risk, and a sign-off dependency.
A second shift happens the moment a request arrives during a live dispute, a contract wind-down, or a supplier disagreement elsewhere in the business. Access obligations do not pause because something else is contested; the decision maker has to run both tracks side by side rather than letting one wait for the other.
Steps the decision maker follows
- Log the request with a timestamp and assign a named owner within the day it arrives.
- Verify the requester's identity before disclosing or even confirming anything about the data held.
- Map every system, vendor, and backup location that may hold the person's data, including decommissioned tools still holding exports.
- Screen each record for third-party data mixed into the same file and redact before anything leaves the organisation.
- Draft the response, route it for internal sign-off, and confirm the deadline has not slipped during review.
- Record the final decision and the reasoning behind any material withheld, in case the requester challenges it later.
Step three is where most delay accumulates. Organisations that keep a live inventory of where personal data sits finish the mapping step in hours; organisations without one spend days chasing individual system owners for confirmation.
Who makes the call, and by when
The named decision maker inside the organisation approves the final disclosure. It is not the front-line handler who first received the request, and it is not whoever happens to be free when the deadline approaches. That separation matters because the disclosure decision — what stays in, what gets redacted, what gets withheld and why — carries the compliance risk, while the intake step carries only an administrative one.
Where the request touches a licensing arrangement that is heading toward closure, the decision maker coordinates with whoever runs the Termination and wind-down process. Access obligations and contract wind-down close on different clocks, and treating them as one track produces the wrong answer on both.
The table below sets out where delay typically originates, by stage.
| Stage | Typical owner | What can stall it |
|---|---|---|
| Intake and identity check | Front-line handler | Incomplete proof of identity |
| Data mapping | IT or data owner | Undocumented storage locations |
| Redaction of third-party data | Decision maker | Mixed records with no clear split |
| Internal sign-off | Decision maker | Review queue backing up near the deadline |
| Dispatch and logging | Front-line handler | No record kept of what was withheld and why |
Common branches
If the request arrives while a third party is disputing rights over the same dataset, keep the two tracks separate. Disclosure obligations do not pause for a dispute, and the reasoning applied in When the other side moved first in this situation shows why waiting for the dispute to settle is the wrong instinct even when it feels safer.
If the data sits inside software built on open-source components, the mapping step should record which component holds which field, not just which application does. The same discipline of tracing data by component rather than by application is described in How open source compliance review technology contract what the.
If the organisation issues tokens and the request touches a holder's wallet history, coordinate with whoever tracks Supply change procedure token issuance what the decision maker, since supply records and access records can diverge sharply after a supply change and reconciling them after the fact is slower than checking before responding.
If none of these branches apply and the request is a straightforward employee or customer file, the standard six-step sequence above is enough on its own, and the decision maker's only real judgement call is the redaction step.
What this page does not cover
This page does not set the exact deadline, the exact fee threshold, or the exact grounds for refusal. Those figures depend on the data protection regime that applies to the organisation, and they sit outside procedural guidance by design. It also does not cover how long data should be kept before any request arrives — that decision is made earlier, when the record is created, and it shapes how large the mapping task in step three ends up being.
For the earlier decision on how long records are kept in the first place, see How retention schedule design data protection what the decision.
Verified
Reviewed 2025. This page sets out the procedural sequence only. It does not cite specific articles, regulations, or national provisions, because the national registry entry for this jurisdiction is not yet populated on this layer of the site.
FAQ
How long does access request handling take in practice?
The internal steps — intake, verification, mapping, redaction, sign-off — usually take a few working days when systems are well documented and the inventory is current. The statutory response window runs in parallel to these steps and is fixed by the applicable regime, not by how long the internal work actually takes.
Which documents are needed to start?
Proof of the requester's identity, a record of exactly when and where the request arrived, and an index of systems likely to hold the person's data. Without that index, the mapping step has no starting point and tends to expand under time pressure rather than shrink.
What happens if the other side does not respond?
If the requester does not answer a clarification question, the organisation still has to respond within the window, based on what it can establish without the missing information. Silence from the requester is not, on its own, grounds to extend the deadline.