Checklist · Technology

Responding to a Data Subject Access Request: A Practical Checklist

Type
Checklist
Jurisdiction
National
Date
2023-09-19
Topic
Technology

A data subject access request (DSAR) or consumer rights request forces a business to find, produce, delete, correct, or stop selling an individual's personal data on a statutory clock. This checklist walks the full workflow under the GDPR and the U.S. state privacy laws — CCPA/CPRA, Virginia's VCDPA, Colorado's CPA, and their siblings — from intake and identity verification through scoping, exemptions, third-party redaction, fulfillment, deadlines, denials, and appeals. It treats the hard scenarios head-on: the authorized-agent request, the request about a minor, and the request that spans a dozen systems. Each phase carries a "Why it matters, and the traps" note and a running worked example built around a fictional D2C brand. The goal is a repeatable process that turns a scary letter into a documented, defensible response delivered on time.

Responding to a Data Subject Access Request: A Practical Checklist

Technology > Privacy | Published 19 September 2023 - Updated 6 January 2025 | UpLaw - uplaw.us

A rights request is a stopwatch, not a suggestion. The moment a customer emails "delete my data" or "send me everything you have," a statutory clock starts, exemptions attach, and every downstream mistake becomes discoverable. This checklist turns that pressure into a process.

Keywords: DSAR, consumer rights request, GDPR access, CCPA deletion, CPRA, right to erasure, identity verification, authorized agent, data mapping, opt-out of sale, portability, redaction, statutory deadline, appeal

Somewhere in your inbox right now is a message that reads, in whole, "Please delete all my information." No case number, no statute cited, maybe not even a full name. Under the old world that was a customer-service ticket. Under the GDPR and the wave of U.S. state privacy laws, it is a legal demand with a deadline, and how you handle it is auditable by a regulator who was not in the room.

This checklist is the operational companion to the strategy laid out in Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork and its lighter-weight sibling Standing Up a Privacy Compliance Program: A Practical Checklist. Those documents tell you how to build the program; this one tells you what to do when a request actually lands. Work the phases in order. Skipping intake logging to "just answer quickly" is how businesses miss deadlines they never knew were running.

Throughout, we follow Tidewater Goods, a fictional direct-to-consumer coastal-apparel brand headquartered in California that ships to customers across the U.S. and the EU. Tidewater is fielding two requests at once: a California shopper, "Marisol," who wants her account and data deleted, and a German customer, "Jonas," who wants a copy of everything Tidewater holds about him. One request, one company, two legal regimes — the perfect stress test.

Phase 1 — Map the rights before the request arrives

  • [ ] Build a one-page matrix of every consumer right your business must honor, by jurisdiction (GDPR vs. CCPA/CPRA vs. VCDPA/CPA and siblings)
  • [ ] Note which rights you owe: access/know, deletion/erasure, correction/rectification, portability, opt-out of sale/sharing/targeted advertising, and (GDPR only) restriction and objection
  • [ ] Confirm whether you are a "controller/business" or "processor/service provider" for each data set — your obligations differ
  • [ ] Record each right's statutory deadline and extension rules on the same page
  • [ ] Identify whether you meet the applicability thresholds at all (revenue, volume of consumers, share of revenue from selling data)

Why it matters, and the traps. The rights are cousins, not twins. Under the GDPR, Articles 15–22 of Regulation (EU) 2016/679 give a data subject the right of access (Art. 15), rectification (Art. 16), erasure or the "right to be forgotten" (Art. 17), restriction of processing (Art. 18), data portability (Art. 20), and objection (Art. 21) — a broad, standalone bundle. The California Consumer Privacy Act as amended by the CPRA, Cal. Civ. Code § 1798.100 et seq., grants the right to know, the right to delete, the right to correct, and the rights to opt out of "sale" and "sharing" and to limit use of sensitive personal information. Virginia's Consumer Data Protection Act, Va. Code § 59.1-575 et seq., and the Colorado Privacy Act, Colo. Rev. Stat. § 6-1-1301 et seq., look similar but differ in the details — Virginia and Colorado, for instance, layer on an appeal right that California handles differently. The trap is treating "a privacy request" as one monolithic thing. A GDPR erasure request carries broad exceptions (Art. 17(3)); a CCPA deletion request carries its own list of nine exemptions in § 1798.105(d). You cannot answer correctly until you know which law's rules govern which data.

