On 11 February 2026, the California Attorney General announced a $2.75 million civil penalty settlement with The Walt Disney Company over how its opt-out of sale and sharing worked. The state's allegation, in one line: a logged-in customer could click "opt out" and still be sold and shared on their other devices and services. Attorney General Rob Bonta put it in his own words in the announcement: "businesses can't force people to go device-by-device or service-by-service."
If your product has a web app, a mobile app and any ad-tech or analytics tag that sends data to third parties, this is an architecture problem more than a legal one. This is a builder's read of a public enforcement action and the regulation text, not legal advice. Counsel decides whether the rules cover you.
What did California say Disney got wrong?
The Attorney General's 11 February 2026 announcement describes three opt-out methods, each with a gap. These are the state's allegations in a settlement, not findings after a trial.
- The in-product toggles applied only to the one streaming service, and often only to the device in use. Sale or sharing from the customer's other devices and services on the same account continued.
- The webform stopped sharing only through Disney's own advertising platform. Sharing with third-party ad-tech companies whose code ran inside Disney's websites and apps continued. Many connected TV apps had no in-app opt-out at all and sent people to the webform.
- Global Privacy Control (GPC), the browser signal, was applied only to the device in use, even when the person was logged in.
The announcement says the investigation grew out of a January 2024 sweep of streaming services, and that Disney must now implement opt-out methods that fully stop its sale or sharing of consumers' personal information. The release does not give a case number or reporting terms in its text, so this post does not guess at either.
What does the regulation require for a browser signal?
Section 7025(c)(1) of the California Consumer Privacy Act (CCPA) regulations, effective 1 January 2026, says a business that receives a valid opt-out preference signal must treat it as an opt-out of sale and sharing "for that browser or device and any consumer profile associated with that browser or device, including pseudonymous profiles." Then comes the sentence that matters for a logged-in user: "If known, the business shall also treat the opt-out preference signal as a valid request to opt-out of sale/sharing for the consumer."
Read that as a rule about identity. If your system knows the browser belongs to account 4821, the signal is an account-level opt-out, not a cookie flag. The regulation's own example (section 7025(c)(7)(C)) goes one step further: a customer sends the signal while logged in, then later logs in on a different device without the signal. The business "shall not interpret the absence of the opt-out preference signal as consent to opt-in."
That last rule breaks a common implementation. Many consent systems store the choice client-side and re-evaluate it on every page load, so a missing signal quietly resets the state to "allowed."
What counts as a valid opt-out method?
Section 7026(a)(4) says a cookie banner or cookie control "is not by itself an acceptable method for submitting requests to opt-out of sale/sharing," because cookies concern collection, not sale or sharing. An online business must accept the preference signal plus at least one other method (section 7026(a)(1)). It cannot require an account to opt out (section 7026(c)).
The speed rules are in section 7026(f). A business must stop selling and sharing "as soon as feasibly possible, but no later than 15 business days" after the request. The regulation's example is blunt: a site using real-time bidding that can cut the flow instantly "shall not take 15 business days." It must also notify third parties that received the person's data after the request and before compliance, and tell them to forward the request on (section 7026(f)(2)). And it must give the consumer a way to confirm the request was processed, such as an "Opt-Out Request Honored" message and a visible toggle (section 7026(g)).
How do you build an opt-out that survives a second device?
Picture a 30-person SaaS company with a web app, an iOS app and a smart-TV app, plus an ad pixel and a data partner that receives a nightly export. The company's opt-out lives in a cookie. Here is what the Disney allegations suggest it has to change.
- 1.Store the choice at two levels. One record on the account (keyed to the user ID) and one on the device or browser (keyed to a device ID or cookie). Effective state is "opted out" if either says so.
- 2.Merge on login. When a device with an active signal authenticates, write the opt-out to the account. When an account that has opted out logs in on a new device, set the device record too. A missing signal never clears anything.
- 3.Put one gate in front of every outbound path. Browser tags, the iOS SDK, the TV app, server-side conversion APIs and the nightly partner export all call the same "may we share this person's data?" check. In the Disney allegations the gaps were the paths the toggle did not reach.
- 4.Make the webform reach third parties. Stopping your own ad platform is not the same as stopping the code your partners run inside your pages. Inventory every tag and SDK, and name which ones the form switches off.
- 5.Queue the downstream notice. For batch exports, record which partners received data between the request and the cutoff, and send the section 7026(f)(2) notice to them.
- 6.Show the state. The confirmation in section 7026(g) is a UI requirement with a data source behind it, so read the same record the gate reads.
In the earlier Honda and Todd Snyder enforcement, the failures were buttons that looked right and did nothing. The Disney allegations are subtler: the button worked, for a smaller set of places than the customer assumed. The PlayOn order asked for a quarterly tracker scan, which is the cheapest way to find the paths your gate does not cover.
When is this the wrong build?
If you do not sell or share personal information, most of this does not apply. Section 7025(c)(1) says treating the signal as an opt-out "is not required for a business that does not sell or share personal information." Many B2B products send data only to service providers under a written contract and run no cross-context advertising. For them the right first step is a data-flow inventory that proves it, then a contract check using the vendor terms guide, not a new consent system.
Two more cases where a custom build is overkill: a company with one web property and one tag manager, where a well-configured consent platform covers every path; and a team whose real exposure is automated decisions rather than advertising, where the work belongs in a different part of the program.
How should you scope the work?
Start with the question the Disney case turns on: for one logged-in user on three devices, which of your outbound data flows still run after they opt out on one? Trace it with a test account. You will find the gaps faster than any policy review will.
If you want a second pair of hands, our ADMT compliance engineering team builds this kind of notice, opt-out and logging work. You can also run the ADMT checker to see which of your decisions fall under the automated-decisionmaking rules, or talk to us with a list of your devices, SDKs and partner exports.
