GDPR data subject request flowchart (DSAR, receipt to closure)
GDPR data subject request process flowchart: log it and start the one-month clock, verify identity, triage the right, search systems and processors, redact third-party data, extend where complex, respond and record the decisions.
What the gdpr data subject request flowchart (dsar, receipt to closure) process is
Almost nothing goes wrong with a data subject request in the part people rehearse. The failure is at the front. The request arrives as one line at the end of a complaint email, in a chat with a support agent, or in a phone call to a branch, and it sits with somebody who does not know that a statutory clock started the moment it was received. By the time it reaches the privacy team half the month is gone and the search has not begun. The second failure is treating the request as a legal exercise when it is mostly a search-and-redaction exercise: the work that takes the time is finding every system that holds the person's data, and then reading what comes back for other people's information. Identity verification is where the third failure hides, because a proportionate check protects the data subject, while an escalating demand for documents is a delaying tactic that regulators recognise on sight. A process that fixes those three things answers most requests comfortably inside the month.
This chart is the statutory route a member of the public takes (a customer, a former employee, a job applicant, somebody who once filled in a form) when they exercise a right under the GDPR. It is not the internal route an employee takes to get hold of a dataset for their work: that is an ordinary business approval with an owner, a purpose and a licence at the end of it, and it lives at /templates/data-access-request-process. It is not the route to a system or an account either, which is approval, segregation of duties and provisioning, at /templates/access-request-process. And it is the mirror image of /templates/data-breach-response-process: that chart runs the Article 33 and 34 notification duty on a 72-hour clock when you have lost control of personal data, while this one runs a one-month clock when a person asks you to account for it. The privacy notice, retention schedule and record of processing this chart leans on are governing documents, and their drafting, approval and review cycle is /templates/document-control-process.
Three things most written procedures leave implicit are drawn here as boxes. "Identity confirmed?" has three branches rather than two (Confirmed, Need more evidence, Not established) so asking for evidence loops back to the same test instead of quietly becoming an indefinite hold, and a request that is never substantiated has a named ending at "Closed: identity not established" rather than fading out of an inbox. "Manifestly unfounded or excessive?" is answered once, early and in the open, because Article 12(5) puts the burden of showing it on the controller, and a refusal reached in the last week looks exactly like a refusal reached because the month ran out. And "Complex or numerous requests?" sits before the response is compiled rather than after, because the two-month extension only exists if the requester was told about it, with reasons, inside the first month. Everything downstream converges on one closure spine: disclose in full, redact, refuse in part or refuse outright at "Refuse with reasons and complaint rights", and the request is still written up at "Record the request and the decisions" and can still be escalated, because a refusal nobody logged is the one a regulator hears about first.
What this flowchart covers
In this template
- Five lanes (Data subject, Privacy intake team, Data protection officer, Legal counsel, System and data owners) laid across five phases: Intake, Identity check, Triage and scope, Search and review, and Response and closure.
- An intake that assumes the request can arrive anywhere: "Request received on any channel" feeds "Log the request and start the clock", which fixes the date of receipt the deadline runs from, and then "Acknowledge receipt and set expectations".
- A three-way "Identity confirmed?" decision, where the evidence branch loops back through "Ask for proportionate identity evidence" to the same test, and the third branch gives an unsubstantiated request the honest ending "Closed: identity not established".
- Triage of the right actually being exercised, then "Manifestly unfounded or excessive?" answered early with the burden of proof on the controller, its Yes branch running through "Refuse with reasons and complaint rights", and a "Scope clear enough to search?" test that permits one narrow clarifying question.
- The search and review spine: "Search systems, backups and processors", "Review third-party data and privilege", "Apply exemptions and refusal grounds", and a "Complex or numerous requests?" test routing into "Extend by two months and explain why".
- One closure spine that refusals rejoin: "Rectification, erasure or restriction?" adds "Action it and notify each recipient", every answered request is written up at "Record the request and the decisions", and "Requester challenges the outcome?" separates "Request closed within the deadline" from "Escalated to the supervisory authority".
When to use this template
- You are writing or refreshing a data subject request procedure and need one page that shows who logs, who verifies, who searches, who redacts and who signs the response.
- Your requests keep arriving in support inboxes, on social channels and at reception, and you need the clock to start at receipt rather than at the moment the privacy team hears about it.
- You are training front-line staff, whose only job in this process is to recognise a request for what it is and pass it on the same day.
- You have missed a deadline, or taken an extension late, and you want the complexity test placed before the response is compiled instead of after.
- An auditor, a customer or a supervisory authority has asked you to show a documented procedure, and you need the redaction and exemption steps to be visible as steps somebody owns.
How it works
Rename the lanes to your own roles
Replace Data subject, Privacy intake team, Data protection officer, Legal counsel and System and data owners with the roles you actually have. Many organisations have no DPO and no in-house counsel: merge those two lanes into a privacy lead and name the external firm you brief for the hard calls, rather than drawing a reviewer who never reviews. Keep the system and data owners lane separate whatever your size, because the search is performed by the people who run the systems and not by whoever owns the process.
List every channel a request can arrive on
A request does not have to be in writing, does not have to mention the GDPR, and does not have to reach the privacy team. Write down each route it really takes — support inbox, contact form, social media, phone, post, reception, a line manager, a solicitor's letter — and give each one an owner whose instruction is to forward it the same day without assessing it. Then decide the single place requests are logged, so the date of receipt exists in one system rather than in somebody's sent items.
Write your identity rules before you need them
Decide in advance what verification each category of requester gets: an authenticated account holder, a former employee, a third party acting under a power of attorney, a parent asking on behalf of a child. Say which evidence closes which doubt, how long you keep it and when it is deleted. Then record your position on whether asking for identity evidence pauses the clock, because guidance differs between regulators, and the position you take needs to be consistent and written down rather than decided per request.
Build the system inventory the search depends on
"Search systems, backups and processors" is only as good as the list behind it. Take your record of processing activities and turn it into a search checklist naming each application, mailbox, shared drive, ticketing system, CCTV estate, call recording archive and processor, with who runs the search and how long it takes. Add your standing position on backups and archives. A checklist means the same request produces the same result twice, which is the thing a regulator actually probes.
Set the redaction and exemption standard
Attach your criteria to "Review third-party data and privilege" so redaction is not improvised: when a third party's data can be disclosed, when consent is sought, when it is reasonable to disclose without it, and how legal professional privilege is claimed and by whom. List the exemptions you rely on in your own jurisdiction and require the reason to be recorded against each withheld item. Redactions made without a written reason cannot be defended months later by somebody who was not there.
Put internal dates inside the month, then publish it
Work backwards from the deadline and give each step its own target date: search complete by day ten, review complete by day eighteen, sign-off by day twenty-four. The statutory month is the outer limit, not the plan, and the extension decision has to be taken while there is still time to communicate it. Then walk the chart through with the intake team, a system owner and whoever signs the responses, correct it to what they really do, and publish that version while keeping the earlier ones.
Frequently asked questions
What are the steps in a GDPR data subject request process?
Receive the request on whatever channel it arrives on, log it and start the one-month clock from the date of receipt, acknowledge it, verify the requester's identity proportionately, triage which right is being exercised, test whether the request is manifestly unfounded or excessive, agree the scope and ask a narrow clarifying question only if you genuinely need one, search every system, backup and processor that could hold the data, review the result for third-party information and privilege, apply any exemptions and record the reason for each, decide whether the request is complex enough to need the two-month extension and tell the requester if it is, compile the response with its reasons, deliver it securely to the verified person, record the request and every decision taken on it, and tell the requester how to complain if they are unhappy. The steps that get skipped are triage and the redaction review, and both are the ones that produce complaints.
How long do you have to respond to a data subject access request?
One month. Article 12(3) of the GDPR requires the controller to provide information on action taken without undue delay and in any event within one month of receiving the request. That is a calendar month rather than a count of working days, so it runs to the corresponding date in the following month — the last day of that month where there is no corresponding date, and the next working day where the corresponding date falls on a weekend or a public holiday. It can be extended by a further two months where the request is complex or where the same person has made a number of requests, but only if you inform the requester of the extension and the reasons for it within the first month. Regulators differ on whether the clock is paused while you wait for identity evidence or for clarification of scope, so record which position you follow and apply it consistently. In practice the deadline is rarely lost in the search. It is lost in the days between the request arriving somewhere in the business and reaching the person responsible for answering it.
Can you refuse a data subject request?
Sometimes, but rarely on the grounds people reach for first. Article 12(5) allows a controller to charge a reasonable fee or refuse to act where a request is manifestly unfounded or excessive, and the burden of showing that sits with the controller. Broad, inconvenient, or made in the middle of a dispute is not the same as excessive. Beyond that, national law provides exemptions that let you withhold specific material rather than refuse the request as a whole, and the erasure right in Article 17 is qualified: paragraph 3 preserves data you are legally required to keep, or that you need to establish, exercise or defend a legal claim. A refusal is not silence. You still have to reply within the deadline, explain the reasons, and tell the person they can complain to a supervisory authority and seek a judicial remedy. This chart therefore draws refusal as a step that produces a reply, is logged alongside every other outcome and can be escalated, rather than letting a refused request drop quietly out of the process.
What do you do about other people's data in the response?
An access request is a right to the requester's own personal data, not to a copy of every document that mentions them, and the two are easy to confuse when the material is email threads, complaint files or appraisal notes. Article 15(4) says the right to obtain a copy must not adversely affect the rights and freedoms of others. In practice that means three options for each piece of third-party information: redact it, ask that person for consent to disclose, or judge that disclosure is reasonable without consent taking account of what the data is, whether the person is under a duty of confidentiality, and whether they have refused. Record which option you took and why. Do the review once on the compiled set rather than system by system, have one named person sign it off, and keep an unredacted copy of what was reviewed so the decision can be explained if it is challenged.
How is this different from a data access request process flowchart?
They answer to different authorities. The data access request process at /templates/data-access-request-process is an internal one: an employee or a team asks for access to a dataset in order to do their job, and the organisation decides on the basis of purpose, sensitivity, lawful basis and licence terms, then grants a scoped, time-bound entitlement it can withdraw. There is no deadline other than the one you set yourself, and you may simply say no. This page is a statutory right exercised by a member of the public. The deadline comes from Article 12(3) rather than from a service level, the outcome is a package of information handed over rather than a permission granted, and the person on the other side can complain to a supervisory authority if you get it wrong. If you are governing who inside the company may query a table, use the internal template. If somebody outside is asking what you hold about them, use this one.