The California Privacy Protection Agency — now operating publicly as CalPrivacy — announced two data broker enforcement decisions in the space of three days in August 2026. Taken individually, neither fine is large. Taken together, and read carefully, they establish a legal theory that reaches a great deal further than the data broker registry.

  • 11 August 2026 — LocateSmarter LLC, an Iowa-based broker, was ordered to pay $116,490. This was CalPrivacy’s first enforcement action against a data broker under both the CCPA and the Delete Act.
  • 13 August 2026 — Cybba, Inc., a Boston-based broker, was ordered to pay $52,400 for failing to register with the Data Broker Registry by the 2025 deadline.

Michael Macko, CalPrivacy’s Head of Enforcement, framed the cadence directly: the Agency has been bringing “a steady drumbeat of enforcement actions under both the Delete Act and the CCPA,” and he does not “see the enforcement activity slowing down anytime soon.”

Both matters were handled by attorneys Neelofer Shaikh and Gary Lee as part of CalPrivacy’s Data Broker Enforcement Strike Force.

The LocateSmarter theory: verification is collection

The registration failure in LocateSmarter is unremarkable. What matters is the second violation.

LocateSmarter required consumers to provide partial Social Security numbers before it would allow them to exercise their opt-out rights. CalPrivacy held that requiring that data violated the CCPA’s data minimisation requirement.

Sit with the structure of that finding, because it generalises well beyond data brokers.

The CCPA requires that a business’s collection, use, retention and sharing of personal information be reasonably necessary and proportionate to achieve the purpose for which it was collected. Businesses have generally applied that test to their product data flows — what they collect to deliver the service, what they retain, what they share with partners.

CalPrivacy has now applied it to the rights-handling process itself. The purpose being served is “verify that the person submitting this opt-out request is the consumer they claim to be.” The question is whether demanding a partial SSN is reasonably necessary and proportionate to that purpose. CalPrivacy’s answer was no.

This is not a novel reading of the statute. The CCPA regulations have always required businesses to avoid collecting new categories of personal information for verification where a less intrusive method is available, and to use information the business already holds where possible. What is new is a regulator putting a six-figure number behind it.

Why this is a trap that catches well-intentioned organisations

There is a genuine tension here, and it catches organisations acting in good faith.

Under-verify, and you disclose or delete personal information at the request of an impostor — which is itself a security incident and a CCPA violation. Regulators and plaintiffs’ counsel have both pursued that failure mode.

Over-verify, and you have collected sensitive identifiers you did not previously hold, from consumers whose only goal was to have less of their data in your systems. You have also, in practice, suppressed the exercise of the right — which is the outcome that draws regulatory attention.

The resolution is not a fixed rule but a proportionality analysis, documented:

  • Match the verification burden to the sensitivity and irreversibility of the request. An opt-out of sale is low-risk and reversible; it warrants light verification. A deletion request destroying records is high-risk and irreversible; it warrants more.
  • Verify against data you already hold. If you have an email address and a transaction history, verify against those. Do not ask for a new identifier.
  • Never demand a category of personal information you do not already hold, absent a specific, documented reason why nothing else will do.
  • Where you must collect verification data, process and discard. The CCPA regulations require that information collected for verification not be used for any other purpose and be deleted as soon as practicable.

LocateSmarter, notably, did hold Social Security numbers — its product included SSNs, dates of birth, driver’s licence information, employment data, and bankruptcy and litigation records. So the “we already hold it” defence was theoretically available. It did not save the company, because the relevant question was not whether LocateSmarter possessed SSNs but whether requiring a consumer to transmit one as the price of exercising a statutory right was proportionate. It was not.

The size of the fine relative to the number of complainants

Tom Kemp, CalPrivacy’s executive director, made a point about the LocateSmarter penalty that compliance teams should take seriously:

“The Board’s decision imposes a substantial fine even though a mere handful of consumers submitted requests to opt out, underscoring the need for businesses to take privacy rights seriously.”

This is a deliberate signal. A common internal argument against investing in rights-handling infrastructure is volume-based: we get four requests a month, this does not justify the engineering. CalPrivacy has now stated, on the record, that it will impose substantial penalties for defective rights handling irrespective of how few consumers were affected.

The theory is straightforward and hard to argue with: a barrier that suppresses the exercise of a right will, by construction, produce a low volume of requests. Low request volume is evidence of the violation, not a mitigating factor.

Cybba and the DROP obligation

The Cybba decision is a cleaner registration case — failure to register with the Data Broker Registry by the 2025 deadline — but the order terms are where the forward-looking obligation sits. Cybba must:

  • pay the $52,400 fine,
  • post metrics about privacy rights on its website,
  • access the Delete Request and Opt-Out Platform (DROP), and
  • process future deletion requests through DROP.

