Honda, Ford and Disney: CCPA lessons for cookie banners and opt-outs

A cookie banner can record a choice while the business continues to sell or share the consumer's information. A privacy form can accept a request while an email confirmation prevents it from being processed. Testing the interface alone will miss both failures.

The Honda, Disney and Ford cases illustrate these problems at different points in the opt-out process. Announced between March 2025 and March 2026, they resulted in $3,758,203 in combined monetary penalties. The useful lesson is in the conduct and remedies, rather than the size of the penalties.

This article examines those three settlements and proposes implementation checks based on them. Their orders bind the settling businesses; they do not create an identical technical specification for every organisation. The governing requirements remain the CCPA, as amended by the CPRA, and its implementing regulations.

The three cases at a glance

Sources: the official Honda announcement, Disney announcement and Ford announcement.

These are California cases. They are useful design references for a wider US implementation, but the scope, exemptions and opt-out requirements of other states need separate assessment.

Honda: make privacy choices equally easy

Honda's cookie tool required consumers to switch off advertising cookies and then confirm their choices. A returning consumer could re-enable cookies with a single “Allow All” action. The order required a “Reject All” control to address that asymmetry.

The Honda stipulated order, paragraphs 30–69 and 77, also describes:

• A shared rights form requiring at least eight fields, including for requests that did not require identity verification.
• Consumers being required to confirm directly that they had authorised an agent to submit an opt-out or limitation request. The order distinguishes that step from asking the agent for signed permission.
• Missing required agreements with advertising technology recipients.

Implementation lesson: review the complete path through the preference centre, including a return visit after opting out. Separate opt-out handling from access, deletion and correction verification. Review recipient contracts alongside the interface.

Honda is often summarised as an “Accept All versus Preferences” case. That is an example discussed in the order, but the documented interaction was specifically a two-step opt-out versus a one-step return to allowing cookies. Preserve that distinction when using the case in a design review.

Disney: make the choice reach the whole account

The Attorney General's announcement describes three gaps. Toggles often affected only one service or device. The webform stopped sharing through Disney's own advertising platform but left third-party advertising transfers running. GPC was limited to the sending device even when the consumer was logged in. Many connected TV apps directed users to that incomplete webform.

The Disney judgment, paragraphs 26–34, requires account-wide application across associated streaming services for logged-in consumers. For consumers who remain unidentified, the choice still applies to the browser, app or device and associated profiles. It also requires accessible opt-out controls within the services and a way to confirm processing.

Implementation lesson: use a test account to trace a choice from the web interface into another associated app or device, then into advertising destinations. A stored preference is only the starting point.

Disney also agreed to a monitoring programme and annual reporting over specified three-year periods. Those are Disney's settlement obligations, not an automatic reporting requirement for every business.

Ford: do not hold opt-outs for email verification

Ford's form collected a request, then instructed the consumer to confirm their email and identity through an emailed link. Unconfirmed requests expired. Ford subsequently processed them during the investigation.

The distinction matters: the finding was about making verification a condition of processing, not a blanket ban on email fields. Information needed to locate the relevant record may be appropriate; proving control of an inbox must not become an opt-out gate.

The Ford stipulated order, paragraphs 22–43 and 50–52, required simpler processing and an audit of tracking technologies on Ford.com for opt-out signal compliance. It did not impose an audit of every SDK across all Ford properties.

Implementation lesson: test the form without opening any confirmation email. Follow the request into the workflow or queue and verify whether the opt-out is applied. A successful submission screen does not prove successful processing.

What the rules mean for implementation

The CCPA regulations effective 1 January 2026 provide the relevant requirements:

• Section 7004: privacy choices must be understandable, symmetrical and easy to execute. “Accept All” paired only with “Preferences” is an explicit example of unequal choice.
• Section 7025(c)(1)–(2): a qualifying opt-out signal covers the browser or device and associated profiles, including pseudonymous profiles. Where the consumer is known, it also applies to that consumer. Additional identifying information cannot be required to process the signal.
• Section 7025(c)(6): display whether the signal has been processed. Detection alone is insufficient.
• Section 7026(c)–(d): do not require account creation or identity verification for sale/sharing opt-outs. Collect only information necessary to complete the request.
• Section 7026(f): stop sale or sharing as soon as feasibly possible, within a maximum of 15 business days. This is not permission to delay a change that can happen immediately.

An opt-out is not a ban on every network request

The CCPA statute, section 1798.140, defines sale and sharing by the disclosure, purpose and recipient relationship. Sharing includes cross-context behavioural advertising, even without payment. Qualifying service-provider or contractor arrangements can fall outside sale or sharing, subject to the statutory conditions and actual processing.

A request to an analytics endpoint therefore needs investigation before it can be classified as a breach of an opt-out. Inspect the payload, identifiers, destination, use restrictions and actual use. A vendor label or contract alone does not establish that the processing qualifies for an exception.

The same assessment applies to server-side transfers. Moving a request away from the browser does not change its purpose or legal classification.

A practical review of your implementation

The following is a proposed engineering review based on these cases. It is not a regulator-issued checklist.

1. Map the journeys. Record the steps for opting out, changing an existing choice and opting back in. Include keyboard navigation and mobile layouts. Save screenshots of each state.
2. Inspect every required field. Document which system needs it and why. Test whether the request can be completed using identifiers already available. Avoid arbitrary rules such as “three fields is acceptable”.
3. Trace a manual request. Submit through a test account, leave confirmation emails unopened, and inspect the resulting preference and workflow status.
4. Trace GPC separately. Start with a fresh browser profile that sends GPC. Compare the visible status, stored preference and outgoing requests. Repeat while logged in and after moving to an associated app.
5. Inspect data leaving the system. Compare browser requests, server events and advertising exports before and after the choice. Record the purpose and recipient of any continuing transfer for review.
6. Test persistence. Reload, revisit a subdomain and sign in on another device. Check for stale caches or default settings that overwrite the preference.
7. Assign ownership. Keep the configuration version, observations, expected behaviour and responsible owner with each test result. Repeat affected checks when tags, vendors or account integrations change.

For a site without accounts, browser storage may be part of the implementation. For an account-based service, a shared preference service may be appropriate. Neither architecture should depend on collecting more identity data just to honour a browser-level signal.

FAQ

Does every California website need an Accept All and Reject All banner?

No. The CCPA is not a general requirement to obtain consent before every cookie. Applicability, sale or sharing, and the rights engaged determine the controls needed. When offering acceptance and refusal choices, apply the symmetry requirement described above. See our CCPA banner requirements guide for the broader framework.

Can an opt-out form ask for an email address?

It may be necessary to locate a record for a particular request. Ford demonstrates why collecting an identifier and requiring the consumer to verify it are different steps. Assess necessity for each field and avoid a verification gate.

Does every opt-out have to reach every device?

The relevant distinction is what the business already associates with the consumer. Disney's judgment addresses account-linked services and devices, while preserving browser, app or device-level handling for unidentified consumers. Do not turn account-wide handling into a requirement that everyone must log in.

Do these settlements prove that a CMP is insufficient?

A CMP can manage the interface and signals. Its effectiveness depends on how it is configured and connected to tags, account preferences and other data transfers. Test that integration rather than treating installation as the final check.

Further reading

Continue with opt-out form design, our Global Privacy Control guide, or the CCPA audit framework.

For help reviewing your implementation, request a free consent audit or discuss your CCPA and GPC setup.