Tidewater's matrix. Marisol is a California resident, so her deletion request runs under the CCPA (45 days, one 45-day extension). Jonas is in Germany, so his access request runs under the GDPR (one month, extendable by two). Same company, two clocks, two rulebooks. For the underlying doctrine on how these regimes fit together, Tidewater's counsel keeps Mobile App Privacy Law: A Compliance Map for Founders and Counsel and The Privacy and Data Protection Toolkit: Building and Operating a Compliance Program on the desk.

Phase 2 — Intake channels and starting the response clock

  • [ ] Publish at least two designated request methods (CCPA requires a toll-free number for some businesses, or two methods including an online form; GDPR requires no fee and accessible means)
  • [ ] Route every channel — email, web form, phone, mail, even in-person — to a single intake owner or ticketing queue
  • [ ] Train customer-facing staff to recognize and forward a request in any wording ("erase me," "what do you have on me," "stop selling my info")
  • [ ] Timestamp receipt the day the request arrives, not the day someone notices it
  • [ ] Log each request in a register: date received, requester, right invoked, jurisdiction, deadline, assignee, status
  • [ ] Send an acknowledgment confirming receipt and the expected response window

Why it matters, and the traps. The single most expensive mistake in this whole process is a request that sits unread in a shared inbox while the clock runs. Under the GDPR, Article 12(3) requires a response "without undue delay and in any event within one month of receipt." Under the CCPA, the business must confirm receipt within 10 business days and substantively respond within 45 calendar days (Cal. Civ. Code § 1798.130). Crucially, the clock starts on receipt, not on verification — the CCPA Regulations, 11 Cal. Code Regs. § 7000 et seq., are explicit that the 45 days run from the day you get the request, and time spent verifying identity does not pause it. A request phrased as a customer complaint on your Instagram DMs still counts. The trap is a decentralized intake where support, legal, and marketing each think someone else has it.

Tidewater's clock. Marisol submitted through Tidewater's web form on a Monday; the register auto-stamps that date and calculates a 45-day due date. Jonas emailed support@ in German; the support agent, trained to spot rights language, forwarded it the same day, and it was logged with a one-month deadline. Both received an acknowledgment within 24 hours. The lesson from Launching a Website: A Legal Compliance Checklist applies directly: your privacy request mechanism is part of your site's legal plumbing, not an afterthought.

Phase 3 — Identity verification and the authorized-agent scenario

  • [ ] Match the sensitivity of the request to the rigor of verification (deletion of a full profile demands more than a simple "what categories do you hold")
  • [ ] Verify the requester to a "reasonable degree of certainty" (access to categories) or "reasonably high degree of certainty" (deletion, specific pieces) under the CCPA Regulations
  • [ ] Avoid collecting new sensitive data solely to verify — use information you already hold to challenge-match
  • [ ] For an authorized agent, obtain signed permission from the consumer plus, in many cases, the consumer's own identity verification and confirmation of the agent's authority
  • [ ] For a request about a minor or on behalf of a household member, apply the heightened parental-consent and household rules
  • [ ] Do not treat non-verification as a denial of the underlying right — offer to process what you can (e.g., opt-out of sale requires no verification under the CCPA)

Why it matters, and the traps. Verification is where privacy and security collide. You must be confident you are handing personal data to (or deleting it for) the right person — a fraudster who successfully impersonates a customer to trigger deletion has weaponized your compliance program against you. The CCPA Regulations set a sliding scale: more sensitive or destructive requests require higher confidence. The GDPR, under Article 12(6), lets a controller request additional information "necessary to confirm the identity" where there are reasonable doubts, but you cannot demand disproportionate documentation. The two central traps are (1) over-collecting — asking a customer to upload a passport to confirm an email you already have on file, which itself creates a new privacy problem — and (2) under-verifying, and shipping someone's purchase history to a stranger.

