Skip to content
Magist
AnalyzeRegulationsVendorsCounselUpdatesCompareAbout
← All Controls

Data subject access request (DSAR) intake process

dsar-inboxDomain: data-privacyType: process

Description

Data subject access requests are the single most operationally demanding piece of most modern privacy regulations. A person the operator has never met asks for everything the operator holds on them, the operator has a fixed window to verify that the requester is actually the person they claim to be, and then the operator produces a complete and machine-readable response covering every data store under its control. The window varies by jurisdiction in load-bearing ways: GDPR Articles 15 to 22 set a 30-day clock that is extendable to 90 with written notice; CCPA gives 45 days with the same 90-day extension; Colorado mirrors CCPA at 45; Virginia matches; Brazil's LGPD compresses to 15 days under Article 18, which is the tightest mainstream window and the one operators with Brazilian users most often miss. A working DSAR system handles the cycle end-to-end. Intake comes through a form or a dedicated inbox, and the routing distinguishes the regulatory request from the support ticket that looks similar (a customer asking what data the operator has on them under CCPA reads identically to a customer asking the same question under support semantics; the routing decides which clock starts). Identity verification scales to the sensitivity of the data: a verified-email check is proportional for a request against a low-stakes consumer account, a government-ID check is proportional for a request that would expose financial or health data, and the regulators have explicitly warned against over-verification that has the practical effect of refusing legitimate requests. Internal lookup is where the difficulty actually lives: most products have grown three or four data stores by year two (the primary operational database, the analytics warehouse, the customer-support tool, the email-marketing platform), and the discovery surface across them is rarely captured in any single map. Response templating produces the machine-readable export (JSON or CSV are the GDPR-acceptable shapes; CCPA defers to "a portable and, to the extent technically feasible, readily usable format"). An audit log records every step. And a calendar tracks the regulatory clock on each open request. The operational pressure points are concentrated in a few places. Identity verification at scale (avoiding both wrongly disclosing data to an imposter and wrongly refusing a legitimate request) is harder than first-pass designs assume. Data-store discovery is the part vendors fulfill least well because the discovery has to reach the operator's specific schemas; OneTrust, Transcend, and similar tools provide the orchestration layer but the connectors to the operator's actual systems are the operator's work. Timeline tracking when DSAR volume is bursty (the typical pattern after a privacy-policy-change news cycle) is the failure mode that produces the cleanest enforcement narratives. And contested-context requests (former employees, plausibly-pretextual outside parties, multi-product accounts spanning consumer and B2B sides) are where the second-order failure modes hide; planning for them in advance is materially cheaper than improvising during. The hard part is usually not the intake; it is the lookup, and the operational difficulty there is documentation depth rather than regulatory shape.

