Loading…
A Data Subject Access Request (DSAR) is a request by a person to see what personal data you hold about them. Every major privacy regime (GDPR, UK GDPR, CCPA/CPRA, DPDPA, LGPD, PDPA, APPI) gives data subjects a version of this right. The shortest statutory window — California's — is 45 days. The longest with extensions — GDPR — is three months.
Build one pipeline that satisfies the shortest applicable window. Five stages: Intake → Identity verification → Data gathering → Review & redact → Deliver & log. Track every step. Treat the audit trail as a first-class artefact, not a side effect.
The temptation is to build per-framework workflows: one for GDPR, one for CCPA. Don't. A single pipeline with framework-aware metadata is:
The diagram above shows the full flow. The next five sections cover each stage in operational detail.
Provide multiple intake channels — a self-service web form, a dedicated email address (typically privacy@ or dpo@), a postal address, and (in some jurisdictions) a phone number. GDPR is technology-neutral, but Supervisory Authorities expect parity across channels.
Each intake event should capture, at minimum:
Assign a case ID. Acknowledge receipt within 10 business days (the CCPA window) — applies to all requests for consistency.
GDPR Art. 12(6) lets you ask for additional information "necessary to confirm the identity of the data subject," but you must not ask for more than is proportionate. CCPA §1798.130(a)(2) requires "reasonable steps" to verify identity, with the standard scaling with sensitivity.
A pragmatic three-tier model:
Stop the clock during verification only to the extent reasonable. The CCPA explicitly permits the response time to be tolled during verification (15-day extension); GDPR does not, so over-engineering verification under GDPR is itself a risk.
The hardest step operationally. Build a system inventory mapping every system that stores or transits personal data, including:
For each system, have a documented extraction procedure keyed off your standard identifiers (user_id, email, phone). Use the GDPR Article 30 Records of Processing Activities as your scaffold — every entry there should map to a DSAR extraction routine.
Once data is gathered, review it for:
Have a redaction reviewer separate from the data gatherer where feasible — separation of duties reduces error.
Deliver via the same secure channel the data subject used, or another channel they choose. Encrypt the package. Provide a covering response explaining the contents, the categories of data, the purposes of processing, the recipients, the retention period, the source of the data, the rights, and the right to lodge a complaint with the Supervisory Authority.
Log: the request, the verification steps, the systems queried, the redactions applied (with reasons), the delivery channel, and the timestamps. This log is your defence in any audit or complaint.
| Regime | Acknowledge | Substantive response | Extension |
|---|---|---|---|
| GDPR / UK GDPR | No specific window — "without undue delay" | 1 month | +2 months for complex/multiple requests |
| CCPA / CPRA | 10 business days | 45 calendar days | +45 days when reasonably necessary |
| DPDPA (India) | No specific window | As prescribed by Rules; default reasonable timeframe | Not specified |
| LGPD (Brazil) | No specific window | 15 days for access; 30 days for confirmation of existence | Possible with reasoned justification |
| APPI (Japan) | No specific window | "Without delay" — typically 2 weeks | Reasonable extensions permitted |
| PDPA (Singapore) | No specific window | As soon as reasonably possible, ≤30 days | Notify with new estimated date if longer |
Default to the shortest applicable window. If you cover GDPR + CCPA, plan for 45 days end-to-end; if only GDPR, plan for the 1-month baseline.
You may refuse a request, in whole or part, when:
Document the basis for refusal. The data subject has a right to know why and to complain to the Supervisory Authority.
A real and growing risk. Threat actors use DSARs to (a) extract competitor data, (b) overwhelm small privacy teams, (c) probe for security weaknesses. The Article 12(5) GDPR "manifestly unfounded or excessive" standard is intentionally narrow — you may charge a reasonable fee or refuse, but documentation of why must be thorough.
Operational guardrails: rate-limit anonymous web-form intake; require a Tier-3 identity check before disclosing sensitive data; cap the volume of automated submissions from a single IP/email; and flag patterns (e.g., serial DSARs from competitor email domains) for senior review.
Under GDPR generally no — Article 12(5) makes responses free unless requests are manifestly unfounded or excessive. CCPA likewise prohibits fees for the first two requests in a 12-month period. Singapore PDPA permits a reasonable fee.
Technically yes if backups are reasonably retrievable, but Supervisory Authorities accept that backups need not be live-searched if your retention policy is documented and you commit to delete the data from backups when they roll over. Document this approach.
Same right, but often higher volume and more sensitive (performance reviews, manager notes, monitoring logs). German BDSG §26 imposes particular employee-data sensitivity. Have HR-specific extraction routines and engage employment counsel on grievance-context DSARs.
Yes — and Article 22 GDPR adds the right to meaningful information about the logic involved, the significance, and the envisaged consequences of automated decision-making. The EU AI Act amplifies this for high-risk AI under Article 26(11).
RegulatoryBridge ships a turnkey DSAR pipeline — intake forms, verification flow, system extractor library, redaction reviewer, delivery encryption, audit log — covering every privacy regime in scope.