A deletion request is a clock, not a ticket
A California consumer’s deletion request does not enter a support queue. It starts a statutory operation with a fixed deadline, a verification standard, a downstream notification chain, and a penalty schedule for getting any of them wrong. The right itself sits in Cal. Civ. Code § 1798.105(a): a consumer may request that a business delete personal information the business collected from the consumer. The statute grants the right and lists the exceptions; the California Privacy Protection Agency (CPPA) regulations set the timeline and verification tiers, and the two documents must be read together.
This playbook is the California counterpart to the European process. Where the GDPR gives a one-month response window under Article 12, California gives 45 calendar days under CPPA regulation § 7021, with a different verification ladder and exception list. Operators who run both regimes from one queue will miss both deadlines unless the queues are kept distinct.
> [!KEY TAKEAWAY]
> California deletion work is deadline work. Confirm receipt within 10 business days, answer within 45 calendar days, and never let verification time eat the clock — the 45 days run from receipt, not from successful verification.
Who this playbook is for, and who should stop here
This playbook is for operators, privacy leads, and counsel at businesses that meet the CCPA definition of a “business” under § 1798.140(d): a for-profit entity doing business in California that determines the purposes and means of processing and satisfies at least one of three thresholds — annual gross revenues above $25,000,000 in the preceding calendar year, annually buying, selling, or sharing the personal information of 100,000 or more consumers or households, or deriving 50 percent or more of annual revenues from selling or sharing personal information. It also serves operators below those thresholds who answer requests voluntarily, because a voluntary process that misses its own published timeline creates the same trust damage as a statutory miss.
Do not use this playbook as a substitute for counsel if any of these apply: the requester is in litigation and the data is subject to a litigation hold; the data includes a minor’s personal information, which sits in the higher penalty tier; the request arrives through an authorized agent whose authority is disputed; or the business has received an enforcement inquiry about the same queue. In each case the deadline still runs, but the deletion decision needs a lawyer before the response goes out.
The clock: 10 business days, 45 calendar days, 90 at most
CPPA regulation § 7021 sets three dates every deletion queue must produce on demand:
$
ext{Confirmation deadline} = ext{Receipt date} + 10 ext{ business days}
$
$
ext{Response deadline} = ext{Receipt date} + 45 ext{ calendar days}
$
$
ext{Extended deadline} = ext{Receipt date} + 90 ext{ calendar days (45 + 45, with notice and explanation)}
$
The regulation is explicit that the 45-day period begins on the day the business receives the request, regardless of verification time. That sentence is the most expensive misunderstanding in California privacy operations: a team that waits three weeks to verify identity and then starts a 45-day countdown has already consumed nearly half its window.
A worked example makes the discipline concrete. A request received on a Monday, Day 0, must be confirmed by the second Friday after receipt (10 business days, skipping weekends), answered by Day 45, and, if an extension is genuinely needed, the consumer must be told before Day 45 why more time is required. The extension is not a grace period a team grants itself; it is a notified, explained decision. “Volume” alone is weak. A search spanning archived systems, an unanswered service-provider chain, or a partial-exception analysis are reasons with facts attached.
> [!WARNING]
> A deletion denied without a detailed explanation is a separate failure from a deletion missed. Under § 7022(f), a business that denies a request in whole or in part must give a detailed explanation of the basis for the denial, delete the information that is not subject to the exception, and use retained information for no purpose other than the exception. A one-line “we cannot comply” satisfies none of the three duties.
Verification: two ladders, chosen by sensitivity
Verification under the CPPA regulations is not a single password check. Section 7060 sets the general rules, § 7061 covers password-protected accounts, and § 7062 covers everyone else — and most deletion requests arrive from people without an account, or who cannot access one.
For non-accountholders, § 7062(d) ties the verification standard to the sensitivity of the information and the risk of harm from unauthorized deletion. Deleting family photographs may require a reasonably high degree of certainty, while deleting browsing history may require only a reasonable degree. The regulation’s illustrations make the calibration plain: a retailer can verify a purchaser by asking for recently purchased items or the dollar amount of the most recent purchase, matching at least two data points for a reasonable degree of certainty, while specific pieces of information may require at least three matching data points plus a signed declaration under penalty of perjury.
The operator’s judgment must be made in good faith and documented per request, not per queue. A blanket “three data points for everything” policy over-verifies low-risk requests; a blanket “one data point” policy under-verifies high-risk deletions and invites an unauthorized deletion, which is worse than a slow one. Where no reasonable verification method exists, § 7062(g) requires the business to say so and explain why, rather than silently dropping the request.
Account holders are simpler: § 7061 lets the business verify through the password-protected account itself, provided it follows § 7060. Authorized agents add a third track under § 7063: verify the agent’s authority as well as the consumer’s identity.
What “delete” actually means, system by system
Section 1798.105(c) requires the business to delete the consumer’s information from its records, notify service providers and contractors to delete it from theirs, and notify all third parties to whom it sold or shared the information unless that proves impossible or involves disproportionate effort. Regulation § 7022(b) defines compliance as one of three outcomes per system: permanently erasing the information from existing systems except archived or backup systems, deidentifying it, or aggregating it.
That three-way definition is the practical heart of the playbook. Erasure is the default for production databases, CRM records, marketing lists, and support tickets. Deidentification fits analytics stores where the record’s value is statistical and the link to the person can be severed. Aggregation fits reporting tables where only the group figure matters. What does not count is suppression: flagging a record “do not contact” while leaving the personal information queryable in the CRM is retention with a label, not deletion.
The downstream chain is where most queues break. Section 7022(b)(2) requires notifying service providers and contractors, and § 7022(b)(3) requires notifying third parties who received the information by sale or sharing. Each notified party has its own duties under § 7022(c): erase, deidentify, or aggregate, delete the non-excepted portion, and pass the notice further down its own chain. A deletion that stops at the business’s own database is incomplete by the regulation’s own terms, and the evidence of completion is the notification log, not the ticket status.
Archived and backup systems get a narrow carve-out under § 7022(d): compliance may be delayed until the system is restored or next accessed or used for a sale, disclosure, or commercial purpose. The carve-out is a delay, not an exemption, and it must be tracked per system so the deletion fires when the backup is next touched.
The exception list: what may stay, and what it may never be used for
Section 1798.105(d) lists eight purposes for which a business, service provider, or contractor is not required to comply with a deletion request, where retention is reasonably necessary for the purpose:
| Retained purpose | What it covers | Authority |
| :--- | :--- | :--- |
| Complete the transaction or contract | Fulfilling the purchase, warranty, recall, or service the consumer requested, or performing the contract | § 1798.105(d)(1) |
| Security and integrity | Uses reasonably necessary and proportionate to ensure security and integrity | § 1798.105(d)(2) |
| Debugging | Identifying and repairing errors that impair existing intended functionality | § 1798.105(d)(3) |
| Free speech and legal rights | Exercising free speech, another consumer’s free speech, or another right provided by law | § 1798.105(d)(4) |
| CalECPA compliance | Complying with the California Electronic Communications Privacy Act | § 1798.105(d)(5) |
| Research | Public or peer-reviewed scientific, historical, or statistical research that deletion would render impossible or seriously impair, with informed consent | § 1798.105(d)(6) |
| Solely internal uses | Uses reasonably aligned with consumer expectations from the relationship and the context of collection | § 1798.105(d)(7) |
| Legal obligation | Complying with a legal obligation | § 1798.105(d)(8) |
Two disciplines govern every exception claim. First, the exception is per-record, not per-consumer: a consumer with an open order and a three-year-old marketing profile gets the order data retained and the marketing profile deleted, with the split explained. Second, retained data is frozen to its exception purpose. A fraud-prevention record retained under the security purpose may not be fed back into marketing segmentation. Section 7022(f)(3) states the freeze plainly, and violating it converts a lawful retention into an unlawful use.
The queue math: what a manual process actually costs
Deletion work is priced in hours per request, dominated by search and notification rather than by the delete statement itself. The following model is illustrative, built from the steps in this playbook rather than from any vendor benchmark, and it should be replaced with a team’s own timed sample before budgeting:
$
ext{Monthly queue cost} = ext{Requests per month} imes ext{Hours per request} imes ext{Fully loaded hourly rate}
$
$
ext{Illustrative cost} = 40 imes 3.5 imes $45 = $6{,}300 ext{ per month}
$
At 40 requests a month and 3.5 hours each, the queue consumes 140 staff hours, or roughly 0.8 of a full-time employee, before any tooling. The lever that moves that number is not faster deletion; it is a data map that answers “where does this consumer’s data live” in minutes instead of days, plus a notification template set that covers service providers, contractors, and third parties without drafting each notice from scratch. To model the staffing cost against a team’s own figures, run the hours math through the break-even calculator before committing headcount or buying a privacy platform.
The penalty arithmetic runs the other way and is the reason the queue deserves that headcount. Under § 1798.199.90, a violation carries a civil penalty of not more than $2,500 per violation, or $7,500 per intentional violation and per violation involving a minor’s personal information, as adjusted. Applied illustratively to a queue that denied 40 requests without the detailed explanation § 7022(f) requires:
$
ext{Illustrative exposure} = 40 imes $2{,}500 = $100{,}000
$
That figure is arithmetic, not a prediction: penalties are assessed per violation in an enforcement action, not auto-generated per ticket, and the regulator weighs intent, cooperation, and remediation. Its purpose is scale-setting. A $6,300-a-month queue that prevents a six-figure exposure discussion is cheap insurance, and a team that frames it that way gets its data map funded.
Execution checklist
> [!FOUNDER]
> “A deletion queue is a trust ledger. Every request you answer on time with a real explanation buys the next hundred customers’ confidence; every request you lose in a spreadsheet costs it. Build the log first and the automation second, because automation over a broken log only loses requests faster.”
> — Enow A. Jovial, Founder & Chief Executive Officer
Operator boundaries: when not to delete on the standard path
Do not run the standard deletion path when a litigation hold covers the data, when the request is part of an enforcement proceeding where disclosure strategy is counsel’s call, or when the requester’s identity cannot be verified to the standard the data’s sensitivity requires. In each case, pause and escalate, but keep the clock visible: an escalated request still has a Day 45, and “with counsel” is not an extension reason unless the consumer has been notified with the explanation § 7021 requires.
Do not delete on a single identifier match for high-sensitivity data, and do not refuse a request solely because the consumer used an unfamiliar channel. The companion submission rules require treating a request made outside the designated manner as if it had been submitted correctly, or telling the consumer how to fix it. The channel is a routing detail. The deadline is the duty.
> [!TIP]
> Publish the deletion method in the privacy policy and keep it to two methods consumers actually use — a web form and an email address — plus the phone route for in-person consumers. Every additional channel is another intake log feeding the same Day 0 clock, and a channel nobody monitors is a deadline missed in silence.
Related reading: the GDPR data subject access request playbook for the European one-month counterpart, and the self-hosted analytics guide for PostHog, Plausible, and Umami under GDPR for the analytics side of the data map. To model the staffing cost of the queue before it spikes, run the hours math through the break-even calculator.