Two days ago, the Delete Act stopped being a registration statute.
Civil Code § 1798.99.86(c)(1) opens with a date that has now passed: "Beginning August 1, 2026, a data broker shall access the accessible deletion mechanism established pursuant to subdivision (a) at least once every 45 days." Subdivision (d) carries the same commencement date for the recurring re-deletion and no-new-sale duties.
That obligation is live. It is not a filing, and it does not close.
Most of the preparation work in this market has been aimed at a moment: the first pull from the Delete Request and Opt-Out Platform, the first batch of matches, the first purge. The statute is not built that way. Read § 1798.99.86(c) and (d) together and what you get is a standing control that has to fire on a maximum 45-day interval, cascade to every service provider and contractor, and keep firing against the same consumer indefinitely.
The distinction matters commercially. A one-time project produces a completion date. A recurring control produces a per-cycle evidence record, and under § 1798.99.82(d) the penalty is metered per request per day.
What changed on 1 August 2026, and why is DROP a recurring operational control rather than a registration formality?
The mechanism itself was the Agency's obligation, not yours. Section 1798.99.86(a) required the California Privacy Protection Agency to establish an accessible deletion mechanism by January 1, 2026, one that lets a consumer, "through a single verifiable consumer request," ask that every data broker holding personal information about them delete it, including information held by an "associated service provider or contractor."
Subdivision (b) sets what the mechanism must do. It must let registered data brokers determine whether an individual has submitted a verifiable deletion request, and it must not disclose any additional personal information when the broker accesses it, unless the title says otherwise. It must be free to consumers, available in any language spoken by a consumer whose information brokers have collected, usable by consumers with disabilities, open to authorized agents, and it must let the consumer check the status of their request.
Consumers also get control over the shape of the request. Under § 1798.99.86(a)(3) a consumer can selectively exclude specific data brokers, and under (a)(4) they can alter a previous request once at least 45 days have passed since their last one.
That is the design context for your side of the transaction. The Agency built a queue. As of 1 August 2026, you are required to go and read it, on a cadence, forever.
Two clocks now run in your environment, and conflating them is the first modelling error to avoid.
→ The access clock. Section 1798.99.86(c)(1) requires access to the accessible deletion mechanism "at least once every 45 days." This is a cadence obligation attached to the broker, independent of whether any request is waiting.
→ The processing clock. Section 1798.99.86(c)(1)(A) requires you, "within 45 days after receiving a request," to process all deletion requests and delete all personal information related to the consumers making them.
These are not the same 45 days. If you access on day 45 of the access cycle and a request landed in DROP on day 2, your processing deadline runs from receipt, not from your pull. A programme that pulls at the statutory maximum interval structurally compresses its own processing window. The prudent reading is that the access cadence sets a ceiling, and your operational cadence should sit meaningfully inside it.
Who counts as a data broker under Civil Code § 1798.99.80, and which entities are carved out of the regime?
Section 1798.99.80(c) defines a data broker as "a business that knowingly collects and sells to third parties the personal information of a consumer with whom the business does not have a direct relationship." The definitions in Section 1798.140 apply otherwise, per subdivision (a).
Three elements have to be present at once: knowing collection, sale to third parties, and the absence of a direct relationship with the consumer. Each is doing work. A business that collects without selling is outside the definition. So is one that sells but only about consumers it has a direct relationship with.
The carve-outs in § 1798.99.80(c) are the part that gets misread most often, because of four words: to the extent that.
→ An entity to the extent it is covered by the federal Fair Credit Reporting Act. → An entity to the extent it is covered by the Gramm-Leach-Bliley Act and its implementing regulations. → An entity to the extent it is covered by the Insurance Information and Privacy Protection Act. → An entity, or a business associate of a covered entity, to the extent their processing of personal information is exempt under Section 1798.146, with "business associate" and "covered entity" taking their Section 1798.146 meanings.
These are activity-scoped, not entity-scoped. A firm with an FCRA-regulated consumer reporting line and a separate marketing-data line does not exit the regime because of the first line. The exemption reaches as far as the covered processing reaches, and no further. The practical consequence is that your Delete Act scope determination is a data-flow question, not a corporate-entity question, and it needs to be re-run whenever a product line changes what it collects or who it sells to.
Section 1798.99.82(b)(2)(H) reinforces the point from the disclosure side. Registration requires you to state "whether and to what extent" you or any subsidiary is regulated by the FCRA, the GLBA, the IIPPA, the Confidentiality of Medical Information Act, or the HHS privacy, security and breach notification rules issued under HIPAA. The statute asks for extent, because extent is the operative concept.
Mapping that boundary once and leaving it is the failure mode. Privacy compliance as a maintained scope model rather than an annual memo is what keeps the "to the extent" line accurate as products move.
What does § 1798.99.86(c) actually require you to do every 45 days: access, process, and cascade to service providers?
Subdivision (c)(1) sets out four duties in one list. All four attach to the same recurring access.
Access. Reach the accessible deletion mechanism at least once every 45 days.
Process and delete. Under (c)(1)(A), within 45 days after receiving a request, process all deletion requests made pursuant to the section and delete all personal information related to the consumers making them, "consistent with the requirements of this section."
Cascade the deletion. Under (c)(1)(C), direct all service providers or contractors associated with the data broker to delete all personal information in their possession related to those consumers.
Cascade the fallback. Under (c)(1)(D), direct all service providers or contractors to process an unverifiable request as an opt-out of the sale or sharing of the consumer's personal information, as provided under Section 1798.120 and limited by Sections 1798.105, 1798.145 and 1798.146.
The verb in (C) and (D) is direct. The statute places an affirmative instruction duty on the broker, running to every associated service provider and contractor, on every cycle. It does not say "have a contract that requires." It says direct.
That is an evidence design decision, not a legal one. Directing a downstream processor on a 45-day cadence produces an artefact each time, or it produces nothing at all and you have no way to show the direction was given. If your service-provider instruction lives only in a master services agreement signed in 2024, you have a contractual term, not a record of a per-cycle direction.
Anyone who has run Article 17 erasure cascades under the GDPR will find the structure familiar, and that comparison is worth drawing carefully, because the California instrument differs in a way that changes the engineering. European erasure is request-triggered and terminates when the request is satisfied. The Delete Act duty under § 1798.99.86(d)(1) does not terminate.
What happens when a deletion request cannot be verified, and why does it become an opt-out instead?
Section 1798.99.86(c)(1)(B) removes the option of simply denying.
Where a data broker denies a consumer request to delete "because the request cannot be verified," the broker must process the request as an opt-out of the sale or sharing of the consumer's personal information, as provided for under Section 1798.120 and limited by Sections 1798.105, 1798.145 and 1798.146.
Read the trigger narrowly. It is specific to denial for non-verification. It is not a general fallback for every denial ground, and the statute distinguishes the grounds elsewhere: § 1798.99.85(b) requires you to report denials separately for requests that were not verifiable, requests not made by a consumer, requests calling for information exempt from deletion, and requests denied on other grounds.
So a failed verification is not a dead end in your workflow. It is a branch, and the branch has its own downstream leg under (c)(1)(D). Two operational implications follow.
First, your verification outcome has to be a recorded, reasoned state per request, not a silent drop. The metrics duty in § 1798.99.85(b)(1) will later ask you to count exactly these.
Second, an opt-out that originates from an unverifiable deletion request has to reach the same service providers and contractors that a successful deletion would have reached. The cascade is symmetrical.
Which personal information may you still lawfully retain under § 1798.99.86(c)(2), and what are you permitted to use it for?
The retention carve-outs are narrow and they come with a use restriction attached.
Under § 1798.99.86(c)(2), a data broker is not required to delete a consumer's personal information if either of the following applies: it is reasonably necessary for the broker to maintain the information to fulfil a purpose described in subdivision (d) of Section 1798.105, or the deletion is not required pursuant to Section 1798.145 or Section 1798.146.
Then (c)(3) closes the loop, and this is the sentence to put in front of your data science and marketing functions verbatim. Personal information described in paragraph (2) "shall only be used for the purposes described in paragraph (2) and shall not be used or disclosed for any other purpose, including, but not limited to, marketing purposes."
Retention under a carve-out is therefore a change of legal status for that data, not a continuation of the status quo. The record survives, and its permissible use collapses to the ground that justified keeping it. If a record is retained because retention is reasonably necessary for a Section 1798.105(d) purpose, that purpose is now the outer limit of what the record may do.
Systems rarely model this. A suppression flag that stops onward sale but leaves the record in the general-purpose store, queryable by any downstream job, does not implement (c)(3). What (c)(3) requires is purpose-bound retention: the surviving record carries its justification with it, and access is constrained by that justification.
How does the duty to stop selling or sharing new personal information under § 1798.99.86(d) change your ingestion pipeline, not just your deletion queue?
This is the subdivision that turns DROP from a deletion project into an architectural constraint.
Section 1798.99.86(d)(1): beginning August 1, 2026, after a consumer has submitted a deletion request and the broker has deleted the data, the broker "shall delete all personal information of the consumer at least once every 45 days pursuant to this section," unless the consumer requests otherwise or the deletion is not required under (c)(2).
Section 1798.99.86(d)(2): beginning August 1, 2026, after that same sequence, the broker "shall not sell or share new personal information of the consumer," unless the consumer requests otherwise or the selling or sharing is permitted under Section 1798.145 or 1798.146.
Both duties are now in force. Together they mean a deleted consumer is a persistent state in your environment, not a completed ticket.
Consider what (d)(1) implies for acquisition. You delete a consumer's record. Forty days later, a data supply partner delivers a file that contains that consumer again, matched on a different identifier. Nothing in your deletion queue fires, because no new DROP request arrived. But (d)(1) requires re-deletion at least once every 45 days, and (d)(2) independently prohibits selling or sharing that newly acquired information.
The control therefore has to sit at ingestion, not only at request handling. That means a durable suppression identity that survives the deletion of the underlying record, applied against inbound data before it is made available for sale or sharing. Retaining just enough to recognise a consumer you must not re-monetise is itself a retention decision, and it needs to be reasoned against (c)(2) and constrained by (c)(3) rather than assumed.
Subdivision (f)(1) permits the Agency to charge a data broker an access fee, not exceeding the reasonable costs of providing access, when the broker accesses the mechanism. Note that (f)(1) cross-refers to access "pursuant to subdivision (d)," while the access duty itself is stated in (c)(1). That internal cross-reference is worth watching in any implementing regulation the Agency adopts under § 1798.99.87(a). Fee regulations, per § 1798.99.87(b), are exempt from the Administrative Procedure Act, so they can move faster than the rest.
A duty that recurs every 45 days and binds your ingestion path is exactly the kind of obligation that decays quietly between annual reviews. Continuous compliance is the difference between a control that ran last quarter and a control you can show ran in every cycle since 1 August 2026.
What evidence do the § 1798.99.85 metrics, the § 1798.99.82 registration fields and the January 2028 independent audit demand, and what does getting it wrong cost per day?
Three separate evidence duties attach to the same underlying request log, on three different clocks.
The metrics duty. Under § 1798.99.85(a), on or before July 1 following each calendar year in which a business meets the data broker definition, the business must compile the number of requests under § 1798.99.86(c) and Sections 1798.105, 1798.110, 1798.115, 1798.120 and 1798.121 that it received, complied with in whole or in part, and denied during the previous calendar year. It must also compile the median and the mean number of days within which it substantively responded. Both sets go into the privacy policy on its website, accessible from a link in that policy.
Subdivision (b) then breaks the denials out into the four categories named above, and subdivision (c) requires that for each provision of Section 1798.145 or 1798.146 under which deletion was not required, the broker specify the number of requests where deletion was not required in whole or in part under that provision.
That last requirement is the one to design for now. It is a per-exemption-provision count. If your denial workflow records "exempt" as a single reason code, you cannot produce it retrospectively. Calendar year 2026 is the first year containing DROP requests, and five months of it remain.
The registration duty. Under § 1798.99.82(a), on or before January 31 following each year in which a business meets the definition, it must register with the CPPA. CPPA data broker registration under § 1798.99.82(b)(2) requires, among other fields, the metrics compiled under § 1798.99.85(a)(1) and (2), whether the broker collects the personal information of minors, whether it collects precise geolocation, whether it collects reproductive health care data, the "whether and to what extent" regulatory statement, and a link to a page detailing how consumers exercise their rights that "does not make use of any dark patterns."
Note the sequencing. The registration field at (b)(2)(B) calls for the § 1798.99.85 metrics, and registration falls on January 31 while the metrics compilation deadline is the following July 1. In practice the registration date pulls your compilation work forward, and a programme that plans to the July 1 date alone will be short.
The audit duty, which is not yet in force. Under § 1798.99.86(e)(1), beginning January 1, 2028, and every three years thereafter, a data broker must undergo a data broker independent third-party audit to determine compliance with the section. Under (e)(2), the broker must submit the resulting report and any related materials to the CPPA within five business days of a written request. Under (e)(3), it must maintain the report and materials for at least six years.
Registration catches up to the audit a year later. Under § 1798.99.82(b)(2)(F), beginning January 1, 2029, the registration must state whether the broker has undergone an audit as described in § 1798.99.86(e) and, if so, the most recent year in which it submitted the report and related materials.
Neither of those dates is live today. Both are already determinative, because a triennial independent audit conducted in 2028 will examine cycles that started on 1 August 2026. Five business days is not enough time to construct a record, only to retrieve one. And the six-year retention in (e)(3) outlasts the five-year limitation period in § 1798.99.89, under which no administrative action alleging a violation of the title may be commenced more than five years after the date the violation occurred.
The cost of getting it wrong. Section 1798.99.82(c) makes a broker that fails to register liable for an administrative fine of two hundred dollars for each day it fails to register, plus an amount equal to the fees due during that period, plus the Agency's investigation and administration expenses.
Section 1798.99.82(d) prices the deletion failure differently, and the difference is the whole point. A broker that fails to comply with § 1798.99.86 is liable for "an administrative fine of two hundred dollars ($200) for each deletion request for each day the data broker fails to delete information as required," plus the Agency's reasonable expenses.
Per request. Per day. The registration penalty scales with time. The deletion penalty scales with time multiplied by the size of your unprocessed queue, and a 45-day cadence failure across a queue of any commercial scale compounds in both dimensions at once.
Both streams are deposited into the Data Brokers' Registry Fund under § 1798.99.82(e), and the same fund receives registration fees and access fees under § 1798.99.81 and § 1798.99.86(f)(2). Enforcement here is designed to be self-funding.
What all three evidence duties share is a single source: a per-request, per-cycle record with a reasoned outcome, a timestamp, and a traceable exemption ground. Build that once and the metrics disclosure, the registration field and the 2028 audit are all queries against it. Audit readiness means the audit pack is a query, not a project.
The reason this works at all is determinism. Every obligation in the Aegis engine traces to a verbatim quote from the legal text, so the control you operate on 1 August 2026 and the evidence you produce on a five-business-day notice in 2028 are anchored to the same source Civil Code language, grounded in the statute rather than generated from a model's memory. A posture you can defend in front of a regulator, a board, or a plaintiff.
FAQ: California Delete Act DROP compliance
How often must a data broker check the DROP mechanism now that it is live?
At least once every 45 days. Section 1798.99.86(c)(1) has required access to the accessible deletion mechanism on that cadence since 1 August 2026. Separately, § 1798.99.86(c)(1)(A) requires deletion requests to be processed within 45 days after receipt, so the receipt clock and the access cadence run independently.
Does a data broker have to delete a consumer's information only once?
No. Under § 1798.99.86(d)(1), after a consumer has submitted a deletion request and the broker has deleted the data, the broker must delete all personal information of that consumer at least once every 45 days, unless the consumer requests otherwise or deletion is not required under § 1798.99.86(c)(2). Section 1798.99.86(d)(2) separately prohibits selling or sharing new personal information about that consumer.
What must a data broker do if it cannot verify a deletion request?
Under § 1798.99.86(c)(1)(B), where a broker denies a deletion request because the request cannot be verified, it must process the request as an opt-out of the sale or sharing of the consumer's personal information under Section 1798.120, limited by Sections 1798.105, 1798.145 and 1798.146. Under (c)(1)(D), the broker must also direct its service providers and contractors to process it the same way.
When does the independent third-party audit requirement start?
It has not started. Section 1798.99.86(e)(1) requires an audit by an independent third party beginning January 1, 2028, and every three years after that. The report and related materials must be submitted to the CPPA within five business days of a written request under (e)(2) and retained for at least six years under (e)(3). The related registration disclosure at § 1798.99.82(b)(2)(F) begins January 1, 2029.
Map your data-broker deletion duties to a standing, evidence-backed control set. See your DROP obligations traced to the source Civil Code text at aegis-grc.com, no call required.
