DSAR Response Workflow: A Practitioner's Guide to Data Subject Access Requests Under CCPA, GDPR, and State Privacy Laws

The California Privacy Protection Agency’s $1.35 million administrative fine against Tractor Supply in October 2025 wasn’t for a data breach. It was for privacy compliance failures — the kind that compound quietly until a regulator decides to make an example. The California AG’s $1.55 million settlement with Healthline in 2025 was the largest CCPA settlement to that point, and the first involving a publisher rather than a data broker.

Neither of these companies was cavalier about privacy. They just didn’t have systems that could handle data subject requests at scale, with evidence, within the required timeline.

That’s the risk a DSAR response program exists to manage.

TL;DR

• CCPA allows 45 days to respond (plus 45-day extension with notice); GDPR requires response within 30 days (plus 2-month extension for complex requests). All active US state privacy laws follow the CCPA’s 45-day model.
• Gartner projected DSAR-related fines exceeding $1 billion by 2026, a tenfold increase from 2022. California’s CPPA is now issuing seven-figure fines for violations that include mishandled consumer requests.
• A defensible workflow requires six steps: intake and logging, identity verification, data collection, legal review and redaction, response delivery, and documented closure.
• With 13+ active state privacy laws, organizations without a systematic workflow are running a rolling compliance risk every time a consumer sends an email.

What a DSAR Is — and Why the Terminology Confuses Everyone

The term “DSAR” — Data Subject Access Request — comes from the GDPR. In GDPR terminology, data subjects have the right to request access to their personal data, and the request is called a subject access request (SAR) or data subject access request (DSAR) interchangeably.

Under CCPA, the equivalent is a “verifiable consumer request” (VCR) or “consumer request.” Functionally, it’s the same thing: a consumer asking to know what data you hold about them, to have it deleted, to correct it, or to get a portable copy.

Here’s the complication: the specific rights available, the scope of data covered, the deadline for response, and the verification requirements differ between GDPR and US state laws. A workflow built solely around GDPR won’t be adequate for California-headquartered consumers, and vice versa. Organizations with US and EU customer populations need a process that handles both, with a clear decision tree for which rules apply.

The Deadline Map

Before designing a workflow, understand the clock you’re working against.

The 30-day GDPR deadline is the tighter constraint. If a request comes in from an EU resident and a California resident simultaneously, the EU response governs your operational pace — even though the legal obligations are separate.

The extension is real but requires genuine complexity justification. Routinely extending every DSAR “just in case” is a pattern regulators notice. The ICO has issued guidance specifically addressing organizations that treat extensions as a default rather than an exception.

Step 1: Intake and Tracking

A DSAR that isn’t logged immediately risks missing the deadline before anyone realizes it was received. This is more common than it sounds: requests arrive through customer service email, privacy request forms, social media messages, and verbal conversations with customer-facing staff who may not know what a DSAR is.

Your intake system needs to:

Capture requests from every channel. Train customer service, operations, and marketing teams to recognize a DSAR and route it immediately to whoever owns the privacy function. A consumer who says “I want to know what information you have about me” is submitting a DSAR, regardless of where they said it.

Log the request with a timestamp. The clock starts when you receive the request — not when you review it, not when you verify identity, not when you decide it’s valid. Log the date and time of receipt as a matter of policy.

Assign an owner and a due date. Every open DSAR should have a named owner and a calculated deadline. Set internal reminders at day 21 (GDPR) or day 30 (US laws) to flag requests that haven’t moved.

Acknowledge receipt to the consumer. This isn’t legally required under most laws, but it creates a record of when the request was received and starts building a documentation trail. It also reduces follow-up contacts that take time away from actually completing the response.

Step 2: Identity Verification — The Balance Point

Before you give anyone their personal data, you need to be reasonably confident they are who they claim to be. This is legally required under CCPA and strongly recommended under GDPR.

The challenge is calibrating verification to risk. If you ask for a government-issued ID to confirm a name-and-email request, you’re probably demanding more than the law requires and potentially violating the data minimization principle by collecting more information than necessary. If you accept any unverified email as sufficient, you risk disclosing personal data to someone who isn’t the data subject.

