DSAR Guide: Handling Data Subject Requests at Scale

A data subject access request (DSAR) is a legal deadline, an enterprise-wide search and an identity verification problem at the same time, and most organisations only discover how hard it is when volumes rise or an attacker sends one. The GDPR, the UK GDPR as amended by the Data (Use and Access) Act 2025 and the California Consumer Privacy Act (CCPA) give people rights to access, correct, delete and move their data, each with its own clock, verification rules and exemptions. This guide covers the DSAR lifecycle: intake, identity checks, search across systems, email and logs, redaction, exemptions, secure delivery, erasure and automation. It is written for privacy operations teams, DPOs, security engineers and the identity teams who own verification.

Key takeaways

The clock starts earlier than most teams think. Under the GDPR the month runs from receipt; under the UK's new Article 12A it starts at the latest of receipt, requested identity information or fee; under the CCPA verification time does not pause the 45 days.
Verification must be proportionate, not maximal. The EDPB says a copy of an ID document should generally not be the way you authenticate someone, and California scales verification to the sensitivity of the data. Reuse existing authentication wherever you can.
A DSAR is an attack channel. Researchers have obtained other people's data simply by asking. Deliver only to a verified channel and treat a request that follows a contact detail change as an account takeover signal.
Search scope is defined by your data map. The UK now limits the duty to a "reasonable and proportionate search", but email, tickets, logs and AI tooling are still in scope, and you must record why you stopped.
The DSAR platform is a privileged non-human identity. Connectors that can read and delete personal data across every system need the secrets, least privilege and logging controls of any high-risk service account.

The rights and their deadlines

"DSAR" is used loosely for any data subject request. Strictly, it is the Article 15 right of access; the other rights have different tests. California requires a "verifiable consumer request" for access, deletion and correction.

Right	GDPR / UK GDPR	CCPA (as amended by CPRA)	Practical notes
Access (right to know)	Art. 15: confirmation, a copy, and information on purposes, recipients, retention, source and automated decision-making	Categories or specific pieces, covering the prior 12 months, or longer for data collected on or after 1 January 2022	The highest-risk request: it hands data to whoever you decide is the requester
Rectification / correction	Art. 16	Civ. Code 1798.106	California says verify with information unrelated to the disputed item
Erasure / deletion	Art. 17 (the right to be forgotten), exceptions in 17(3); Art. 19 notify recipients	Civ. Code 1798.105	Irreversible, so a fraudulent request causes real harm
Restriction	Art. 18	Closest equivalent: right to limit use of sensitive personal information	No verification may be required for California limit requests
Portability	Art. 20: data the person provided, processed by consent or contract and by automated means, in a structured, commonly used and machine-readable format	Handled through the response to a request to know specific pieces	Output format is the main engineering task
Objection / opt-out	Art. 21; absolute for direct marketing	Opt-out of sale or sharing	California prohibits requiring verification for opt-outs

GDPR Article 83(5) puts infringements of Articles 12 to 22 in the higher fine tier, up to EUR 20 million or 4% of worldwide annual turnover.

How each clock works

Element	EU GDPR	UK GDPR (after DUAA 2025)	CCPA regulations
Base period	Without undue delay and within one month of receipt (Art. 12(3))	One month from the "relevant time" (Art. 12A, in force 5 February 2026)	45 calendar days (11 CCR 7021(b))
Start point	Receipt of the request	Latest of receipt of the request, of identity information you asked for, or of a fee	Receipt, "regardless of time required to verify the request"
Pause	None in the text; you may ask the person to specify where you hold a large quantity of data	Clock stops while you wait for information reasonably needed to identify the data sought	None
Extension	Two further months for complexity or number of requests, notified with reasons within the first month	Same	A further 45 days (90 in total) with notice and reasons
Acknowledgement	Not required	Not required	Confirm receipt within 10 business days and describe verification
Refusal	Reasons and right to complain within one month (Art. 12(4))	Same	Deny and explain where verification fails

Intake and triage

