Data Subject Access Requests: How to Build a Workflow That Meets the Deadline

Here's the thing almost nobody realises about the DSAR deadline: it's usually blown long before the request ever lands in your inbox. The clock you're racing — roughly thirty days under GDPR, forty-five under California's law — feels like the challenge. It isn't. The real challenge is that when a request arrives asking for everything you know about a person, most organisations genuinely don't know where all of it lives. It's scattered across a CRM, an email platform, analytics, a support tool, three spreadsheets, and a backup someone set up in 2022. The deadline was missed the day you lost track of your own data.

Which means the goal isn't to get faster at scrambling. It's to build a workflow — and the preparation behind it — so that when a data subject access request comes in, you don't panic, you just run a process you already have. Requests are only getting more common as privacy awareness grows and more regions pass access laws, so "we'll figure it out if it happens" is quietly becoming a liability. This is how to build a DSAR workflow that meets the deadline calmly, every time, and turns a dreaded fire drill into routine operations.

This is general guidance for marketers, not legal advice. DSAR obligations, deadlines, and exemptions vary by jurisdiction and by the nature of your organisation and data — for your specific duties, consult a qualified privacy professional or attorney.

Why this is worth taking seriously

It's tempting to file DSARs under "rare edge case." That's increasingly wrong. Request volumes have been climbing sharply — driven by rising consumer awareness and the steady expansion of privacy laws across US states and beyond — so the odds you'll face one, and then several, keep going up. And the downside of fumbling one is not trivial: regulators have issued serious, sometimes seven-figure penalties specifically triggered by access requests that were ignored, answered late, or answered incompletely. An ignored data-subject request is one of the concrete, marketing-adjacent failures behind the fact that privacy fines are rising. A calm workflow isn't bureaucratic nicety; it's risk management.

The clock — and what actually starts it

First, the timing, because misunderstanding it is a common way to fall behind on day one. The response window depends on which law applies: under GDPR you typically get around thirty days from receipt, extendable by up to a further two months for genuinely complex or high-volume requests, as long as you tell the person about the extension before the original deadline passes. Under California's CCPA/CPRA it's roughly forty-five days, similarly extendable when necessary. Other regions differ, so if you operate across borders you'll track different clocks for different requesters — part of the broader picture in our GDPR and CCPA compliance checklist.

The detail that catches people out: the clock starts the day the request is received, not the day someone notices it. A request that sits unread in a shared inbox for a week has already burned a week of your window. That single fact is why the very first stage of the workflow — fast, reliable intake — matters more than it looks, and why a request can arrive through any channel at all: a web form, an email, a support ticket, even a letter or a phone call.

Featured Recommendation AD · AFFILIATE

4.8 / 5.0

Chemicloud

Affordable, reliable web hosting with free migration and 24/7 real human support — no AI chatbots

Best for: Web Hosting for Growing Websites

Visit Website

View details Compare

The core truth You don't respond to a DSAR — you run a workflow you already built. The thirty-day clock isn't the real test; the real test is whether you knew where the data lived before the request arrived. Preparation, not speed, meets the deadline.

The six-stage workflow

A dependable DSAR process moves through six stages from receipt to resolution. Each has a job, and each has a characteristic way of going wrong.

Intake and log means capturing every request the moment it arrives into one central register — date received, channel, requester, and which right they've invoked (access, deletion, or a consent withdrawal) — and acknowledging it promptly so both the clock and expectations are set. Respond securely means delivering the finished package through a protected channel, never unencrypted email, within the deadline. And document everything, because a well-kept record of the whole process is itself evidence of good faith to a regulator — the paper trail is part of the compliance, not an afterthought to it. Two of the middle stages deserve their own discussion, because they're where the most damaging mistakes happen.

Trap one: verify identity before you hand over anything

This is the counterintuitive one that turns a compliance action into a compliance disaster. A DSAR asks you to assemble and hand over everything you know about a person. So if you send that dossier to someone impersonating the data subject, you haven't complied with anything — you've committed a data breach, disclosing personal data to an unauthorised party, which can draw a penalty entirely of its own.

