dsar_response_workflow v1.0.0

name: dsar_response_workflow description: "Run a data subject access request from intake to delivery: recognise the request in any form, set the statutory clock by regime with a deadline calculator, verify identity in proportion to the risk, search systems and mailboxes on a logged and reasonable search, make redaction and exemption calls record by record, and deliver a response pack that documents every decision. Covers EU and UK GDPR, California CCPA and CPRA, the Virginia pattern US state laws, Brazil LGPD, and Canada PIPEDA. Ships timeline tables, a search log, a decision log, a cover letter template, and a worked request end to end. Use when someone asks to handle, answer, or audit a DSAR, SAR, subject access request, request to know, or consumer access request, or to set up the process for one."

DSAR Response Workflow

Purpose

A data subject access request is a person asking an organisation what personal data it holds about them and for a copy of it. The names vary by regime: DSAR or SAR under GDPR, request to know in California, consumer access request under US state laws. The job is the same each time. Find the data, protect everyone else in it, answer on the statutory clock, and leave a file that shows how every call was made.

This skill runs one request end to end, and it also works as the setup pattern for a standing process. It gives you:

• A recognition test so requests that arrive as a plain email, a phone call, or a social media message get caught on day one
• A regime table with the clock, extension, fee, and appeal rules, plus a calculator that does the date maths
• Verification tiers scaled to what the requester will receive
• A search method with a log, so reasonable and proportionate is provable later
• Redaction rules and an exemption checklist, applied record by record
• A response pack format with a cover letter that carries the supplementary information the law lists
• A worked request that shows the whole run on real dates

Treat this workflow as general information about process. Refusals, privilege calls, and contested exemptions need review by the Data Protection Officer or qualified counsel in the regime that applies. Deadlines and exemption lists in the references were checked against regulator guidance and statute text in October 2026. Laws in this area change, so confirm the clock for the regime in front of you before you diary it.

Workflow

1. Recognise the request and open the case file

• Treat a request as valid when it is clear the person is asking for their own personal information. No set wording is required. The person does not need to name the law, use a form, or write to a privacy address. A request can be verbal, written, or sent through social media, and any staff member can receive one.
• Train the front doors. Support, HR, sales, and anyone who answers phones or inboxes needs to know the recognition test and the rule that the request goes to the case owner the same day. Most blown deadlines are really recognition failures from week one.
• Open a case file on the day of receipt with: the request exactly as received, the channel, the date and time, the requester contact route, and a case reference. Log receipt before you judge quality. A messy request still starts the clock in most regimes.
• Check who is asking. The data subject, or a third party with authority to act for them. For a third party, the third party proves authority: a signed authorisation, a power of attorney, or a solicitor on record. For a child, judge competence and best interests under the local rule before answering a parent or the child. Record the check.
• Acknowledge receipt fast. California requires confirmation within 10 business days for know, delete, and correct requests. Everywhere else, a prompt acknowledgement with the case reference, the deadline you are working to, and what happens next is good practice and calms repeat chasing.

2. Set the clock before anything else

• Name the regime. Use references/regimes.md to pick it from where the requester lives and which entity controls the data. If the requester is an employee, a patient, or a student, check whether a sector rule changes the content list.
• Run the calculator and write the dates into the case file:

python3 bin/dsar_deadline.py --regime gdpr --received 2026-03-02
python3 bin/dsar_deadline.py --regime ccpa-know --received 2026-03-02 --extension

• Know the shape of your clock. GDPR gives one calendar month, plus two months for complex or multiple requests if you notify inside month one. California and the Virginia pattern state laws give 45 calendar days, plus 45 with notice inside the first period. Brazil LGPD gives 15 days for the full declaration, with a simplified answer available at once. Canada PIPEDA gives 30 days, plus up to 30 more in set cases with written notice.
• Handle pauses honestly. Identity proof and, in the UK, a clarification question can stop or delay the start of the clock under the rules in the regime file. Ask on day one. A clarification question asked on day 25 reads as stalling because it usually is.
• Never let an extension be a surprise. If search volume or complexity will need the extension, send the notice inside the original period, give the real reason, and give the new date. Diary both dates and work to the first one until the notice is sent.
• If you are a processor for this data, stop. You do not answer the requester. Notify the controller at once, help with the search under your contract, and tell the requester which organisation is the controller and how to reach it.

3. Verify identity in proportion to the risk