The authorized-agent scenario is its own beast. Both the GDPR and the CCPA let a third party — a family member, a privacy service, a lawyer — submit on the consumer's behalf. Under the CCPA Regulations, you may require the agent to provide the consumer's signed permission, verify the consumer's own identity directly, and confirm the agent's authority. A business gets tripped up when it either rubber-stamps an agent (handing data to whoever asks nicely) or stonewalls a legitimate agent (a common tactic that regulators frown on). The minor scenario adds parental consent: a request to delete a child's account or opt a teen out of sale must run through the age-appropriate consent rules, and under the CCPA a minor's data has opt-in (not opt-out) protection for sale.

Tidewater's verification. Marisol's deletion request requires a "reasonably high degree of certainty," so Tidewater sends a confirmation link to the email on her account and asks her to confirm two recent order details — no new documents collected. Jonas's access request is verified against his account login and a magic-link email. A week later a company called "PrivacyGuard LLC" submits a deletion request "on behalf of" a customer; Tidewater's process correctly pauses to require the consumer's signed authorization and direct identity confirmation before proceeding.

Phase 4 — Scoping: finding the personal data across every system

  • [ ] Pull the data map / RoPA (record of processing activities) and list every system that could hold the requester's data
  • [ ] Search structured systems (CRM, order database, email platform, support desk, payment processor records) by identifier
  • [ ] Search unstructured stores (shared drives, ticket attachments, marketing spreadsheets, Slack exports) where they hold personal data
  • [ ] Query processors, sub-processors, and service providers who process data on your behalf
  • [ ] Capture backups and archives in scope for access; note their separate treatment for deletion
  • [ ] Compile the results into a single response file keyed to the specific right invoked

Why it matters, and the traps. You cannot produce, delete, or correct data you cannot find. This is the phase where a mature data-mapping program pays for itself and an immature one collapses. The GDPR's Article 30 record of processing activities and the general accountability principle assume you know where personal data lives; the CCPA's disclosure obligations assume the same. The recurring trap is the "forgotten system" — the standalone marketing tool, the founder's personal spreadsheet, the analytics vendor — that surfaces later and turns a clean deletion into an incomplete one. This is precisely why data mapping is the load-bearing wall of any privacy program; see Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork for how to build and maintain the inventory before a request forces you to.

A second trap: over-retention makes scoping harder and riskier. Every extra copy of personal data you keep past its purpose is another place a DSAR has to reach and another exposure in a breach. The discipline described in Data Minimization and Storage Limitation: Curbing the Over-Retention of Personal Data directly shrinks your DSAR burden — you cannot be asked to delete what you never kept. A third trap: cross-border data. If the requester's data has been transferred outside the EU, your scoping must reach the offshore processor, and your transfer mechanism (covered in Moving Personal Data Out of the EU After Schrems II: SCCs and Transfer Impact Assessments) should already obligate that processor to assist with rights requests.

Tidewater's scope. Jonas's access request pulls records from Shopify (orders), Klaviyo (email marketing), Zendesk (three support tickets, one with a photo attachment), Stripe (payment metadata), and a Google Sheet a marketing contractor kept of "VIP EU customers." That last sheet is exactly the forgotten system — it existed outside the data map until this request forced its discovery, and Tidewater adds it to the RoPA on the spot.

Phase 5 — Exemptions, exceptions, and redacting third-party data

  • [ ] Screen the in-scope data against the applicable law's exemptions before producing or deleting
  • [ ] For deletion, check whether you must retain data to complete a transaction, comply with law, detect fraud/security incidents, or exercise legal claims (CCPA § 1798.105(d); GDPR Art. 17(3))
  • [ ] Withhold trade secrets, privileged material, and information whose disclosure would compromise security
  • [ ] Redact third parties' personal data from an access response so you disclose the requester's data, not others'
  • [ ] Do not disclose specific pieces of "sensitive" information (SSN, financial account, precise geolocation, health data) in an access response where the rules bar it
  • [ ] Document the legal basis for every withholding and redaction