A request needs no form, keyword or channel. The EDPB states that no specific format is required, and the ICO notes requests can be verbal and made to any member of staff. California requires at least two designated methods including a toll-free number, or only an email address for a business that operates exclusively online with a direct relationship to the consumer, and a business cannot require an account to make a request.

Single register: log every request in one case system on the day it arrives, with timestamp, channel, regime, right and computed due date. One letter often contains several requests.
Routing: train customer service, HR and recruitment to forward requests the same day. A request sitting in a shared inbox for two weeks has used half its time.
Do not ask why: the EDPB says controllers should not assess "why" someone wants access. Litigation motives do not invalidate a request.
Agents and portals: the ICO says it is the third party's "responsibility to provide evidence of their authority". In California a business may require signed permission and ask the consumer to verify directly or confirm the agent's permission, but "shall not require power of attorney". Watch commercial rights portals for templated bulk submissions.

Manifestly unfounded or excessive

GDPR Article 12(5) and Civ. Code 1798.145(h)(3) both allow a reasonable fee or a refusal for manifestly unfounded or excessive requests, and both put the burden of proof on the organisation. The EDPB says these concepts "have to be interpreted narrowly" and the ICO describes "a high threshold". Size, inconvenience and an ongoing dispute do not make a request excessive. Document the reasoning and give the person their complaint rights.

Verifying identity without opening an attack path

Article 12(6) allows a request for additional information only on "reasonable doubts" about identity. The EDPB adds that an existing login is generally sufficient and that ID document copies "should generally not be considered an appropriate way of authentication"; the ICO says to "only request formal identification if necessary". California prescribes levels: a reasonable degree of certainty, which "may include matching at least two data points", for a request to know categories, and a reasonably high degree, at least three pieces of information plus a "signed declaration under penalty of perjury", for specific pieces. "Sensitive personal information shall warrant a more stringent verification process", and businesses must maintain measures to detect fraudulent identity-verification activity.

The risk is real. At Black Hat USA 2019, Oxford researcher James Pavur sent GDPR access requests for his partner's data to more than 150 organisations using only her name, email address and phone number. According to Infosecurity Magazine, 24% provided the data and a further 16% accepted a weaker check he could satisfy; returned data included hotel stay records and a US Social Security number.

Scenario	Suggested verification	Delivery
Logged-in customer requesting access	Existing session, with re-authentication or step-up MFA before download	In-account, time-limited download
No login, low-sensitivity data (marketing, browsing)	Match two data points you already trust; one-time code to the contact detail on file	Contact detail on file, not the one in the request
Sensitive data (health, financial, precise location, ID images)	Three data points or a one-time code plus a check against non-public data; California adds the signed declaration	Portal with MFA; never email attachments
Erasure of an active account	Re-authentication, or verification equal to account recovery	Confirmation to the contact on file before execution
Employee or former employee	HR records and a known personal contact	Portal or encrypted media
Agent or third party	Evidence of authority plus direct confirmation by the individual	To the individual, or to the agent once confirmed

Reuse, do not collect: California limits extra verification data to verification, security or fraud prevention and requires deletion "as soon as practical".
Bind delivery to the verified channel: the common fraud pattern is a request from a new email address. Send codes and data to the contact detail on file.
Correlate with account changes: a contact detail change followed within days by an access or erasure request is an account takeover pattern; route it to fraud review. See the Account Takeover Prevention Guide.
Treat the DSAR desk like a help desk: phone and chat channels face the same impersonation pressure as password resets, the route that exposed member data in the Co-op cyber attack. See the Account Recovery and Help Desk Security Guide.
Proofing from scratch: for requesters with no account and sensitive data, use document verification with liveness as a last resort and delete the images after the check. See the Identity Proofing and KYC Guide.
Cannot verify: under 11 CCR 7062 a business must deny a request for specific pieces it cannot verify; under Article 12(2) a controller can refuse only if it shows it cannot identify the person.

Searching at scale, including logs and machine data

Access means "access to the actual personal data themselves", including pseudonymised data, and the EDPB expects a search across IT and non-IT filing systems. In the UK, section 78 of the Data (Use and Access) Act 2025 inserted Article 15(1A): the person is entitled to what the controller can provide "based on a reasonable and proportionate search", treated as in force from 1 January 2024. That codifies proportionality; it does not excuse skipping a system you know holds the data.