CCPA’s approach: match at least two data points from information already on file for the consumer — things like the email address used in previous transactions, a device identifier, or account details. For highly sensitive data (financial records, health information, precise geolocation), require two or more data points. For general category-level information, one data point may suffice.

GDPR’s approach: use the minimum information needed to confirm identity in the circumstances. If the request comes from an authenticated account portal, further verification may not be needed. If it comes from an anonymous email claiming to be an account holder, verification is warranted.

Document your verification methodology. If a consumer complains that your verification process was excessive or discriminatory, you need to show regulators what standard you applied and why.

One important note: you cannot deny a request solely because you’re unable to verify identity. If verification genuinely fails — the consumer can’t match any data point you have on file — CCPA allows you to notify the consumer that you cannot verify and inform them of what steps they can take to provide sufficient information. You cannot simply ignore unverifiable requests.

Step 3: Data Mapping and Collection

Once identity is confirmed, the real operational challenge begins: finding all the data you hold about this person.

This is where organizations without mature data inventories struggle. A DSAR response requires locating data across:

• Primary databases (CRM, account management systems)
• Marketing platforms (email lists, ad targeting data)
• Analytics systems
• Third-party processors who hold data on your behalf
• Backups and archives (with careful attention to scope limitations)
• Offline records, if any

Under GDPR, the scope is genuinely broad. An email that mentions an individual can be in scope. A call recording is in scope. Internal notes about a customer support interaction are in scope. Organizations routinely discover during their first DSAR response that data exists in places they hadn’t inventoried.

CCPA covers categories of personal information as defined in Cal. Civ. Code § 1798.140, including identifiers, commercial information, biometric data, internet activity, geolocation data, and inferences drawn from any of the above to create a consumer profile.

Practical guidance: maintain a DSAR data map — a documented list of every system that holds personal data and the query or export process for retrieving it. The first time you build this map will take significant time. Every subsequent DSAR response will be faster and more consistent. Organizations that haven’t invested in data mapping can spend days assembling a response that a mapped organization can produce in hours.

Step 4: Legal Review, Exemptions, and Redaction

Not everything you find is necessarily producible. Before responding, review the collected data for:

Third-party personal data. If your records include personal information about someone other than the requester — a business contact, a family member, a counterparty — that information must typically be redacted or withheld to protect the third party’s rights.

Law enforcement exemptions. Data that is the subject of an active law enforcement investigation may be withheld or require delayed disclosure.

Privileged materials. Communications subject to attorney-client privilege are generally exempt from DSAR responses.

Trade secrets and confidential business information. Where disclosure of certain information would reveal your proprietary processes or the personal data of employees, narrowly targeted exemptions may apply.

Manifestly unfounded or excessive requests (GDPR). If a request is clearly designed to harass, or is so repetitive as to be abusive, GDPR allows you to charge a fee or refuse — but this is a high bar and should involve legal review before you invoke it.

Document every exemption decision. If the consumer appeals or complains to a data protection authority, you need to show that you applied an exemption deliberately and on a defensible basis — not that you withheld data because it was inconvenient to produce.

Step 5: Response Delivery

The response must:

• Confirm whether personal data is held about the individual
• Provide the requested information in a portable, intelligible format
• Be delivered securely (not via unencrypted email attachment if sensitive)
• Be provided free of charge

Under CCPA, portable formats that allow transmission from one entity to another without hindrance — structured CSVs, secure PDFs, JSON — satisfy the portability requirement. Under GDPR, the portability right technically applies only to data provided by the data subject (not inferred data), but the access right is broader.

If the consumer requested correction rather than access, the response must confirm what was corrected and, if correction is refused, explain why.

If the consumer requested deletion, the response must confirm what was deleted and, if any deletion was incomplete (due to a legal retention obligation, for example), explain which categories of data were retained and why.

Step 6: Documentation and Closure

Every completed DSAR should generate a closure record documenting:

• Date request received
• Verification method and outcome
• Systems searched and data categories found
• Exemptions applied (with rationale)
• Date and method of response delivery
• Whether an extension was taken and the justification