Why it matters, and the traps. Neither access nor deletion is absolute. The CCPA lists nine deletion exemptions in § 1798.105(d) — completing a transaction, security and fraud detection, legal compliance, exercising free speech, internal uses aligned with expectations, and so on. The GDPR's Article 17(3) carves out erasure where processing is necessary for freedom of expression, legal obligations, public-health tasks, archiving, or the establishment or defense of legal claims. The big traps: (1) treating an exemption as all-or-nothing — an exemption that lets you keep a customer's transaction records for tax purposes does not let you keep using her email for marketing; you delete what you can and keep only what the exemption covers, then tell the requester what you kept and why; and (2) mishandling third-party data. An access response must give the requester their data — not the personal data of other people caught in the same records. If Jonas's support ticket names another customer, that person's name is redacted. The GDPR's Article 15(4) expressly says the right to obtain a copy "shall not adversely affect the rights and freedoms of others." A related trap lives in the categories of data in scope: sensitive personal information carries its own handling rules. If the requester's records include biometric identifiers — face-geometry templates, voiceprints — the disclosure and deletion analysis is shaped by the biometric-specific regimes canvassed in Biometric Privacy Law and the AI Systems That Read Faces and Voices; and if any of the data is protected health information, a DSAR intersects with HIPAA's separate access-and-amendment framework, mapped in HIPAA in the Cloud: Business Associates, BAAs, and Protecting ePHI. Do not answer a health-data or biometric-data request under the state-privacy rulebook alone.

Tidewater's exemptions. Marisol's deletion request hits an exemption: Tidewater must retain her invoice and payment records to comply with tax and fraud-prevention obligations, so it deletes her marketing profile, account login, and support history but retains a minimal transaction record — and its response letter says exactly that. Jonas's access file is redacted to remove a second customer's name that appeared in a shared support thread, and Tidewater withholds the internal fraud-scoring notes under the security exemption, logging the basis for each.

Phase 6 — Fulfilling each right correctly

  • [ ] Access / right to know: produce the personal data (or categories, sources, purposes, and recipients) in a concise, intelligible, plainly worded format; for the CCPA, cover the 12-month lookback (broader on request under CPRA)
  • [ ] Deletion / erasure: delete from production systems, direct processors to delete, and address backups per your retention rules; confirm what was deleted and what was retained under exemption
  • [ ] Correction / rectification: update inaccurate data and notify processors and, where required, downstream recipients
  • [ ] Portability: provide the data in a structured, commonly used, machine-readable format (GDPR Art. 20; CCPA portability for the right to know)
  • [ ] Opt-out of sale/sharing/targeted advertising: stop the sale/share, honor Global Privacy Control signals, and flow the opt-out to relevant recipients — no verification required to opt out
  • [ ] Send instructions to every processor and confirm they executed the request
  • [ ] Deliver the response securely (encrypted file, authenticated portal), never as an open attachment to an unverified address

Why it matters, and the traps. Each right has its own deliverable and its own failure mode. For access, the trap is a data dump — a raw database export that no human can read violates the GDPR's Article 12(1) requirement of "concise, transparent, intelligible and easily accessible form, using clear and plain language." For deletion, the trap is the "delete the record, keep the shadow" problem: you delete the CRM entry but leave copies in the email platform, the data warehouse, and the vendor's system. Deletion means telling your processors to delete too. For opt-out of sale/sharing, the traps are twofold: many businesses do not realize that sharing data with an ad-tech vendor for cross-context behavioral advertising is a "sale" or "share" under the CPRA, and many fail to honor the Global Privacy Control browser signal, which California treats as a valid opt-out. For portability, a PDF is not "machine-readable"; JSON or CSV is.

Tidewater fulfilling. For Jonas, Tidewater assembles a plain-language access summary (categories, sources, purposes, recipients) plus a structured JSON export of his order and profile data, delivered through an authenticated download link. For Marisol, it deletes across Shopify, Klaviyo, and Zendesk, sends deletion instructions to each processor, receives written confirmation, and preserves only the tax-required transaction record. When Marisol later also submits an opt-out of sale, Tidewater flips her ad-tech sharing flag off and confirms — no identity verification demanded, because the law does not permit it for opt-outs. Because that same flag also governs Tidewater's marketing email, the opt-out should be reconciled with the separate unsubscribe machinery required by federal email law; see CAN-SPAM Compliance for Commercial Email: A Practical Checklist so a privacy opt-out and an email unsubscribe do not fall out of sync. Businesses building the request-response mechanism into their site should coordinate this with their public disclosures; see Drafting a Privacy Policy: A Practical Checklist so the rights you promise on paper match the rights you deliver in practice.