Required by (17 regulations)

  • CCPA/CPRA

    12-month lookback; verifiable consumer request; response within 45 days (extendable to 90).

    Cal. Civ. Code §§1798.100-1798.199.100; 11 CCR §7000-7102

  • CPA

    6-1-1306 — 45-day response.

    Colo. Rev. Stat. §§6-1-1301 to 6-1-1313; 4 CCR 904-3

  • DPDPA

    India DPDPA: 7-15 day response window for data principal requests; Rules notified 2025-11-13; Phase II (consent managers) effective 2026-11-13; Phase III (substantive DSR obligations) effective 2027-05-13.

    Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023), published in the Gazette of India on August 11, 2023

  • GDPR

    Articles 15-22 — 30-day response (extendable to 90 with notice); identity verification.

    Regulation (EU) 2016/679 of the European Parliament and of the Council

  • LGPD

    Article 18 — response within 15 days.

    Lei nº 13.709, de 14 de agosto de 2018 (as amended by Lei nº 13.853/2019 and Emenda Constitucional nº 115/2022)

  • PIPA

    Korea PIPA: 10-day response window for data subject access requests under PIPA Article 35.

    Personal Information Protection Act (Act No. 10465, enacted March 29, 2011; last wholly amended by Act No. 19234, effective September 15, 2023)

  • PIPEDA

    Canada PIPEDA: 30-day response window with one 30-day extension permitted on notice; Section 8.

    S.C. 2000, c. 5 (Personal Information Protection and Electronic Documents Act)

  • PIPL

    China PIPL Article 45: 15 working day response window for data subject requests.

    Personal Information Protection Law of the People's Republic of China (adopted August 20, 2021, effective November 1, 2021)

  • Privacy Act

    Australia Privacy Act APP 12 + APP 13: reasonable steps within a reasonable time; OAIC guidance suggests 30 days. Privacy and Other Legislation Amendment Act 2024 (effective 2024-12-10) adds statutory tort effective 2025-06-10.

    Privacy Act 1988 (Cth), No. 119 of 1988

  • PDPL

    Saudi PDPL: 30-day response window for data subject access requests; Implementing Regulations Article 18.

    Royal Decree M/19, dated 9/2/1443 AH (September 16, 2021), Personal Data Protection Law, effective September 14, 2023

  • Thailand PDPA

    Thailand PDPA: 30-day response window for data subject requests under PDPA Section 30.

  • KVKK

    Turkey KVKK: 30-day response window for data subject requests under Article 13; SCC/BCR cross-border transfer mechanism added by 8th Judicial Reform Package 2024-03-12.

  • UAE Data Protection Law

    UAE PDPL: response timing established by Executive Regulations (issued by UAE Data Office; details still being operationalized as of mid-2026).

  • VCDPA

    Section 59.1-577 — 45-day response.

    Va. Code §§59.1-575 to 59.1-585

  • UK GDPR

    UK GDPR Articles 15-22 (data subject rights, parallel to EU GDPR) + DPA 2018 Part 3 (law-enforcement processing). Data (Use and Access) Act 2025 (DUAA) Part 5 amendments commenced 2026-02-05 introduce a stop-the-clock mechanism for complex requests (28-day window can pause if information is required from the requester), a reasonable-and-proportionate threshold for vexatious / excessive requests, and a 2-month extension entitlement for complex requests (matching GDPR Article 12(3)).

    UK GDPR (retained Regulation 2016/679) Articles 15-22; Data Protection Act 2018 (UK Public General Acts c.12); Data (Use and Access) Act 2025 Part 5 (commenced 2026-02-05)

  • Washington MHMDA

    Handles MHMDA consumer rights requests (access, deletion, consent withdrawal).

    Washington My Health My Data Act (HB 1155, 2023)

    Source →

  • Chile Law 19.628

    Chile's data-protection regime grants access, rectification, and deletion rights requiring an intake channel.

    Ley N° 19.628 sobre Protección de la Vida Privada (1999); to be substantially superseded by Ley N° 21.719 (2024) effective 2026-12-01

    Source →

Fulfilled by (4)

  • onetrust · full · low effort · $$
  • transcend · full · low effort · $$
  • didomi · partial · medium effort · $$
  • In-house build · high effort
    Requires identity-verification flow + cross-system data-discovery; usually under-resourced when built in-house.

Magist does not accept payment from vendors. Methodology.

Evidence formats

  • DSAR intake form
  • request-tracking system
  • response templates
  • verification logs
  • response-time SLA dashboard

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions.

Magist

Pre-launch regulatory analysis for product teams. Built by a lawyer, designed for PMs.

Tools

  • Analyze
  • Guided walkthrough
  • Vendors
  • Find counsel
  • Saved analyses

Reference

  • Scope by business model
  • Scope by jurisdiction
  • App ratings
  • Regulations
  • Compare regulations
  • Enforcement
  • Browse Controls
  • Vendor coverage
  • Radar
  • Pulse
  • Changelog
  • Guides
  • Regulatory updates
  • Open data
  • Corpus license
  • Ontology
  • State of Compliance

Solutions

  • For legal teams
  • For engineering
  • For executives
  • For law firms
  • For investors
  • For teams →

About

  • About Magist
  • Methodology
  • Editorial standards
  • Reviewers
  • Coverage status
  • Corrections
  • Trust
  • Coverage scope
  • How we handle data
  • Sub-processors
  • FAQ

Built by Neel Patel, a practicing in-house games attorney. Games touch more compliance domains at once than anything else in tech — Magist was designed around that.

Magist provides legal information based on publicly available regulatory sources. It does not constitute legal advice and does not create an attorney-client relationship. Consult a licensed attorney in your jurisdiction before making compliance decisions. Operated by a Washington-licensed attorney. Not licensed in California or other US states. Magist provides legal information; consult a licensed attorney in your jurisdiction.

Magist is an instrument, not a consultancy. It does not sell compliance services or take payment from vendors for placement; the analysis is the same for everyone. No vendor, sponsorship, or referral fees, ever.

MethodologyLimitationsDisclosures

© 2026 Magist
TermsLicensePrivacySecurityLinkedIn