Start from the data map: every system in the record of processing should carry a search method (API query, saved report or manual procedure) and an owner. See the Data Mapping and ROPA Guide.
Resolve identifiers first: collect every identifier the person is known by (customer IDs, emails, phone numbers, device IDs, employee number, pseudonymous keys) and search on all of them.
Unstructured data: email, chat, tickets and shared drives produce most of the volume and redaction work; use eDiscovery tooling with agreed custodians and date ranges.
Logs and audit trails: in Pankki S (C-579/21, 22 June 2023) the Court of Justice held that a person is entitled to information on consultations of their data, including dates and purposes, but not generally to the identity of employees acting under the controller's authority unless that is essential to exercise their rights.
Data written by non-human identities: agent memory, prompt and response logs, retrieval indexes and notes generated by bots and service accounts are still personal data about the person described. The audit trail of which service account touched a record also answers the Pankki question.
Backups and deleted data: the EDPB says you need not provide data you no longer hold, but must not erase data to avoid a request. Set a policy for when backups are searched.
Processors: Article 28(3)(e) requires processors to assist; contract for search and deletion turnaround well inside your own deadline.

Redaction, exemptions and delivery

Article 15(4) protects the rights of others, but the EDPB says it "should not result in refusing the data subject's request altogether": redact or withhold specific parts. The UK Data Protection Act 2018 Schedule 2 exemptions most often relevant are legal professional privilege, management forecasts, negotiations with the requester, confidential references and crime and taxation. Apply them item by item and record why.

Third-party data: redact other people's details unless they consent or disclosure is reasonable without consent, and record the reasoning.
Redaction quality: remove text from the document layer and strip metadata; boxes drawn over PDF text and hidden spreadsheet columns are a well-known cause of accidental disclosure.
Complete response: send the Article 15 information with the data, generated from the data map, and explain internal codes as the EDPB expects.
Secure delivery: an authenticated portal with time-limited, logged downloads; electronic requests get electronic replies, and portability needs structured output such as JSON or CSV.

Erasure, correction and downstream propagation

Erasure must reach every copy. Article 19 requires telling each recipient about erasure, rectification or restriction unless impossible or disproportionate. Exceptions under Article 17(3) include freedom of expression, legal obligation, public task, archiving and research, and legal claims.

Backups: the ICO says "the key issue is to put the backup data 'beyond use', even if it cannot be immediately overwritten". Re-apply erasures if a backup is restored.
Suppression lists: keep the minimum needed (for example a hashed email) so a re-imported record does not resurrect marketing.
Retention holds: legal holds and statutory records override erasure for the data they cover; tell the person what you kept and why.
AI systems: models and embeddings can retain personal data. See the AI and Privacy Guide.

Choosing an operating model

Model	Fits	Strengths	Weaknesses
Manual with ticketing	Tens of requests a year, few systems	Cheap, human judgement on every case	Deadlines slip as volume grows; no record of what was searched
Privacy platform with system connectors	Hundreds to thousands a year, many SaaS systems	Due-date tracking, templates, automated discovery and deletion	Connectors need broad privileges; unconnected systems are silently missed
Self-service in the authenticated account	High-volume consumer services	Verification solved by login; immediate download	Covers only data the product exposes; email, logs and support records still need a back-office search

Small organisations can run a documented manual process; large ones usually combine self-service for account data with a platform for everything else, plus specialists for employee and litigation-linked requests.

Where identity fits: the DSAR platform as a non-human identity

A DSAR platform holds OAuth grants, API keys or service accounts able to read, export and delete personal data across connected systems. Scope each connector to the minimum operations, give each its own identity rather than one shared admin account, keep secrets in a vault with rotation, log every query and deletion to the SIEM, and include the grants in access reviews. See the Service Account Security Guide and the SaaS and OAuth App Governance Guide.

Implementing a DSAR programme

