Separate targets from conclusions
Suggested dates are workflow aids. They should help the team notice aging cases, upcoming deadlines, and blocked work without deciding legal obligations automatically.
- Label suggested dates as team guidance, not legal conclusions.
- Require documented rationale for pauses or exceptions.
- Keep jurisdiction details reviewable by the team.
| Context | Published baseline | Operational caution |
|---|---|---|
| EU GDPR | Without undue delay and generally within one month | Article 12 contains conditions for extensions; review the actual rule |
| UK access request | ICO explains calendar-month calculation and identity/authorisation dependencies | A month is not always 30 days |
| California know, delete, or correct | CPPA states confirmation within 10 business days and substantive response within 45 calendar days | Other request types and exceptions may differ |
Use deadline status for prioritization
Teams need to know what is due soon, overdue, blocked, or waiting on requester input. Deadline status should be visible in the case inbox and on each case.
- Filter cases by due soon, overdue, and blocked.
- Show verification and clarification holds separately.
- Use reminders for work that needs human attention.
Record changes as part of the case
If the target date changes, the record should explain what changed and why. This keeps the timeline clear for later review.
- Record who changed a deadline and when.
- Attach rationale to pauses, escalations, and exceptions.
- Review aging cases before they become urgent.
Example: a case is waiting on a system owner
A request is approaching its target date, but one evidence task is still open. Changing the case status alone does not solve the delay. The owner needs to identify the missing work and decide whether to escalate.
- Record which system or decision is holding up the response.
- Give the outstanding action to a named person and agree when it will be checked again.
- Keep any change to the target date separate from the reason work is delayed.
Make every date change understandable
A useful note tells another responder why the working date changed and what was reviewed. A vague note such as "extended" leaves the next person guessing.
- Record the previous and new working dates along with the reason for the change.
- Name the person responsible for reviewing the timing decision.
- Do not assume that waiting for information automatically changes a legal deadline; have the appropriate person review the circumstances.
Calculate from the rule, not a universal day count
Under GDPR Article 12, the general outer limit is one month after receipt, with a possible further two months where necessary because of complexity or number, provided the person is informed within the first month and given reasons. ICO guidance for UK access requests says to count to the corresponding calendar date; if it does not exist, use the month's last day, and move a weekend or public-holiday end date to the next working day.
- EU example assumption: received March 10; the general one-month date is April 10. Confirm local law and facts before relying on it.
- UK ICO example: received January 31, 2026; the corresponding date does not exist in February, so the month ends February 28, 2026, a Saturday, and moves to Monday, March 2 under the published guidance.
- Record receipt, the rule consulted, calendar method, jurisdiction assumption, target, reviewer, and any notice separately.
Keep California clocks and request types separate
The CPPA FAQ states that businesses confirm receipt of requests to know, delete, or correct within 10 business days and substantively respond within 45 calendar days. The California Attorney General says an additional 45 days may be available with notice for requests to know; opt-out requests follow a different operational time frame. Check the current regulation and request type before using an extension.
- Example assumption: a know request received September 1, 2026 has a 45-calendar-day working date of October 16, 2026; separately calculate the 10-business-day confirmation using the applicable holiday calendar.
- Do not restart the 45-day response clock after verification; California guidance says verification can occur within that period.
- A combined message may require parallel tracks rather than one date copied across every requested right.
Sources
Sources checked September 20, 2026. These primary and regulator materials support the legal-rule summaries above; check the current rules that apply to your organization.
- EU General Data Protection Regulation, Articles 12 and 15 — Primary text for access rights, transparent communication, identity questions, and response timing.
- ICO: responding to a right-of-access request — Official UK guidance on calendar-month calculations, clarification, extensions, and proportionate identity checks.
- California Privacy Protection Agency: frequently asked questions — Official operational summary, including confirmation and response time frames for requests to know, delete, and correct.
Common questions
Can software calculate DSAR deadlines automatically?
Software can suggest target dates, but teams should treat legal timing and exceptions as human-reviewed decisions.
What deadline statuses should a DSAR workflow show?
Useful statuses include unassigned, due soon, overdue, blocked, waiting on verification, waiting on requester, and pending approval.
Why document deadline exceptions?
Documentation helps future reviewers understand why a request paused, moved, escalated, or took longer than expected.
Run privacy requests in one controlled workflow
Privacy Requests helps teams manage intake, verification, tasks, response preparation, secure delivery, and audit history without a broad enterprise suite.
Start free