Retain this documentation for at least as long as required by your jurisdiction’s general record retention requirements — typically three to five years. Regulators in DSAR enforcement actions routinely request this documentation for all requests over the preceding 12–24 months, not just the complaint that triggered the investigation.

Multi-Jurisdiction Complexity: When CCPA and GDPR Apply Simultaneously

A consumer who is both a California resident and an EU citizen has rights under both laws. In practice, this is rare for individual requests but common for enterprise customer populations.

The practical approach is to identify the consumer’s primary relationship to your organization (California-based account, EU-based account, or ambiguous) and apply the stricter standard where there’s genuine ambiguity. For deadline conflicts, the GDPR’s 30-day standard governs. For scope conflicts, produce what the more expansive law requires. Document which legal basis you’re responding under.

For organizations with significant EU customer populations, a GDPR Article 30 Record of Processing Activities (RoPA) dramatically accelerates DSAR responses by providing a pre-built map of what data you hold, where it is, and who has access to it.

When You Can Deny, Delay, or Extend

These situations are available but narrow:

Deny: Insufficient verification (with consumer notice of how to remedy); manifestly unfounded or excessive requests (high bar); confidentiality exemptions for trade secrets or third-party personal data that can’t be redacted.

Extend: Genuine complexity (multiple systems, large data volume requiring significant collection effort, requests that implicate multiple legal regimes) — but only with consumer notice within the initial response window.

Frequency limitation (CCPA only): You are not required to respond to the same type of request from the same consumer more than twice in any 12-month period.

Invoking these provisions without documentation invites the exact regulatory scrutiny you’re trying to avoid. Always document the basis for a denial or extension in the request record.

The Scale Problem

Organizations are receiving more DSARs every year, and California’s January 2026 enforcement expansion to automated decision-making technology added a new request type — opt-outs and explanations of ADMT decisions — that requires the same structured workflow. Organizations that handle DSARs through ad hoc manual processes manage at low volume. At scale, ad hoc breaks. Common failure modes:

• Requests received but not logged, deadline missed before anyone tracks it
• Identity verification inconsistently applied across staff handling requests
• Data collection limited to primary database, missing marketing platform and analytics data
• Response delivered over email without encryption for sensitive financial data
• No closure documentation, leaving the organization unable to demonstrate compliance in an enforcement inquiry

The underlying steps — intake, verify, collect, review, deliver, document — are the same at any scale.

So What Does This Mean for Your Privacy Program?

Map your DSAR obligations before the next request arrives. Which state privacy laws apply to your customer population? Do you have EU residents in scope? What’s your current intake channel, and are all customer-facing staff trained to recognize and route requests?

Then test your workflow. Send a mock DSAR through your own process. Time how long it takes to verify identity, collect data, review it, and generate a response. If you can’t complete the exercise in 30 days, you know your gap before a regulator finds it for you.

The CPPA’s enforcement trajectory is clear: $1.35 million against Tractor Supply, $1.55 million against Healthline. The agency has made public that it is working through a backlog of complaints. The question isn’t whether enforcement will reach your organization — it’s whether your process will hold up when it does.

For how California’s enforcement posture has evolved and what the CPPA is actively targeting, see CCPA and CPRA Enforcement in 2025: What the California Privacy Protection Agency Is Actually Going After. For how state privacy laws interact with GLBA financial institution obligations, see State Privacy Laws and the GLBA Safe Harbor: What Banks and Fintechs Can No Longer Assume. For the data retention schedules that determine how long personal data must be kept before deletion is permissible, see Data Retention Policy Template: Schedules, Legal Hold Triggers, and Defensible Disposal.

Sources: CPPA Imposes Largest Administrative Fine to Date — Tractor Supply Company (Orrick) | California AG Issues Highest CCPA Fine to Date (Privacy World) | ICO: A Guide to Subject Access | CCPA Requirements 2026: Complete Compliance Guide (Secure Privacy) | TrustArc: DSR Requirements — GDPR & CCPA Compliance Guide