A CCPA opt-out form should help a consumer stop the sale or sharing of their personal information. It should collect only what the business needs to act on that choice, without turning the request into an identity-verification exercise.
That distinction is central to the Honda and Ford enforcement cases. It is also easy to lose when a business uses the same form, validation rules and email workflow for every privacy right.
There is no universal two-field form or maximum field count that guarantees compliance. Start with the information and systems involved, then justify each input. A short form can still block a valid request; a longer form needs a clear reason for every required field.
This guide covers sale and sharing opt-outs under the CCPA, as amended by the CPRA. It focuses on implementation. For the case history, read our Honda, Ford and Disney review.
Identify the record without verifying the person
The California Attorney General's CCPA guidance, section B, distinguishes asking enough to identify the relevant information from requiring proof of identity. A business may need an identifier to locate a record, but an opt-out must not depend on creating an account or completing identity verification.
Consider an email address used to find a customer's purchase record. That is a different function from sending a link and refusing to act until the customer proves control of the inbox. The first may be necessary for the particular request. The second makes verification a prerequisite.
For implementation, document two things beside each required field: which record it locates and why information already available cannot do the job. Changing a label from “verification” to “identification” does not change what the workflow actually does.
What Honda and Ford actually found
Honda: excessive collection and the wrong request workflow
Honda used a common form for several privacy rights, requiring at least eight fields even for opt-out and limitation requests. The order says Honda generally needed only two data points to identify a consumer in its database. That was a finding about Honda's systems, not a two-field standard for every business.
The order also addressed direct confirmation of agent authority and unequal cookie choices. Its $632,500 penalty covered multiple findings, rather than simply the number of form fields. See the Honda order, paragraphs 30–52 and 75–77.
Ford: requests expired behind email confirmation
Ford's privacy form had multiple fields. After submission, consumers had to follow an email verification step before Ford would process their opt-outs. Requests expired when consumers did not complete that step, despite Ford having enough information to act.
The $375,703 settlement addressed that barrier and continued sale or sharing after requests. It also required a tracking-technology audit on Ford.com. This was not a finding that every email field is prohibited. See the Ford order, paragraphs 22–43 and 48–52.
Design consequence: route sale/sharing opt-outs separately from the verification workflow used for requests to know, delete or correct information. Check the backend queue and expiry rules, not just the visible form.
Choose fields from the data flow
The CPPA's data minimisation advisory, scenario one, explains why the necessary information depends on what the business sells or shares. A browser advertising opt-out may need no new information. Applying a request to a separate purchase-history record may require an identifier. Unrelated identity documents add collection without helping fulfil the request.
Use the following as a proposed design review, rather than a prescribed form template:
| Situation | Suggested starting point | What to check |
|---|---|---|
| Browser activity only | A direct opt-out control using the browser context already available | Whether any new visible field serves a necessary purpose |
| Consumer already recognised | Reuse the existing association with their profile or account | Whether the choice reaches the relevant connected systems |
| Separate customer records | Ask for the minimum identifier needed to locate those records | Whether the same request can be handled without collecting it again |
| Request through an agent | A distinct agent route with provision for signed permission | Whether it avoids sending the consumer through identity verification |
Do not add a mandatory California-residency checkbox as a default design rule. Assess jurisdictional information only where it is needed. In particular, processing a qualifying GPC signal must not depend on a follow-up form.
Avoid asking consumers to understand your architecture. A selector between “browser”, “CRM” and “CDP” makes internal system boundaries their problem. Explain any genuine scope limitation in ordinary language and process the choice wherever the available information permits.
Handle authorised agents correctly
For sale/sharing opt-outs, 11 CCR § 7026(j) allows the business to require the consumer's signed written permission from the agent. An agent's statement that permission exists is not automatically sufficient. The signed-permission requirement does not apply to requests made through an opt-out preference signal.
Honda's order separately explains why requiring the consumer to confirm the agent's authority directly was improper for these requests. Do not copy the access, deletion or correction agent workflow into the opt-out path.
Sources: the current regulations, section 7026(j) and Honda order, paragraphs 45–52.
In practice, distinguish the agent's contact details from the consumer identifier used to locate records. Restrict access to permission documents and avoid collecting unrelated identity evidence.
Make receipt and completion distinct
Section 7026(f)–(g) requires action as soon as feasibly possible, within 15 business days, and a way to confirm processing. Third parties receiving sale/shared data between receipt and compliance must be notified and directed to comply and forward the request. The deadline does not justify delaying an immediate technical change. See the current regulations.
Design the interface around the actual state of the request. These are illustrative messages to adapt to the implementation:
- Received: “We have received your request. You do not need to verify your email.”
- Partially applied: “Your choice is active for this browser. We are applying it to the associated customer records.”
- Completed: “Your opt-out of sale and sharing has been applied.”
Only show the second or third message when the systems support it. A request identifier or status page can help consumers follow progress without revealing personal records.
A confirmation email can report an outcome. It should not contain a required confirmation action that holds up processing. Do not collect an email address solely because the existing support-ticket system expects one.
Connect the form to the systems that disclose data
A proposed implementation sequence is:
- Record the request time and available identifiers.
- Apply the choice to relevant browser controls immediately where supported.
- Update associated customer preferences and affected server-side transfers.
- Track completion or failure for each affected integration.
- Show an accurate status and route failures to an owner for resolution.
Include advertising exports, audience uploads and mobile integrations in the review where relevant. A successful CMP update does not establish that every other system received the choice.
Assess continuing transfers by their purpose, recipient role and contractual restrictions. The CCPA's sale and sharing definitions in section 1798.140 do not make every analytics request a sale or sharing. Conversely, a first-party endpoint can forward information to an advertising recipient. Inspect the complete transfer, including what happens on the server.
For testing, retain the request time, affected systems, observed outcome and configuration version. Avoid copying unnecessary personal information into diagnostic logs.
Test the complete request journey
The CPPA's dark-patterns advisory announcement emphasises clear, balanced choices and the effect of an interface on consumers. Use that principle when reviewing errors, accessibility and unnecessary steps.
Run these engineering checks with test data:
- Submit while signed out. Check that the available opt-out is not blocked by a login screen.
- Submit while signed in. Compare the preference across associated services.
- Leave every confirmation email unopened. Check whether processing still completes.
- Submit through the agent route with signed permission. Check that the consumer is not sent a verification challenge.
- Send GPC in a fresh browser profile. Check the displayed status and resulting data transfers independently of the form.
- Simulate an integration failure. Check that the interface does not claim full completion and that the failure remains visible to an owner.
- Use a keyboard and screen reader. Check labels, errors, focus movement and access to the submit control.
There is no general conclusion from these cases that every CAPTCHA is prohibited. Review any anti-abuse control for necessity, accessibility and whether it blocks legitimate requests. Server-side controls also need testing; rate limiting is not automatically harmless.
FAQ
Can we use one portal for all privacy rights?
Yes, but the portal needs distinct processing paths. The information and verification appropriate for access or deletion should not become mandatory for sale/sharing opt-outs.
Does a one-click form let us remove the opt-out link?
No. The exception in § 7025(f)–(g) concerns frictionless processing of opt-out signals, prescribed privacy-policy disclosures and full effectuation of the request. A short form alone does not establish eligibility. Online collection also requires signal handling plus an interactive method under § 7026(a)(1). See the current regulations.
What if the identifier does not match a record?
Treat that as a matching problem, not a reason to default to identity verification. Investigate whether the request can be fulfilled using the available context. Do not expose whether another person's account exists or claim a record was updated when it was not.
Can a shared cookie preference cover every system?
Only if the affected systems actually use it. Check the integration with account records, server-side processing and other relevant destinations. Cookie storage alone does not demonstrate that an opt-out has been carried through.
Further reading
Continue with our CCPA banner requirements guide, Global Privacy Control guide, or CCPA audit framework.
For help reviewing an existing implementation, request a free consent audit or discuss your CCPA and GPC setup.