Phase 7 — Deadlines, extensions, denials, and appeals

  • [ ] Calendar the base deadline and the extension deadline at intake (GDPR: one month + up to two more; CCPA: 45 days + one 45-day extension)
  • [ ] To extend, notify the requester before the base deadline expires and state the reason
  • [ ] If you deny in whole or part, tell the requester which right, on what legal basis, and what they can do next
  • [ ] Provide the GDPR data subject notice of the right to complain to a supervisory authority and to a judicial remedy (Art. 12(4))
  • [ ] Provide the appeal mechanism required by Virginia, Colorado, and other state laws (a distinct, documented internal appeal within a set window)
  • [ ] Respond to an appeal within the statutory appeal deadline and, for some states, inform the consumer how to contact the state attorney general
  • [ ] Do not charge a fee unless the request is manifestly unfounded or excessive, and document why if you do

Why it matters, and the traps. Deadlines are the enforcement pressure point. The GDPR permits a two-month extension for complex or numerous requests under Article 12(3), but only if you tell the data subject within the first month and explain the delay. The CCPA allows one 45-day extension, again with notice. The trap is a silent extension — quietly taking more time without notifying the requester, which converts a lawful extension into a violation. On denials: you must be specific. "We can't help you" is not a lawful denial; "we are retaining your transaction records under Cal. Civ. Code § 1798.105(d)(1) to complete your purchase and comply with tax law, and have deleted everything else" is. On appeals: Virginia (Va. Code § 59.1-577) and Colorado (Colo. Rev. Stat. § 6-1-1306) require a formal appeal process that California's statute does not; if you serve Virginians and Coloradans, you need an appeal workflow and a template response, or you will blow the appeal deadline you did not know you had.

Tidewater's deadlines. Jonas's request is straightforward, so Tidewater responds in three weeks — inside the one-month window, no extension needed. Marisol's spans five systems and a processor, so Tidewater invokes the 45-day extension, notifies her in writing on day 40 of the first period, and completes on day 70. Because Tidewater also serves Virginia and Colorado customers, its response templates already carry an appeal-rights paragraph that it activates whenever it denies a request from those states.

Phase 8 — Recordkeeping and metrics

  • [ ] Log every request and its disposition in a durable register (received, verified, right, jurisdiction, outcome, dates, denials, appeals)
  • [ ] Retain proof of what you produced, deleted, or corrected, and the legal basis for any withholding
  • [ ] Track the CCPA metrics some businesses must publish: number of requests received, complied with (in whole or part), denied, and mean/median days to respond
  • [ ] Review the register periodically for missed deadlines, recurring denials, and process gaps
  • [ ] Feed lessons back into the data map, retention schedule, and vendor contracts

Why it matters, and the traps. Accountability is a legal requirement, not a nicety. The GDPR's Article 5(2) makes the controller responsible for demonstrating compliance, and under the CCPA Regulations a business that knows or should know it handles the personal information of 10 million or more consumers a year must compile and disclose request metrics annually. The trap is the undocumented "quiet handle" — the well-meaning support agent who deletes a customer's account off-ticket and leaves no record. If a regulator later asks how you handled a request, "we're pretty sure we did it" is not an answer. A clean register is also your best defense: it shows a pattern of timely, reasoned responses. For how this recordkeeping nests inside the broader program, see The Privacy and Data Protection Toolkit: Building and Operating a Compliance Program and, for the website-facing pieces, The Website and Internet Law Toolkit.

