Building a DSAR Workflow That Doesn't Suck
A practical guide to building a DSAR workflow for small businesses. Step-by-step process from intake to response, no expensive software required.
Last updated: 2026-02-07
Why Most DSAR Workflows Fail
Most small businesses handle their first DSAR the same way: someone gets a confusing email, panics slightly, googles "what is a DSAR," spends three days figuring out what to do, and cobbles together a response at the last minute. It works once. Maybe twice. Then it falls apart.
Disclaimer: This article is for informational purposes only and does not constitute legal advice. Privacy regulations are complex and change frequently. You should consult a qualified attorney for guidance specific to your business. The information here is based on the GDPR (in particular Articles 12 and 15), the CCPA (Cal. Civ. Code §§ 1798.100–1798.199.100), and the UK GDPR / Data Protection Act 2018, as of the date of publication.
The problem is not that DSARs are hard. They are not. The problem is that without a repeatable workflow, every request feels like the first time. You waste hours reinventing the process, miss steps, forget to check systems, and sweat deadlines that should be routine.
A good DSAR workflow fixes this. It turns a stressful ad-hoc scramble into a boring, predictable process — which is exactly what you want. Boring means no surprises. No surprises means no fines.
This guide walks you through building a DSAR workflow from scratch. No expensive software required. A spreadsheet, some templates, and a clear process are all you need.
The DSAR Workflow at a Glance
Before we dig into the details, here is the full workflow in seven stages:
Stage 1: Request Intake — A DSAR arrives. You recognize it and capture the details.
Stage 2: Logging and Deadline Setting — You log the request in your tracker and calculate the response deadline.
Stage 3: Identity Verification — You confirm the requester is who they claim to be.
Stage 4: Data Search — You search all your systems for the requester's personal data.
Stage 5: Review and Redaction — You review what you found, redact third-party data, and apply any exemptions.
Stage 6: Response Delivery — You compile and send the response package to the requester.
Stage 7: Record Keeping — You close the request and file your records.
That is it. Seven stages, each with a clear set of actions. Let us walk through each one.
Stage 1: Request Intake
A DSAR can arrive through any channel. The person does not have to use any magic words or fill in a specific form. If someone is asking about their personal data, it is a DSAR.
Where DSARs Come From
- Email — The most common channel. Someone emails your general inbox, support address, or a specific employee.
- Web forms — If you have a privacy request form on your website (and you should), requests come through there.
- Phone calls — Yes, verbal requests count. Ask the person to follow up in writing, but start your clock from the verbal request.
- Social media — Someone messages your business on Instagram or Twitter asking about their data. It counts.
- Post — Physical letters. Less common but it happens, especially from solicitors acting on behalf of their clients.
- In person — A customer walks in and asks. It happens in retail and service businesses.
What to Do at Intake
-
Recognize it as a DSAR. The person does not have to say "DSAR" or cite any law. Phrases like "what data do you have about me," "I want a copy of my personal information," or "I want to exercise my right of access" all trigger the process.
-
Record the date and time you received it. This is when your deadline clock starts. Under GDPR, you have 30 calendar days (GDPR Article 12(3)). Under CCPA, you have 45 calendar days (Cal. Civ. Code § 1798.130(a)(2)).
-
Capture the requester's details. Name, email address, any identifying information they provided, and the channel the request came through.
-
Send an acknowledgment. Let the requester know you received their request and are processing it. This is not legally required under every regulation, but it is good practice and buys you goodwill. Use a template — you should not be writing these from scratch every time.
Setting Up an Intake Channel
The easiest way to manage intake is to create a dedicated email address (something like privacy@yourbusiness.com) and a simple web form. Put both on your privacy policy page. This does not prevent requests from coming through other channels, but it gives people a clear path and makes it easier for your team to spot incoming requests.
If you want to go one step further, use a Google Form that feeds into a Google Sheet. The form captures the requester's name, email, what they are requesting, and any other details you need. The Sheet becomes the start of your tracking log.
Stage 2: Logging and Deadline Setting
Every DSAR needs to be logged in a central tracker. This is non-negotiable. You cannot manage what you do not track, and when a regulator asks how you handle DSARs, "I think we responded to that one" is not an answer.
What Your Tracker Needs
Your DSAR tracker can be a spreadsheet. It does not need to be fancy. Here are the columns that matter:
- Request ID — A unique identifier (DSAR-001, DSAR-002, etc.)
- Date Received — When the request arrived
- Requester Name — Who made the request
- Requester Email — How to contact them
- Request Channel — How it came in (email, form, phone, etc.)
- Request Type — Access, deletion, correction, etc.
- Applicable Regulation — GDPR, CCPA, or other (determines your deadline)
- Deadline Date — Calculated from date received
- Identity Verified — Yes/No/Pending
- Status — New / Identity Verification / Data Search / Review / Response Sent / Closed
- Assigned To — Who is handling this request
- Notes — Any relevant details
- Date Completed — When the response was sent
- Extension Used — Yes/No (and reason if yes)
Calculating Deadlines
This is critical. Get it wrong and you are in violation.
-
GDPR: 30 calendar days from the day after you receive the request (GDPR Article 12(3)). If day 30 falls on a weekend or public holiday, the deadline extends to the next business day. You can extend by up to 60 additional days for complex requests, but you must notify the requester within the initial 30 days and explain why.
-
CCPA/CPRA: 45 calendar days from receiving the request (Cal. Civ. Code § 1798.130(a)(2)). Extendable by an additional 45 days (90 total) if you notify the requester.
-
UK GDPR: Same as EU GDPR — 30 calendar days, extendable to 90 (UK GDPR Article 12(3)).
Set a calendar reminder for 7 days before the deadline. If you are not on track to respond, that is your warning to escalate or request an extension.
Stage 3: Identity Verification
Before you hand over anyone's personal data, you need to be confident the person requesting it is who they say they are. Sending someone else's data to the wrong person is a data breach — and a spectacularly avoidable one.
How to Verify Identity
The level of verification should be proportionate to the sensitivity of the data and the risk of fraud. Here is a tiered approach:
Low risk (request from a known contact through a verified channel): If a customer emails you from the email address you have on file for their account, and they are asking about data associated with that account, the verification is essentially done. The request came from a channel you can reasonably trust.
Medium risk (request from an unknown email or through a general channel): Ask the requester to verify their identity by providing information you can match against your records. This might include their account number, the last four digits of a phone number on file, their date of birth, or a recent transaction detail. Two matching data points is usually sufficient.
High risk (sensitive data, representative requests, or anything that feels off): Ask for a government-issued photo ID. Redact everything you do not need (they can black out their photo, address, and ID number — you just need the name to match). If someone is making a request on behalf of another person, ask for proof of authorization (a signed letter, power of attorney, etc.).
What Not to Do
- Do not ask for more information than you need to verify identity. Requesting a passport copy to confirm an email unsubscribe is disproportionate.
- Do not use the verification step to stall. Regulators know this trick and they do not appreciate it.
- Do not skip verification entirely. Even if you are in a rush, confirming identity is not optional.
For a detailed walkthrough, see our identity verification guide.
Stage 4: Data Search
This is usually the most time-consuming part of the process. You need to search everywhere you hold personal data for information about the requester.
Where to Look
Think beyond your main database. Personal data lives in more places than you expect:
Core systems:
- CRM (Salesforce, HubSpot, Pipedrive, etc.)
- Email marketing platform (Mailchimp, Constant Contact, etc.)
- Customer support tool (Zendesk, Freshdesk, Intercom, etc.)
- Accounting/invoicing software (QuickBooks, Xero, FreshBooks, etc.)
- HR/payroll system (for employee DSARs)
- E-commerce platform (Shopify, WooCommerce, etc.)
Communication channels:
- Email inboxes (search for the requester's name and email address)
- Slack or Teams messages
- Phone call recordings or notes
- Chat logs from website live chat
File storage:
- Google Drive or OneDrive
- Shared network drives
- Local files on individual computers
- Paper files (yes, these count)
Third-party services:
- Analytics platforms (Google Analytics — though this is typically anonymized)
- Advertising platforms (Google Ads, Facebook Ads)
- Survey tools (SurveyMonkey, Typeform)
- Any other SaaS tool where you may have stored personal data
How to Search Efficiently
Create a data search checklist — a list of every system you need to search for each DSAR. Run through the list systematically. Mark each system as searched, note what you found, and flag anything that needs review.
This checklist becomes one of the most valuable documents in your DSAR process. Update it whenever you add or remove a system from your tech stack.
What to Collect
For each system, export or copy:
- All personal data fields related to the requester
- Any records associated with them (transactions, communications, notes)
- Metadata (when data was collected, when it was last updated, who has accessed it)
Store everything in a working folder for this specific request. Keep it organized — you will need to review it before sending.
Stage 5: Review and Redaction
You cannot just dump raw data exports on the requester. You need to review what you have found and clean it up.
What to Review For
Third-party personal data: If your CRM notes say "John called to complain about his order — spoke with Sarah in support," the requester (John) has a right to his data, but you need to consider whether including Sarah's name is appropriate. In most cases, the names of your employees acting in their professional capacity can be included, but personal information about other customers mentioned in the same records must be redacted.
Exemptions: Certain data may be exempt from disclosure. Common exemptions include legal professional privilege (communications with your lawyer about the requester), data that would adversely affect the rights of others, and trade secrets. Exemptions vary by regulation — do not assume that a GDPR exemption applies under CCPA or vice versa.
Accuracy: If you spot data that is obviously wrong, note it. You have an obligation to maintain accurate data, and finding errors during a DSAR is a good time to correct them.
Sensitive data: If the data includes health information, financial details, or other sensitive categories, make sure your delivery method is appropriately secure.
How to Redact
For digital documents, use a PDF editor to black out information that should not be disclosed. Do not just change the text color to white — that is not redaction, that is hiding. Use actual redaction tools that permanently remove the underlying data.
For spreadsheets, delete the cells containing third-party data or replace them with "[REDACTED — third party personal data]."
Document every redaction you make and why. If the requester or a regulator challenges your redactions, you need to be able to explain your reasoning.
Stage 6: Response Delivery
Time to send the response. Here is what it should include.
The Response Package
A cover letter that includes:
- Confirmation that you process (or do not process) their personal data
- A summary of what data you hold and what is included in the response
- The purposes for which you process their data
- Categories of recipients you have shared their data with
- Your data retention periods (or the criteria for determining them)
- Information about their other rights (erasure, rectification, objection, etc.)
- Their right to lodge a complaint with a supervisory authority
- The source of the data, if not collected from them directly
- Any applicable exemptions you have relied on, with a brief explanation
The data itself — organized in a clear, understandable format. CSV, PDF, or a structured document. Do not send raw database exports with field names like "cust_ph_num_2" — make it readable.
How to Deliver Securely
Do not send personal data as an unencrypted email attachment. Options include:
- Password-protected ZIP file sent via email, with the password communicated through a separate channel (text message, phone call)
- Secure file sharing link (Google Drive, OneDrive, or Dropbox with access controls) that expires after a set period
- Encrypted email if your email provider supports it
- Postal mail for physical copies (use tracked delivery)
Timing
Send the response before your deadline. If you cannot meet the deadline, you must notify the requester before the original deadline expires, explain why you need more time, and provide a new expected date. Under GDPR, you can extend by up to 60 additional days (GDPR Article 12(3)). Under CCPA, by 45 additional days (Cal. Civ. Code § 1798.130).
Stage 7: Record Keeping
After sending the response, close the loop.
What to Keep on File
- A copy of the original request
- Your identity verification records
- Your data search checklist (showing which systems you searched)
- The response you sent (cover letter and data)
- Any correspondence with the requester
- Notes on any exemptions applied
- Dates for every step (received, verified, searched, reviewed, sent)
How Long to Keep It
There is no universal rule, but keeping DSAR records for at least three years is common practice. This gives you coverage for most regulatory investigation timelines and limitation periods for complaints. Some organizations keep them for six years to align with general contractual limitation periods.
Store these records securely and separately from your day-to-day business data. A dedicated folder (digital or physical) for DSAR records is the simplest approach.
Putting It All Together: Your DSAR Process Document
Every business that handles personal data should have a written DSAR process document. It does not need to be long — one to two pages is fine. It should cover:
- Who is responsible — Name the person (or role) who owns the DSAR process.
- How requests are received — List the channels and explain how each routes to the responsible person.
- The workflow stages — Summarize the seven stages above.
- Deadline rules — Specify which regulations apply and what the deadlines are.
- Identity verification requirements — Describe your tiered approach.
- Data search checklist — List every system to be searched.
- Escalation process — What happens if the deadline is at risk? Who decides on exemptions?
- Template locations — Where to find your response templates.
This document serves two purposes: it makes the process repeatable (anyone on your team can follow it), and it demonstrates to regulators that you take DSAR compliance seriously.
Common Workflow Mistakes to Avoid
Mistake 1: Not recognizing DSARs when they arrive
The biggest workflow failure happens before the workflow even starts. If the person reading your inbox does not recognize a DSAR, the clock runs and nobody knows. Train everyone who handles incoming communications.
Mistake 2: Waiting to start until you are sure
Some businesses sit on a request for days trying to determine whether it is "really" a DSAR. If it looks like a DSAR, treat it as one. You can always close it out later if it turns out to be something else. You cannot get time back if you wait.
Mistake 3: Searching only the obvious systems
Your CRM is not the only place personal data lives. Email inboxes, shared drives, spreadsheets, accounting software, and third-party tools all need to be checked. Use a checklist every time.
Mistake 4: Skipping identity verification
It is tempting to skip this step when you are in a hurry, but sending data to the wrong person creates a much bigger problem than a late response.
Mistake 5: Not documenting what you did
A regulator will not take your word that you handled a DSAR properly. They want to see evidence. Document every step, every decision, and every date.
Mistake 6: Over-engineering the process
You do not need software, automation, or a 30-page procedure document. You need a clear, simple process that people actually follow. Start basic and add complexity only when the basic process breaks down. If you are looking at software options, see our DSAR software comparison to understand what is worth paying for and what is not.
When to Upgrade Your Workflow
Your manual workflow will serve you well for a long time. But there are signs it is time to invest in better tooling:
- You are spending more than a few hours per week on DSAR management
- Requests are falling through the cracks or deadlines are being missed
- Multiple people need to coordinate on the same request and the spreadsheet is causing confusion
- Your data is spread across so many systems that manual search takes an unreasonable amount of time
- You are handling more than 20 requests per year
When you hit these thresholds, it is worth looking at dedicated tools. Our DSAR software comparison breaks down the options by business size and budget.
For a deeper look at how to handle individual DSAR responses, see our guide on how to respond to a DSAR.
References
- General Data Protection Regulation (GDPR): Article 12 (Transparent communication and response timelines) and Article 15 (Right of access). GDPR Article 12 | GDPR Article 15
- California Consumer Privacy Act (CCPA): Cal. Civ. Code § 1798.130 — response requirements and timelines. Full text on the California Legislative Information site
- UK GDPR / Data Protection Act 2018: ICO guidance on the right of access. ICO right of access guidance
Last reviewed: February 2026. Privacy laws change frequently. Verify all statutory references against the current text of the law and consult qualified legal counsel before making compliance decisions for your business.
Start Building Your Workflow Today
You do not need to spend weeks on this. A solid DSAR workflow can be set up in an afternoon if you have the right templates. Our DSAR Response Templates include everything you need — acknowledgment letters, identity verification requests, response cover letters, extension notices, data search checklists, and a ready-to-use tracking spreadsheet.