Home · Synthesis · cl-us-state-privacy-consumer-rights

Cross-jurisdiction consumer / Data Principal rights — operational fabric

CCPA CPA CTDPA DPDPA FDBR GDPR ISO 27701 MODPA OCPA TDPSA UCPA USP-Other VCDPA MHMDA

Primary statement

Consumer / Data Subject / Data Principal rights operate across multiple jurisdictions with overlapping but distinct specifications. The audit-defensible rights fabric provides: (1) all six core rights — access, correct, delete, portability, opt-out of sale/sharing, limit sensitive personal information; (2) identity verification proportionate to data sensitivity; (3) response within the strictest SLA in scope (typically 30 days under DPDPA / CCPA / VCDPA; longer for free with extensions on documented basis); (4) Universal Opt-Out Mechanism (UOOM) honour where mandated (CO, CT, OR, TX from Jan 2025); (5) non-discrimination for rights exercise; (6) downstream propagation to processors / service providers / sub-processors.

Audit-fatigue payoff

A unified rights-management architecture — single intake portal, identity verification flow, response workflow with SLA tracking, downstream propagation API, UOOM honour mechanism — satisfies rights requirements across 19 US states + GDPR + DPDPA + ISO 27701 simultaneously. The strictest specifications: CCPA 1798.130 (intake method requirements), GDPR Article 12 (transparency and modalities), DPDPA Rule 14 (publication + response timelines), Maryland MODPA (strictest data minimisation). Without unification, the organisation operates 20+ separate rights pipelines (one per jurisdiction); with unification, the auditor sees one architecture that handles all jurisdictions with jurisdiction-specific configuration.

Strictness matrix

Scope

Rights scope: confirmation of processing + access to data + meta-information (purposes, categories, recipients, retention, source, automated decision logic, transfers). GDPR Article 15 specifies the broadest information set; the right of access extends beyond the data itself to the processing context. Other frameworks address subsets: CCPA 1798.110 (categories + specific pieces); DPDPA Section 11 (summary + Data Fiduciary identity + recipient identities). Ceiling source: gdpr:Art.15 Rationale: GDPR Article 15 is the broadest scope articulator — the right of access includes processing meta-information that other frameworks do not explicitly require. Building access to GDPR 15 specification satisfies CCPA / VCDPA / CPA / DPDPA simultaneously.

Threshold

Threshold: Maryland MODPA sets the strictest data minimisation standard — collection limited to what is reasonably necessary and proportionate, including a heightened minimisation standard for sensitive data (only what is "strictly necessary" for the service). This threshold drives the response to access / portability / delete requests: less data collected means less data to retrieve / port / delete. Cross-framework, the strictest minimisation is the audit-defensible threshold. Ceiling source: modpa:MD.14-4604 Rationale: Maryland MODPA (effective October 2025) is the strictest US data minimisation standard. Adopting MODPA-level minimisation simultaneously satisfies all narrower minimisation standards across the cluster.

Method

Method: (1) two or more designated request intake methods, including a toll-free number for businesses with a website + the website itself; (2) identity verification proportionate to data sensitivity (heavier for sensitive data, lighter for general); (3) response within the strictest applicable SLA — typically 30 days (CCPA, GDPR, DPDPA, VCDPA-style states); (4) confirmation of receipt within 10 days (CCPA); (5) extension permitted on documented basis to 45 days total; (6) non-discrimination for rights exercise (CCPA 1798.125); (7) downstream propagation — service providers / processors notified of correction / erasure requests within their contractual SLA. Ceiling source: ccpa:CCPA.1798.130 Rationale: CCPA 1798.130 is the most prescriptive method articulator, specifying intake methods, confirmation timeline, and the non-discrimination prohibition. Building to CCPA method satisfies all US state laws and provides the operational baseline for GDPR / DPDPA.

Frequency

Response SLA: 30 days standard across major frameworks. DPDPA Rule 14 specifies operational requirements including the website / app publication of intake mechanism + response within timeline. CCPA requires 45-day response with 45-day extension (90 days maximum with extension). GDPR requires 1 month with 2-month extension. The strictest universal SLA is 30 days; building to 30 days satisfies the floor across jurisdictions. Ceiling source: dpdpa:DPDP.24 Rationale: DPDPA Rule 14 provides the most operational specification of response SLA, including the publication-of-mechanism requirement. The 30-day SLA is the floor across jurisdictions; building to it is the audit-defensible cadence.

Evidence

Required evidence: (1) documented procedure for receiving, authenticating, evaluating, and responding to rights requests; (2) multiple intake channels documented; (3) identity authentication evidence (proportionate verification); (4) response records — sample requests with their full lifecycle traced; (5) SLA dashboard showing response time compliance; (6) downstream propagation evidence — sample correction / erasure requests with processor notification trace; (7) UOOM honour evidence (for CO, CT, OR, TX from Jan 2025); (8) non-discrimination posture documentation; (9) per-jurisdiction configuration evidence showing how the unified fabric handles jurisdiction-specific differences. Ceiling source: iso27701:A.1.3.7 Rationale: ISO 27701 A.1.3.7 specifies the most comprehensive evidence framework for rights handling. Adding the US-state specifics (UOOM, non-discrimination, CCPA confirmation requirements) on top of the ISO 27701 baseline produces the audit-defensible evidence pack.

Auditor test pattern

Step 1: Inspect the rights intake architecture; verify multiple channels including the CCPA-required toll-free for businesses with websites. Step 2: Sample 3 recent rights requests (across right types: access, delete, opt-out) and trace each through the full lifecycle including response timeline. Step 3: Verify SLA compliance against the strictest applicable timeline (30 days typically). Step 4: For a delete or correction request, verify downstream propagation to processors / service providers with confirmation receipt. Step 5: Inspect UOOM honour mechanism (for applicable jurisdictions); test that browser Global Privacy Control signal is detected and honoured. Step 6: Verify non-discrimination posture — rights exercise does not trigger reduced service.

Common findings

Common 2024–26 findings: (1) Access requests handled via generic support without proper identification or documented response; (2) Correction limited to certain fields (e.g., name yes, but not transaction history corrections); (3) Erasure not propagated to backups, processors, and downstream caches — deletion is one-database deep; (4) UOOM honour not implemented despite mandate (CO / CT / OR / TX from Jan 2025); (5) Identity verification too heavy or too light — heavy enough to chill rights exercise OR light enough to enable impersonation; (6) Non-discrimination posture undocumented; rights exercise correlates with service degradation; (7) Per-jurisdiction differences ignored — single rights pipeline doesn't honour jurisdiction-specific requirements (e.g., MODPA strict minimisation, FDBR limited applicability).