California's privacy regulator fined an Iowa data broker in August 2026 over a web form with three fields: full name, the last four digits of a Social Security number, and a mailing address. The form was the company's way to opt out of the sale of personal information, and the California Privacy Protection Agency (CPPA, which now brands itself CalPrivacy) found it asked for more than the law allows. The Board's own findings say only "a mere handful" of California's nearly 40 million consumers ever used it. Nobody was hurt by a leak. The form itself was the violation.
That is the part worth reading if you build the request intake for a product with California users. The order is public, it is short, and paragraph 43 is a remedy written as a list of requirements. This post reads it that way. It is a builder's read, not legal advice: counsel decides what applies to you.
What did CalPrivacy actually find?
The case is In the Matter of LocateSmarter, LLC, Case No. ENF26-05-D-LO. The CPPA Board adopted the stipulated final order on 10 August 2026, and CalPrivacy announced it on 11 August 2026. LocateSmarter is a data broker in Cedar Falls, Iowa that sells names, dates of birth, Social Security numbers, addresses and similar records to its clients through batch files, an API and a search platform.
The order bundles two separate violations, and the money splits the same way:
| Violation | Law | Amount in the order |
|---|---|---|
| Registered late as a data broker (deadline 31 January 2026 for 2025 activity) | Delete Act, Civil Code 1798.99.82 | $30,600 fine, plus the $6,000 annual registration fee |
| Opt-out form required a partial SSN and a mailing address | CCPA, Civil Code 1798.100(c); regulations 7002(d) and 7026(d) | $79,890 fine |
Add the three figures and you get the $116,490 CalPrivacy quoted in its announcement. The CCPA half is the $79,890, and it is the half that applies to anyone, not just data brokers.
What can an opt-out form legally ask for?
Less than most teams assume. The regulations, as the order recites them, say a business may not require a verifiable consumer request to opt out of sale or sharing (section 7026(d)). At most it may ask for information necessary to complete the request, and the same section says that "to the extent that the business can comply with a request to opt-out of sale/sharing without additional information, it shall do so."
The order's reasoning for why is plain: a stranger opting you out of a sale does you little harm, so there is nothing to verify against. Delete, know and correct requests are different. A wrong answer there can expose someone, and the order confirms a business may require verification for those.
Then comes the part that catches teams who think they are fine because they never called it "verification." Section 1798.100(c) limits collection to what is "reasonably necessary and proportionate," and paragraph 23 of the order says that applies to any collection, including collection to process consumer requests. Section 7002(d) weighs the minimum information needed, the possible harm to consumers, and any safeguards. A Social Security number scored badly on all three. The Board also noted (paragraph 28) that LocateSmarter held other, less sensitive data points it could have used instead.
Because the Board treated the form's design as the harm. Paragraph 29 says requiring an SSN "could intimidate consumers from exercising their privacy rights," and paragraph 30 draws the inference from the numbers: a handful of requests from nearly 40 million people is what a form that intimidates looks like. The company did not need to have mishandled any single request.
For an engineering team that changes the risk model. You cannot reason "no complaints, so no exposure." The unit under review is the screen. If someone at CalPrivacy can open your privacy page and read the fields, the evidence is already public.
A worked example: auditing one request form
Picture a 30-person HR-tech company with one shared "Privacy request" page. It has a dropdown (delete, know, correct, opt out), then required fields for full name, email, date of birth, and the last four digits of an employee ID, because that is what the support team wanted when the page was built for deletion requests. The same form, unchanged, receives the opt-outs.
Run the audit one request type at a time:
| Request type | Verification allowed? | What the form can require |
|---|---|---|
| Opt out of sale or sharing | No (section 7026(d)) | Only what is needed to act on the request, often an email or a browser signal |
| Delete, know, correct | Yes (order paragraph 18) | Enough to match your own records, still bounded by minimization |
| Opt out of ADMT, from 1 January 2027 | No (sections 7221(f) and 7060(b)) | Same shape as the first row |
That company has the LocateSmarter defect. The date of birth and ID digits are fine as a way to match a deletion request to a record, but they are not fine as required fields on an opt-out. The fix is not a new vendor. It is conditional fields: the form branches on request type, and the opt-out branch asks for the least that finds the person.
What the remedy reads like as a spec
Paragraph 43 of the order requires LocateSmarter to change its intake in four ways, and paragraph 44 gives it 60 days. As a checklist:
- 1.Methods that are easy, take minimal steps, and do not require more information than necessary.
- 2.No verifiable consumer request for an opt-out.
- 3.No portion of a Social Security number, ever, for an opt-out.
- 4.Honor each opt-out within the time the CCPA requires.
Two more paragraphs are easy to skip. Paragraph 45 requires updated training for everyone who handles CCPA requests, and paragraph 39 requires the privacy policy to publish request metrics: how many requests came in, how many were completed or denied, and how long the response took. A request log that can produce those numbers is the cheapest piece of this to build early.
If you also have an ADMT opt-out coming on 1 January 2027, build it once. The section 7221 handler shares the no-verification rule and adds a 15 business day clock. The failure pattern is the same one in the PlayOn order and the Honda and Todd Snyder orders: intake that quietly asks for more than the right requires.
What if you sell or license data, or buy it from a broker?
The Delete Act half of the order matters if any part of your product collects personal information and sells it outside a direct relationship with the person. Paragraph 10 is the test the Board applied. Whether you meet it is counsel's call, and tenant and employment screening vendors should ask the question rather than assume. If you do, the order also requires access to the CPPA's Delete Request and Opt-out Platform (DROP) to process deletion requests (paragraph 40). CalPrivacy said on 25 August 2026 that brokers had to begin processing DROP requests by 1 August 2026, that 654 brokers were in the system, and that about a quarter had reported processing requests.
When you do not need outside help
If your opt-out form is a name and an email, or it is a single link that honors a browser opt-out signal, you are done. Delete the extra fields, keep a dated screenshot, and move on. Nobody needs to be hired for that.
Help starts to make sense when intake is spread across a consent tool, a support desk and three vendors, and nobody can say which system holds the field that asks for too much. That is the build behind the ADMT readiness work. You can also run the free ADMT checker first to see whether the 1 January 2027 rules reach you. If you want a second pair of eyes on a request flow, send us the scope.
Sources
- California Privacy Protection Agency: Order of Decision and Stipulated Final Order, In the Matter of LocateSmarter, LLC, Case No. ENF26-05-D-LO (adopted 10 August 2026)
- CalPrivacy: first action against a data broker under both the CCPA and the Delete Act (11 August 2026)
- CalPrivacy: half a million Californians have signed up for DROP (25 August 2026)