• Verify before you search in depth and always before you disclose. Sending one person's data to another person is a personal data breach, and it is the worst outcome this workflow can produce.
• Match the check to the sensitivity of what will be sent and to the relationship you already have:
• Known account holder, low sensitivity: re-authentication through the existing account, or confirmation sent to the contact address already on file
• Known person, no account, or medium sensitivity: match the details the requester gives against details already held, such as account number, recent transaction, or address on file
• High sensitivity (health, finance, precise location, data about children), a changed contact route, or any sign of impersonation: stronger proof, which can include a formal identity document. Ask for the least that settles it. Photograph or copy of a document is a last step, not a first step
• Use the California tiers where CCPA applies. Categories requests: reasonable certainty, which matching at least two data points can meet. Specific pieces: reasonably high certainty, which matching at least three data points plus a signed declaration under penalty of perjury can meet. Deletion: scale between the two by sensitivity and by the harm a wrongful deletion would cause. Opt out requests are not verified.
• Ask promptly, ask once, and list exactly what you need. Do not collect extra personal data to prove identity and then keep it. Verify, record the method and the result, and delete copies of identity documents once the case closes unless a rule requires keeping them.
• If verification fails, write and say what failed, what the person can provide instead, and that the request stays open or is declined under the named regime rule. In California, an unverifiable request can be denied, and the response must say so.

4. Scope the request

• Clarify only when you need to. If you hold a large amount of data about the person, or the request is vague about dates, accounts, or topics, you may ask what they need. You cannot force a narrower request. If they restate the full request, run the full search.
• Record the scope you agreed or, where there was no reply, the scope you applied and why it is reasonable: date range, accounts and aliases, systems in scope. Note known gaps by name, for example a mailbox deleted under a retention policy in 2024, so the cover letter can address them before the requester does.
• Check for siblings. A request that says access may also carry rectification, erasure, or objection inside it. Split each right into its own tracked task with its own clock where the regime sets one, and tell the requester you have done so.

5. Search, and log the search as you go

• Search where the data actually lives, not where the org chart says it should live. The usual set: CRM and product database, support tickets, email mailboxes including shared boxes and leavers, email archive, HR system and personnel file, finance and billing records, call recordings and chat transcripts, marketing platform, documents and shared drives, and any processor or vendor who holds data for you.
• Copy assets/search-log.csv into the case file and fill one row per system: owner contacted, search terms, date range, date searched, hits, and what was found. Search terms should include name variants, every email address, account and customer IDs, phone number, and old addresses where the system indexes them.
• The legal standard in GDPR terms is a reasonable and proportionate search. You do not have to search in ways that are unreasonable or disproportionate to the importance of the information, and you do have to be able to show what you did. The log is that proof. An empty row with a date and a search term beats a confident claim that nothing exists.
• Chase processors in writing on day one of the search, with a reply deadline inside your own clock. Log the sent date and the reply date. Their silence does not extend your deadline.
• Backups and archives: state your position in the log. A common defensible line is that live systems are searched and backup media is restored only if live data is lost or the requester shows a specific gap, because backups are overwritten on a short cycle. Whatever line you take, write it down and apply it the same way every time.
• Dedupe and sort as you collect. Keep one master copy set, unedited. All redaction and export work happens on copies.

6. Review, redact, and decide record by record

• Work through the collected set with assets/decision-log.csv. One row per record or per coherent group: what it is, whether it holds third party data, the decision, the ground or test applied, who decided, and the cover letter line that explains it.
• Follow the order in references/redaction-and-exemptions.md: requester's data or not, mixed data and the three step third party test, exemption or withholding ground, disclose if neither applies.
• Redact with craft. Burn redactions into the file so the text underneath is gone, test the output by selecting and searching it, strip metadata and tracked changes, redact consistently across the whole pack, and keep the unredacted master and the redaction key apart from the delivered files under restricted access.
• Get a second reviewer to sample the pack before delivery. They search for withheld names across every file and spot check that the requester's own data survived review. Log the check.
• Escalate these calls every time: legal professional privilege, health data with a serious harm question, safeguarding or child related records, live litigation or a live negotiation with the requester, and any full refusal. The escalation and its outcome go in the decision log.

7. Build and deliver the response pack

• The pack has three parts. One, the cover letter from assets/cover-letter-template.md, adapted to the regime. Two, the copy of the personal data in a commonly used format, electronic if the request arrived electronically or the requester asked for that. Three, an index or schedule so the requester can match files to the letter.
• The GDPR and UK cover letter must carry the Article 15 supplementary list: purposes, categories, recipients or categories of recipient, retention period or criteria, the other rights and how to use them, the right to complain to the supervisory authority, the source of data not collected from the person, and automated decision making information where it exists. The California letter carries the categories, sources, purposes, and third party list for the lookback period instead. The regime file has both lists.
• Address the gaps head on in the letter. Data the requester named that you did not find, systems you could not search, and anything withheld with its ground, each in plain language. A letter that admits a gap closes a complaint. A letter that hides one starts it.
• Run assets/response-pack-checklist.md end to end before sending. Then deliver securely: encrypted pack or secure portal with download rights, password or key by a separate channel, delivery address confirmed against the verification record.
• Close the file properly. The case file keeps the request, the verification record, the clock calculation, the search log, the decision log, the cover letter as sent, and the delivery log. Set a retention date for the case file itself and honour it.

