A workflow is only useful if each state has an exit condition somebody can check. Without that it is a set of labels people move around a board. These are the five states a request actually moves through and what has to be true to leave each one.
Received: the date is recorded
Exit condition: the receipt date and the channel it arrived on are written down. Not the date somebody noticed. The whole deadline is measured from this field, so a workflow that starts at triage has already lost days it cannot get back.
Identified: you know who is asking
Exit condition: a recorded basis for believing the requester is who they say. In most cases that is the account the request came from. Note the date identification completed even where the clock does not pause, because the gap between receipt and identification is the part you will be asked about.
Scoped: you know what was asked for
Exit condition: the request is classified as access, deletion, correction, portability or opt-out, and the date range and systems in scope are stated. Vague requests get scoped by asking, and the question and answer both belong in the record.
Searched: you know where you looked
Exit condition: a list of systems searched with a date and a person against each. This is the state most workflows skip and the only one that produces evidence. It is also where the real elapsed time goes.
Answered: it went out, and you can prove it
Exit condition: what was released, what was withheld and on what basis, who approved it, and the date sent measured against the deadline. California allows 45 days from receipt with one 45-day extension on notice; the GDPR allows one month with a two-month extension.
Extended: the clock was stretched, and the record says so
A sixth state, used rarely and recorded always. Both regimes allow an extension where the request is complex or numerous, and both require the person to be told inside the original period, with the reasons. The exit condition for entering it is a notice sent to the requester, dated inside the first period, stating the new deadline and why. A workflow that lets a request simply run over, with an email sent on day fifty explaining the delay, has not extended anything; it has missed the deadline and then apologised. The record holds the extension notice with its date beside the original deadline, so the answer is measured against the right clock.
At ten requests a year, drawn
One person owns intake and reads every inbox that a request could arrive in. Every request gets a row on the day it arrives, with the receipt date and channel. Identification and scoping happen within the first week and are written down. The search is a checklist of the systems the data map names, worked over two or three weeks, each line signed and dated. The answer is drafted, approved by a second person, sent, and the row closed with the dates. Ten rows a year, five states each, forty dates. That is the whole workflow at the size most companies actually are, and the record on this site is those rows with the clock counted from receipt.
Questions people ask about dsar workflow
Should the clock pause during identification?
Do not build on the assumption that it does. Regimes differ and the safe design counts every day from receipt, so a delay in identification eats your own slack rather than the requester's.
How many people should touch a request?
As few as possible, with one named owner. What matters more than the count is that each action is recorded against the person who took it, because that is what an audit reconstructs.
What does a good workflow look like at ten requests a year?
A logged receipt date, a named owner, a searched-systems list and a sent date. That is genuinely enough at that volume, and the reason to put it in a tool rather than a spreadsheet is that a tool cannot forget the receipt date.
When is the acknowledgement due, and what does it say?
California requires confirmation of receipt within ten business days, saying how the request will be processed. The GDPR does not fix a day for it but expects the person to be kept informed. The acknowledgement says the request was received, on what date, what will happen next and by when, and it is the first entry after the receipt date in the record.