Baseline: count the open backlog and the last 12 months of requests by type and channel, measure average and worst-case response times, and list systems with no search method.
Procedure: write intake, verification, search, exemption, redaction and delivery steps, with a verification matrix approved by the DPO and the fraud or security team.
Map search methods: give every system in the data map a search and deletion method and owner; add assistance clauses to processor contracts.
Pilot: run one request type in one region for a month, with a second reviewer checking every response before release.
Test verification: have the fraud or red team submit requests from new email addresses and through fake agents; none should succeed. Repeat after each process change.
Automate in stages: connect the highest-volume systems first and run automated discovery alongside manual search until results match. Run automated deletion in report-only mode first.
Roll back: keep the manual procedure staffed during transition; if a connector returns incomplete results or deletes too broadly, disable it and revert to manual handling for that system.

Detection and measurement

Treat the request stream as a security signal: spikes from one source, requests naming different people from one IP address or email domain, requests shortly after contact detail changes, repeated failed verification and bulk agent submissions. Log every export, download and deletion with the case number and the human or service account that performed it.

On-time rate: requests closed within the statutory period, by regime, and extensions as a share of all requests.
Time to close: median and 95th percentile; the tail shows which systems and request types cause late responses.
Verification failure and fraud rate: requests refused for failed verification and those confirmed fraudulent.
Search coverage: share of data map systems with a tested search and deletion method.
Rework rate: responses reopened after a complaint, missed data or over-disclosure.

Framework mapping

DSAR activity	Legal basis	NIST Privacy Framework 1.0	Control frameworks
Request policy and intake	GDPR Art. 12(2); CCPA 1798.130(a)(1)	CT.PO-P3	ISO/IEC 27001:2022 A.5.34; SP 800-53 PM-26
Identity verification	GDPR Art. 12(6); 11 CCR 7060 to 7062	None specific	SP 800-53 IA-12
Search and access	GDPR Art. 15; UK GDPR Art. 15(1A)	CT.DM-P1, CT.DM-P2	CIS Controls v8.1 3.2; SP 800-53 PM-21
Correction	GDPR Art. 16; CCPA 1798.106	CT.DM-P3, CM.AW-P5	SP 800-53 SI-18
Erasure and recipient notice	GDPR Arts. 17, 19; CCPA 1798.105	CT.DM-P4, CT.DM-P5	ISO/IEC 27001:2022 A.8.10; CIS 3.5; SP 800-53 SI-12
Portability	GDPR Art. 20	CT.DM-P6	None specific
Logging and complaints	GDPR Art. 12(4)	GV.MT-P7	SP 800-53 AU-2; ISO/IEC 27001:2022 A.5.33

Common failure patterns

Sending data to the address in the request: a reply from an unverified address is not verification, as Pavur's results show.
Automated channels acting without checks: a bot or form that triggers exports or recovery on request is an attacker's tool; an AI support assistant sending recovery links to attackers drove the Meta AI Instagram account takeover.
Over-verification: demanding passport copies from logged-in customers breaches the EDPB's proportionality guidance and creates a new store of ID images.
Searching only the CRM: email, tickets, logs and AI tool histories are where disputes live.
Erasure that does not propagate: data persists in processors, analytics copies and restored backups and returns at the next import.

Practitioner checklist

Log every request in one case system on receipt with regime, right and computed due date.
Publish request channels that meet each regime, including a toll-free number where the CCPA requires it.
Adopt a risk-tiered verification matrix that reuses existing authentication and delivers only to verified channels.
Route requests that follow contact detail changes to fraud review.
Give every system in the data map a tested search and deletion method and an owner.
Include logs, email, tickets, AI tools and processors in search scope and record proportionality decisions.
Apply exemptions and redactions item by item, with reasons in the case file.
Deliver through an authenticated, logged portal with time-limited downloads.
Scope, vault and monitor every DSAR platform connector as a privileged non-human identity.
Report on-time rate, verification failures and search coverage quarterly.

Standards and references

Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · Privacy Programme Guide for Security Teams · Consent Management Guide: Cookies, CMPs and GPC · Identity Data Privacy and Consent Guide. This guide summarises data subject rights under the GDPR, UK GDPR and CCPA and is not legal advice.