8. Worked example, one request end to end

Facts. On Monday 2 March 2026 a former customer emails support from a new email address: please send me everything you hold about me, including support calls. Nobody in support recognises it as a DSAR until Wednesday. That two day gap is the first lesson of the case: the clock started Monday.

Regime and clock. The requester lives in the UK, so UK GDPR applies. The calculator gives:

$ python3 bin/dsar_deadline.py --regime uk-gdpr --received 2026-03-02
regime: uk-gdpr
clock_start: 2026-03-02
response_due: 2026-04-02 (one calendar month)

Verification. The new email address is a risk flag. The case owner replies on 4 March asking the requester to confirm the account number and the address on file, and to reply from the original account email if they still have it. They reply on 6 March with the account number, the address, and the last order date, all matching. Under ICO guidance the clock runs from receipt of the identity information, so the file records a revised start of 6 March and a due date of 6 April, and the letter will say so plainly. The check asked for no identity document, because three held data points settled it.

Search. The search log ends with nine rows. CRM: full account record. Product database: usage logs for 14 months, the retention limit. Support platform: 23 tickets. Mailboxes: 41 emails across support and billing shared boxes. Call platform: 6 recordings with transcripts. Marketing platform: profile and campaign history. Finance: invoices, no card data held. HR system: no hits, correctly, the requester was never staff. Processor: the call platform vendor confirms in writing on 12 March that it holds no copies beyond the export already taken.

Review. 312 pages and files after dedupe. Decision log highlights: call transcripts disclose with agent surnames removed under third party step 1, because the content is about the requester and the surnames add nothing. One internal email chain about a billing dispute is disclosed in part: the requester's data stays, a paragraph setting out the settlement position in a live negotiation is withheld under the negotiations ground, logged with the DPO as decision maker. Two pages of a complaint investigation that name another customer are withheld under the third party test step 3, with the balancing factors written out. Nothing else is withheld.

Delivery. The pack goes out on 1 April, inside both the original and the revised dates: cover letter with the Article 15 list, a schedule of 9 sections, data as PDF and CSV, recordings as MP3 with transcripts. Password by text message to the number on file. The letter names the two gaps the requester is most likely to ask about: usage logs older than 14 months no longer exist under the retention policy, and the two withheld pages with the ground. Case file closed with a retention review date.

Output Contract

Every completed run of this workflow produces a case file containing:

• The original request, the acknowledgement, and the case reference
• The regime named, the clock calculation output, and every extension or pause notice as sent
• The verification record: method, data points matched, result, and the date the clock started or restarted
• The search log (assets/search-log.csv), one completed row per system or source, including processors
• The decision log (assets/decision-log.csv), one row per record or group withheld or redacted
• The response pack as delivered: cover letter, data copy, and index, plus the completed pack checklist
• The delivery log: date, method, recipient confirmation, and the separate channel used for the password or key

Report to the person who commissioned the work in these terms: case reference, regime, deadline and whether it was met, systems searched, volume disclosed, items withheld with grounds in one line each, and any gap or risk that remains open. Give counts from the logs, not from memory.

Operating Rules

• No disclosure without a verification record. If the record is thin, strengthen the check or narrow what you send. Never solve doubt by sending and hoping.
• Deadlines come from the calculator and the regime file, checked against current regulator guidance for the case in front of you. If the guidance and this skill disagree, the guidance wins and the file note says why.
• Exemptions and withholding grounds apply record by record, with reasons written at the time. Blanket claims over a whole file or a whole system are out.
• The requester's motive is irrelevant to whether you answer. A request made to support a dispute, a tribunal claim, or a press story gets the same search and the same clock.
• Keep the requester's data out of the work itself. Case discussions in chat tools and ticket comments become personal data and can fall inside the next request. Keep commentary factual and in the case file.
• Manifestly unfounded or excessive is a high bar with the burden on you. One angry requester, one large request, or one repeat request is not enough on its own. If you reach for it, the reasoning file gets built before the letter, and counsel or the DPO signs the call.
• Fees follow the regime file and nothing else. Where a fee is allowed, state the basis and the amount early, and record the requester reply.
• When nothing is found, that is still a response. Say what was searched, give the supplementary information that applies, and meet the same deadline.
• If you miss the deadline, say so to the requester with the reason and the new date, and log the cause. A late honest letter draws a smaller penalty risk than silence in every regime covered here.