That last term connects to a deadline that took effect twelve days before the decision. Under the Delete Act, data brokers must process deletion requests submitted through DROP beginning 1 August 2026, with defined response timelines. DROP is California’s centralised deletion mechanism: a consumer submits a single request, and every registered broker is obliged to check the platform and delete accordingly.

We covered the mechanics of DROP in detail in our California Delete Act DROP platform compliance guide. The short version for brokers: DROP shifts deletion from a consumer-initiated, per-broker process to a pull obligation. You must periodically access the platform, retrieve the deletion list, match it against your records, and delete. Failing to check DROP is a violation even if no consumer ever contacted you directly.

This is a sustained programme, not a burst

CalPrivacy’s data broker enforcement has been running for over a year. We tracked the first enforcement surge — eight fines — in December 2025. The Agency has since built a dedicated Data Broker Enforcement Strike Force with named attorneys and a visible cadence.

The pattern across the actions is consistent:

  1. Registration failures are the entry point. They are trivially provable — either you are on the registry by the deadline or you are not. No investigation is required, and the fine is calculated on a per-day basis.
  2. Registration failures then open the door to substantive review. Once CalPrivacy is examining a broker, it examines the broker’s rights-handling, disclosures, and data practices. LocateSmarter’s SSN requirement almost certainly surfaced this way.
  3. Order terms impose ongoing obligations — DROP access, published metrics, compliance monitoring — that outlast the fine.

The lesson for any organisation that meets the data broker definition is that the registration obligation is not a minor administrative item to be handled when convenient. It is the thread the regulator pulls.

What “data broker” actually captures

A recurring failure mode is organisations concluding they are not data brokers because they do not think of themselves that way. California 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.

That definition catches more than the obvious people-search companies:

  • Adtech and measurement firms. Cybba’s own description — selling geolocation data, internet activity data, and inferences to facilitate targeted advertising, identifying repeat customers and purchase-likely consumers from behavioural signals — is a fairly ordinary description of a mid-market adtech business.
  • Lead generation businesses across insurance, mortgage, education and home services.
  • Identity, fraud and verification vendors that build products from data sourced outside a direct consumer relationship.
  • B2B contact data providers — the personal information of business contacts is still personal information under the CCPA.
  • Analytics and enrichment providers that append third-party attributes to client records.

If your revenue depends on data about people who have never heard of you, run the analysis properly, with counsel, and document the conclusion either way.

A checklist

If you may be a data broker

  • Run the definitional analysis against the CCPA and Delete Act text; document the conclusion and the reasoning.
  • If in scope, register with the Data Broker Registry. Late registration is better than none; the fine accrues per day.
  • Implement DROP access and a scheduled process to retrieve and action deletion requests. This obligation has been live since 1 August 2026.
  • Publish the required privacy rights metrics.

Everyone handling CCPA rights requests

  • Audit your verification flows. For each request type, list every data element you demand from the consumer.
  • For each element, answer in writing: why is this necessary, what less intrusive alternative did we consider, and why was it rejected? That document is your defence.
  • Remove any requirement for SSN, government ID, or other sensitive identifiers from low-risk request types, particularly opt-outs. If you require them for high-risk deletion requests, document the proportionality reasoning.
  • Verify against data you already hold wherever possible.
  • Confirm verification data is used only for verification and deleted promptly. Check this in the code, not in the policy.
  • Measure your request completion rate. A high abandonment rate between request initiation and completion is the metric that indicates a suppressive verification flow — the exact pattern CalPrivacy penalised. Instrument it and review it.

Governance

  • Do not let low request volume justify low investment. CalPrivacy has explicitly rejected that argument.
  • Treat rights-handling as a monitored control with an accountable owner, not as a support ticket queue.
  • Extend the same proportionality review to CPRA-adjacent regimes — Connecticut, Colorado, Texas, Oregon and others impose materially similar verification constraints.

The through-line

The most durable takeaway from these two decisions is not the dollar amounts. It is that the process by which you honour a privacy right is itself a regulated data processing activity, subject to the same minimisation and proportionality tests as everything else you do.

Most privacy programmes were built to answer “are we collecting too much in the product?” Rather fewer were built to answer “are we collecting too much in the consent banner, the DSAR intake form, the identity verification step, and the preference centre?” CalPrivacy has now made clear that it will ask the second question, that it will ask it of organisations with a handful of complainants, and that the answer will carry a six-figure price.

This article is provided for informational purposes only and does not constitute legal advice. Organisations should consult qualified counsel regarding their specific obligations under the CCPA, the California Delete Act, and applicable state privacy law.