Skip to main content

​
CCPA/CPRA Posture: Consumer Rights on Orbit

The DSAR page documents the request pipeline end to end; this guide is the CCPA/CPRA posture around it — which consumer-rights verb covers which statutory right, when to apply it, how California’s state-level gating interacts with the request lifecycle, and how the jurisdiction code and consumer_categories subdivision carry through your organisation’s records. It is the California counterpart to Assembling a GDPR Posture End to End, and it sits in the same per-jurisdiction posture group in the nav.
This page describes Orbit’s platform controls. It is not legal advice. Whether CCPA/CPRA applies to you — the revenue, volume, or data-sale thresholds in Cal. Civ. Code §1798.140(d), the service provider vs. contractor distinction, what “selling” or “sharing” covers for your use — depends on your business. Confirm with qualified counsel.

​
The tenant-owned framing

Same model as every other posture on Orbit (posture overview):
  • Every control here defaults open. A new tenant has no pending requests, no portal link published, no retention window set, and no binder generations. Nothing on this page is mandated, and nothing here gates sending by itself — you assemble the posture; the platform enforces what you set.
  • Orbit is the conduit and the ledger. It carries the request from intake to fulfilment, runs the verification gate and the SLA clock, and keeps the auditable record. It never decides whether CCPA/CPRA applies to you, never files with the California Privacy Protection Agency or the Attorney General for you, and never answers a consumer’s legal question on your behalf.
  • Statutory citations below are signposts, not determinations. The platform tracks the clock and the verbs; whether a specific request is valid, which exemption applies (for example the B2B or employee carve-outs), or whether 45 days is shortenable in your case sits with your counsel.

​
Section 1 — The consumer-rights verb map

The CCPA (2018) and its CPRA amendment (effective 2023) define eight consumer rights. Each maps onto an operator request_type on POST /compliance/dsar; the public portal exposes a friendlier subset that resolves onto the same verbs. The full intake, schema, and portal flow are on DSAR — this table is the posture view. Two structural notes:
  • The statutory clock is 45 days. Filing a request with applicable_jurisdiction: "ccpa" or "cpra" starts a 45-day SLA clock — the response window in §1798.130(a)(2). The SLA dashboard tiers scale to that window (amber at 30–38 days, red at 39–45, breach past 45; escalation flagged at day 40). Track it with GET /compliance/dsar/sla, detailed on DSAR.
  • The CCPA-only verbs refuse a GDPR jurisdiction. opt_out_sale, limit_sensitive_pi, and non_discrimination have no GDPR equivalent, so filing one without setting applicable_jurisdiction: "ccpa" or "cpra" is rejected with 422 VALIDATION_ERROR — the gdpr default only covers rights that exist under GDPR.

​
Section 2 — When to apply each verb

The pipeline is rights-driven, not request-driven: you file the verb the consumer actually asked for, and higher-assurance verbs require an operator verification decision before fulfilment proceeds (DSAR → Verify or reject identity).
  • know — access requests. For California consumers you usually attach consumer_categories to scope the answer; the subdivision is in Section 4.
  • delete — erasure. Tracked as its own resource so you can audit and intervene before data is destroyed, with a signed proof-of-deletion certificate once it executes — the receipt a consumer or regulator holds as evidence the §1798.105 right was fulfilled (DSAR → Proof-of-deletion certificate).
  • correct — CPRA’s rectification right. Also the nearest verb for a restriction-style claim where accuracy is disputed — file the accuracy half as correct and narrow processing in parallel (see the worked pair on DSAR).
  • portability — machine-readable export. Lands as a signed, time-limited download link on the request row.
  • opt_out_sale — sale/share opt-out under §1798.120, including cross-context behavioural-advertising “sharing” added by the CPRA. Fulfilment flows into the same suppression layer every send reads (Opt-Out & Suppression Lists), so the opt-out is enforced before dispatch, not merely recorded.
  • limit_sensitive_pi — CPRA’s §1798.121 restriction on using sensitive PI beyond authorised purposes. File it to narrow processing in a lawful, tracked way; it is also the CCPA/CPRA analog you pair with a GDPR restriction claim.
  • non_discrimination — §1798.125 claims. Rare in practice, but filing them on the same pipeline keeps them against a 45-day clock with the rest.
A request filed under the wrong verb still burns the clock — the reclassification path is operator-side (applicable_jurisdiction and request_type can be corrected after intake), so reclassify early rather than letting a mis-filed know ride out as one.

​
Section 3 — California’s state-level gating in the posture

CCPA/CPRA is a US state law, not a federal one — and Orbit’s country map reads the US as one row while California rides as a state-level jurisdiction inside it. Two consequences to hold together:
  1. The country map stays country-shaped. Country rules and the country-rules console carry one US row per channel (iso: "US") — what the destination accepts, sender registration, opt-out text. Answering “what does California add?” is a posture question you answer here, on the state-jurisdiction surfaces below — the map deliberately does not fragment countries into states.
  2. State-level gating is handled on three surfaces, and none of them touches the DSAR lifecycle itself:
How that interacts with the DSAR lifecycle: the DSAR lifecycle is fully driven by the jurisdiction you file at intake. When a California consumer files — or you reclassify an incoming request — applicable_jurisdiction: "ccpa" or "cpra" starts the 45-day clock, and request_type picks from the CCPA-only verbs. The US-CA code on a record simply tells fulfilment and audit reads which rows fall under the California jurisdiction; it does not gate intake, verification, or the clock. Keep the two wires separate: state gating on send/recording surfaces, jurisdiction-at-intake on the DSAR pipeline, and nothing on either surface blocks the other.

​
Section 4 — The organisational subcategories the API accepts

For access requests (request_type: "know") you can attach consumer_categories — the CCPA §1798.100(b) notice-at-collection categories the consumer is asking about. The compliance API accepts GDPR and CCPA/CPRA classes together; this subdivision is the CCPA one. The full enum is defined on DSAR → Request types and the API reference; the values: identifiers, customer_records, protected_classifications, commercial, biometric, internet_activity, geolocation, sensory, professional, education, inferences, sensitive_pi. Scope the answer with the category list that matches what the notice-at-collection covers: an access request that asks about internet_activity and geolocation fulfils against those two categories, not against the whole enum. The list is also what your organisation’s own records (the privacy register activities and the evidence binder export) should mirror so the consumer-facing answer and the internal record agree.

​
Section 5 — Where this page sits in the posture group

This page sits in the Compliance nav group alongside the other per-jurisdiction posture guides — GDPR, TCPA, STIR/SHAKEN, and HIPAA — and the California wire it documents reads four sibling surfaces: the country rules map, the state calling windows intersection, the DSAR pipeline itself, and the consent records an opt-out lands on.