That's why identity verification must come before you gather or release a single record, and why a quick reply from the sending email address isn't enough on its own — email accounts get compromised and spoofed. Use a secure, proportionate method: for an existing customer, having them authenticate through their account login often does the job; for others, security questions they previously set, or reasonable identity documentation, may be appropriate. The balance to strike is being confident enough that you're not fooled, without making verification so onerous that it becomes an unlawful obstacle to a legitimate request. Protecting the real person is the whole point — the same instinct behind locking down your accounts against impersonation generally.

Trap two: redact the third-party data

The second landmine sits in the review stage. The data you hold about one person is very often tangled up with data about others — an email thread names a colleague, a support note mentions another customer, a record references a third party. When you disclose person A's data, you must not accidentally hand over person B's along with it, because doing so breaches person B's rights just as surely as ignoring a request breaches A's.

So before anything goes out, review the gathered data carefully and redact third-party personal information, and check whether any legal exemptions apply (things like legal privilege or genuinely confidential commercial information). This review is painstaking by nature, which is another reason volume makes manual handling untenable — and a reason clean, well-structured source data helps enormously, since tangled, duplicated records are far harder to review safely. It's one more payoff from good CRM data hygiene.

The real secret: win the deadline before the request arrives

Now the heart of it. Everything above is executable in the response window except stage three — find and gather — which is where deadlines actually die. If your personal data is scattered across a dozen systems and nobody has ever mapped where it all is, then a request kicks off a frantic, system-by-system treasure hunt, and thirty days evaporates fast, especially if two or three requests land at once.

Building and maintaining that data map is really an exercise in knowing your own data estate — which is exactly the discipline behind a solid first-party data strategy and the reason it pays to map and document your processes before you need them. It's also far easier when your data isn't fragmented across a sprawling, disconnected set of tools, which is one more argument for a well-integrated martech stack. A DSAR is, in a sense, a stress test of how well you actually know your own systems — much like an honest end-to-end funnel audit tests how well you understand your own pipeline.

Automate the parts that don't need judgement

Because request volume is rising, handling everything by hand eventually breaks. The good news is that most of the workflow's mechanical parts automate well, leaving humans for the judgement calls (redaction decisions, exemption assessments). Sensible things to automate: a request intake portal so submissions land in one structured place and the clock starts automatically; deadline tracking with reminders well before the due date; data discovery that searches across connected systems to find a person's records; and documentation that logs each step for the audit trail as it happens. This is precisely the sort of rules-based, high-stakes process that benefits from no-code automation and, increasingly, from the same kind of agentic AI tools that can locate data across platforms and track everything in a single dashboard. Automate the plumbing; keep humans on the calls that carry legal weight.

A note on refusing and extending

You aren't obligated to fulfil every request unconditionally. You can take the single permitted extension for genuinely complex or numerous requests, provided you notify the person before the original deadline with a reason and an estimated completion date. And you can refuse a request that's genuinely unfounded or excessive, or where fulfilling it would infringe others' rights — but any refusal must be documented, justified, and communicated to the requester, and it shouldn't be your default escape hatch. Regulators look dimly on organisations that lean on refusals and extensions to dodge the spirit of the right. Use these as the narrow, well-reasoned exceptions they're meant to be.

The short version

The DSAR deadline — roughly thirty days under GDPR, forty-five under CCPA — is usually lost before the request even arrives, because the hard part isn't the clock, it's knowing where a person's data actually lives across your scattered systems. Requests are rising and the fines for mishandling them are real, so build a repeatable six-stage workflow: intake and log the moment it lands (the clock starts on receipt, not on notice); verify identity before releasing anything, because sending data to an impostor is itself a breach; find and gather across every system; review and redact third-party data; respond securely within the deadline; and document every step as your proof. The two traps that cause the worst outcomes are skipping real identity verification and failing to redact others' data. But the deadline is genuinely won upstream, by maintaining a data map so gathering becomes a lookup rather than a hunt — and by automating the mechanical stages so humans focus on judgement. Prepare in advance, and a DSAR stops being a fire drill and becomes just another process you run calmly, on time, every time.