A privacy request from intake to audit record

Scenario and boundaries

A person using the fictional name Casey Morgan submits an access request to Northstar Garden Supply. They ask for account information, order history and past support conversations. Jordan Lee, a fictional operations lead, coordinates the request. Avery Chen is the fictional authorized reviewer. Sam Rivera owns the support-system search.

1. Intake preserves what arrived

Jordan creates case DEMO-1042 and records the received channel, received time and Casey's original wording. The initial record says “possible access request” until an authorized person reviews it. Jordan sends a neutral acknowledgment through the approved channel without promising a result or deadline.

Record created

• Original request and recorded received time.
• Named case owner and next review date.
• Products and accounts mentioned by the requester.
• Open questions about identity, scope and applicable requirements.

Use the intake checklist and add the request to the request tracker.

2. Identity review is proportionate and recorded

The team checks whether Casey can use an existing authenticated account route. Avery considers the sensitivity of the requested information and the risk of disclosing it to the wrong person, then records the approved verification step and outcome. The case record points to the verification evidence in its controlled location rather than copying identity material into the tracker.

If the existing route had not provided enough confidence, the team would have paused disclosure and followed its escalation procedure. A request moving forward would reflect a documented human decision, not an automatic checkbox.

Read the identity verification guide for more operational questions.

3. Task assignment turns scope into owned work

Jordan and Avery translate the reviewed scope into one task per likely data source. Each task identifies a system owner, approved search inputs, the expected result and where controlled evidence should be stored.

4. Search results include limitations

Each assignee records what they searched, when they searched it, the coverage period, a summary of the result and any limitation. They keep raw exports in approved storage and put references—not personal data—into the worksheet.

Sam reports three fictional support conversations and flags that archived attachments were outside the first export. Jordan leaves the collection stage open, assigns the archive search, and records why the original result was incomplete. The follow-up finds one fictional attachment, which is added to the controlled evidence set for review.

This record explains work performed, but it cannot prove that an unknown or omitted system contains no data. Use the system search worksheet to make the search and its limits reviewable.

5. A person approves the exact proposed response

Jordan prepares a draft response and a packet containing the files proposed for Casey. Private working evidence remains separate. The reviewer handoff gives Avery the request scope, verification outcome, completed searches, limitations, open questions and the exact proposed files.

Avery initially returns the packet because the archived attachment search is still open. After Sam completes the follow-up, Avery reviews the new result, opens each proposed file, checks the response text and records approval with the packet reference. The approval does not automatically extend to later file changes.

The response approval checklist makes this final human review explicit.

6. Delivery uses reviewed controls

Jordan verifies the recipient and publishes only the approved packet through a controlled delivery route. The synthetic delivery record captures the recipient channel, packet version, link creation, expiry setting, access method, delivery notification and later access event. Ordinary email carries the notification, not the sensitive export files.

The team also records who can revoke access. Expiry and revocation control future access through the delivery route; they cannot retrieve a copy after a recipient downloads it. See the secure DSAR delivery guide.

7. The audit record tells the full story

Before closing DEMO-1042, Jordan checks that the case history connects the original request, verification decision, task results, search limitation and follow-up, response approval, exact packet, delivery configuration and access event. The closure note describes the outcome without claiming that a closed status proves legal compliance.

Learn how to preserve this history in the privacy request audit trail guide.

Run the exercise with your own procedure

1. Download the five files in the free DSAR toolkit.
2. Delete the synthetic sample rows and keep a clean master copy.
3. Map each field to your approved systems, roles and escalation paths.
4. Walk a fictional request through the workflow with the people who would own each step.
5. Record gaps: missing system owners, unclear review authority, unsafe file transfers or incomplete closure records.
6. Update the procedure and repeat the exercise before relying on it for a real request.

Check primary guidance for your situation

This example intentionally avoids prescribing universal time limits, identity evidence or disclosure decisions. Requirements vary by jurisdiction and facts. Start with the regulator or authority relevant to your organization and obtain qualified advice when needed.

• European Data Protection Board: Guidelines 01/2022 on data subject rights — Right of access
• UK Information Commissioner's Office: A guide to subject access