Common Mistakes to Avoid

  • Starting the clock at verification instead of receipt. The deadline runs from the day the request arrives. Verification happens inside that window, not before it.
  • Losing requests in a shared inbox. A rights request in a support DM or a mailed letter counts. Centralize intake or you will miss deadlines you never saw.
  • Over-verifying. Demanding a passport to confirm an email you already hold both annoys the customer and creates a fresh pile of sensitive data you now must protect.
  • Under-verifying. Shipping a full data export to an unverified email address is a breach you caused. Match rigor to sensitivity.
  • Rubber-stamping — or stonewalling — authorized agents. Both extremes draw regulator attention. Follow the agent-verification rules precisely.
  • The forgotten system. The rogue marketing spreadsheet, the analytics vendor, the founder's personal export. If it holds personal data, it is in scope. Keep the data map current.
  • Deleting the record but keeping the shadows. Deletion means production systems, backups per policy, and every processor. Send the delete instruction downstream and confirm.
  • Treating a "sale/share" too narrowly. Cross-context behavioral advertising is a "share" under the CPRA. Ignoring Global Privacy Control signals is a documented enforcement priority.
  • Dumping raw data as an "access" response. The GDPR requires concise, intelligible, plain-language output. A database export is not compliant.
  • Silent extensions. You may extend, but only if you notify the requester before the first deadline lapses and explain why.
  • Vague denials. Cite the specific exemption and say what you kept, deleted, and why.
  • Ignoring the state appeal right. Virginia, Colorado, and others require an appeal process California does not. Build the template before you need it.
  • No paper trail. If you cannot show what you did, you cannot show you complied. Log everything.

Consolidated one-glance checklist

Before any request (standing readiness)

  • [ ] Rights matrix by jurisdiction, with deadlines and extension rules
  • [ ] Current data map / RoPA reaching every system and processor
  • [ ] Two designated intake channels routed to one owner
  • [ ] Verification playbook (sliding-scale rigor; agent and minor rules)
  • [ ] Response templates: access, deletion, correction, portability, opt-out, denial, appeal
  • [ ] Processor contracts obligating assistance with rights requests

When a request arrives

  • [ ] Timestamp receipt; log in the register; calendar base + extension deadlines
  • [ ] Acknowledge receipt (CCPA: within 10 business days)
  • [ ] Identify jurisdiction, right(s) invoked, and governing law
  • [ ] Verify identity to the right degree of certainty (or confirm agent authority)
  • [ ] Scope the data across all systems and processors
  • [ ] Apply exemptions; redact third-party data; document each withholding
  • [ ] Fulfill the specific right in the required format, delivered securely
  • [ ] Send processor delete/correct instructions and confirm execution
  • [ ] Respond within the deadline (notify before extending)
  • [ ] On denial: cite the basis; provide complaint/appeal rights
  • [ ] Record the disposition; update the data map and metrics

Primary Authority

  • General Data Protection Regulation, Regulation (EU) 2016/679, arts. 12 (transparency and modalities), 15 (access), 16 (rectification), 17 (erasure), 18 (restriction), 20 (portability), 21 (objection), 22 (automated decision-making), and 5(2) (accountability).
  • California Consumer Privacy Act, as amended by the CPRA, Cal. Civ. Code § 1798.100 et seq. — including § 1798.105 (deletion and its exemptions), § 1798.106 (correction), § 1798.110 and § 1798.115 (right to know), § 1798.120 (opt-out of sale/sharing), and § 1798.130 (response timing and methods).
  • CCPA Regulations, 11 Cal. Code Regs. § 7000 et seq. — verification standards, authorized-agent rules, timing, and request-metrics obligations.
  • Virginia Consumer Data Protection Act, Va. Code § 59.1-575 et seq. — consumer rights and the § 59.1-577 appeal process.
  • Colorado Privacy Act, Colo. Rev. Stat. § 6-1-1301 et seq. — consumer rights and the § 6-1-1306 appeal process.
  • Companion state comprehensive privacy laws (Connecticut, Utah, and the growing roster) follow the Virginia/Colorado template with jurisdiction-specific deadlines and appeal rules — confirm the current statute for each state where you have consumers.

Related UpLaw Resources

Related Guides & Articles

Related Checklists

Related Toolkits

This checklist is general legal information from UpLaw (uplaw.us), not legal advice, and does not create an attorney-client relationship. Statutes, rules, and fees change; verify current requirements and consult qualified counsel before acting.