From 30-day panic to a repeatable DSAR workflow
Most teams do not miss DSAR deadlines because the work is hard. They miss them because intake, verification and discovery each restart from scratch every time.
A data subject access request is not intellectually difficult. It is a coordination problem with a statutory deadline attached, and coordination problems degrade fast as volume grows. The teams that handle DSARs comfortably are not smarter — they have simply stopped treating each request as a novel event.
Where the 30 days actually go
| Stage | Typical elapsed time | Usual cause |
|---|---|---|
| Intake to acknowledgement | 2–5 days | Request arrived in a shared inbox nobody owns |
| Identity verification | 3–8 days | Ad-hoc back-and-forth over email |
| Locating the data | 7–15 days | No system inventory — every request is a fresh archaeology project |
| Review and redaction | 3–6 days | Third-party data mixed into exports |
| Delivery | 1–2 days | Secure channel improvised per request |
Notice that the largest block is discovery, and discovery is the stage that benefits most from work done before any request arrives. Everything else is process; that one is preparation.
Fix intake first — it is the cheapest win
- One canonical route: a branded portal, linked from the privacy policy, the footer and the preference centre.
- Automatic acknowledgement with a reference number and the statutory deadline, sent on submission.
- Structured capture of request type up front. "Access" and "deletion" branch differently and should never share a queue by default.
- A monitored fallback for requests that arrive by email or post anyway — because they will.
The clock starts on receipt
Not on triage, not on verification. A request sitting unread in a shared inbox for six days has already consumed a fifth of your window.
Verification proportionate to risk
Over-verification is its own compliance failure — you must not collect excessive data to confirm identity, and an onerous process functions as a barrier to a right. Scale the check to what is being asked for.
- 1Authenticated in-product request: session identity is usually sufficient. No extra evidence.
- 2Access request from a known email: a signed one-time link to that address.
- 3Deletion or a request touching sensitive data: step up, and document why the step-up was proportionate.
- 4Request made by an agent or representative: verify the authority, then verify the subject.
Make discovery boring
The difference between a two-week discovery phase and a two-day one is whether you already know which systems hold personal data. That artefact — an owned, maintained inventory of systems, data categories and owners — is the single highest-leverage thing a privacy team can build.
- Every system mapped to the categories of personal data it holds and a named owner.
- A standing fulfilment task template per system, so the request routes automatically instead of being negotiated.
- Known third parties and processors listed alongside, since their data is in scope too.
- Refreshed on a schedule and on system onboarding — a stale map is worse than none, because it is trusted.
DSAR response time is a lagging indicator of how well you understand your own data estate.
What to measure
- Time to acknowledgement — should be minutes, automated.
- Time in verification — the stage most likely to hide a stalled request.
- Percentage of requests fulfilled with zero manual data hunting.
- Requests closed with more than five days of margin. This is your real safety buffer, and it is the number that predicts a missed deadline.