Summarize this article with
In October 2025, the California AG settled with Sling TV for $530,000. The case exposed four technical compliance failures common across enterprise privacy programs: (1) identity parity gaps for logged-out users, (2) disconnected opt-out architecture, (3) contextual consent gaps, and (4) non-web surface compliance gaps. This guide explains each failure and what privacy leaders should do about it.
In October 2025, the California Attorney General settled with Sling TV and Dish Media Sales for $530,000. It was one of the more significant CCPA enforcement actions of the year, and news coverage reflected that.
Like the Disney settlement that followed a few months later, most of that coverage was legal analysis of the enforcement. What got less attention was the underlying technical infrastructure. How should privacy, consent, and permissioning tech be architected to conform with CA AG expectations?
The gap between law and infrastructure
The Sling settlement is unique; not simply because of the specificity of the alleged CCPA violations, but because said violations require sophisticated technology infrastructure to resolve. The CCPA enforcers' expectations are genuinely difficult to meet. Most privacy tech on the market isn't designed to reach the scope of what this settlement suggests is required.
This guide is an attempt to translate the Sling settlement's requirements into practical terms. Not to assign blame, and not to oversimplify. These are hard problems, and privacy teams deserve a clear-eyed read of what the settlement actually requires at a systems level, and what closing those gaps looks like in practice.
The four critical, technical learnings from the Sling TV settlement are:
- The identity obligation follows capability, not authentication state
- Frictionless opt-out is a clear legal requirement, not just a design principle
- Consent isn't a single account-level setting — it has to respond to profile and content
- Non-browser surfaces need their own opt-out mechanism (in this case, CTV)
Together, we'll walk through these four technical learnings, map them to the specific regulatory language, and give you a clear framework for auditing your own program against each one.
1. The identity obligation follows capability, not authentication state
One of the core enforcement principles in this settlement is symmetry. If a brand is using knowledge of consumer identity for targeted advertising, it must also use that knowledge to suppress data sharing when a consumer opts out.
This means that the scope of your opt-out obligation is defined by the scope of your data monetization. More sophisticated data monetization = more sophisticated consent infrastructure expectations.
The settlement extends this further than most privacy professionals have probably assumed. In paragraph 25(b) of the settlement, we read:
"DEFENDANTS shall treat the CONSUMER's opt-out choice as a request to opt out of SALE or SHARING for that browser or device and any consumer profile that DEFENDANTS associate with that browser or device, including pseudonymous profiles, in the context of SELLING or SHARING their PERSONAL INFORMATION or CROSS CONTEXT BEHAVIORAL ADVERTISING."
The operative phrase is "any consumer profile that DEFENDANTS associate with that browser or device." The opt-out obligation doesn't attach only when a user is logged in. It extends to pseudonymous profiles associated with a device for advertising purposes, regardless of whether the consumer is currently authenticated. If the system can link a device to a profile for targeting, it must link that device to the same profile for opt-out enforcement. Note: this is the same principle California regulators applied in the Disney settlement a few months later.
The instinctive response from many companies will be: "We didn't build an identity graph. We're not in scope." That reasoning is understandable, but the settlement doesn't actually support it. What it says is that if identity resolution is being used in connection with your advertising, the opt-out obligation attaches. It doesn't draw a line between capabilities you built and capabilities you simply benefit from.
Most companies running programmatic advertising are benefiting from cross-device identity resolution right now, not because they built anything themselves, but because Google, Meta, The Trade Desk, and most major ad platforms provide it natively. Whether a company that benefits from a third-party platform's identity resolution is therefore obligated to honor opt-outs across those same identifiers is a question the settlement leaves genuinely open. The CA AG's logic strongly implies yes, but that ambiguity is real and worth watching.
What to do: Are you using ad platforms that perform cross-device identity resolution on your behalf? Do you know which ones? If yes, audit whether your consent infrastructure can honor opt-outs with the same scope and fidelity that those platforms use to target. Map the resolution points in your advertising stack where anonymous or device-level identifiers get linked to known or pseudonymous profiles. Those points define where your identity obligation extends, and they are the right place to start.
2. Frictionless opt-out is a clear legal requirement, not just a design principle
The settlement dedicates several paragraphs to specific prohibited UX behaviors. This converts what used to be a design principle into an explicit legal surface, and it's specific enough to audit against.
The baseline for logged-in users is established in settlement paragraph 25(a):
"Where a CONSUMER is logged-in to their SLINGTV account, DEFENDANTS shall not require the CONSUMER to fill out a webform with identification information (e.g., name, address, phone number, email address). Instead, DEFENDANTS shall provide the CONSUMER with a toggle or other opt-out method that is easy to execute, requires minimal steps, and does not require the CONSUMER to provide additional information..."
If you know who someone is, you cannot make them prove it again to exercise a privacy right. That's the rule.
The settlement gets more specific about what the AG considers prohibited friction. Bundling other privacy choices — cookie preferences, email marketing toggles, Nielsen-style vendor controls — in a way that implies those choices constitute or must accompany a CCPA opt-out is prohibited. So is requiring consumers to scroll through text or find unlabeled menu symbols to locate the opt-out. So are confirmation screens designed to dissuade. Paragraph 30 prohibits misdirection explicitly: you cannot direct a consumer trying to opt out via the Sling app to website cookie choices. That is an exact description of what happens when a CTV opt-out flow sends users to a webform on a different domain with no technical connection to the app's data sharing behavior, and the AG has now called it out by name.
As for connected TV (CTV): a native in-app opt-out is required on every platform and device. If a toggle isn't commercially feasible, a QR code is acceptable, but it must capture login state and must either immediately effectuate the opt-out account-wide or route to a compliant opt-out notice — either way, without forcing a second device, re-login, or webform. The phrase "not requiring use of a second device" is now in a consent decree. (More on CTV in section #4 below.)
What to do: Audit your opt-out flow against this settlement's prohibited behaviors specifically. Does your consent layer know whether the user is logged in before deciding what experience to serve? If it presents the same flow to everyone regardless of authentication state, that's a capability gap, not just a design gap. Your consent infrastructure needs to be connected to your identity infrastructure dynamically. Also check whether your opt-out entry points are bundled with cookie preferences or other choices in a way that could obscure the CCPA opt-out path. The AG's list of prohibited behaviors is specific enough to use as a checklist.
3. Consent isn't a single account-level setting — it has to respond to profile and content
Most consent architectures and tools are organized around a moment: a banner appears, a user clicks, a preference is recorded. The Sling settlement keeps pointing to something different — a consent layer that is aware of context and adjusts its behavior based on signals it's receiving from the product. This is the part of the settlement with the broadest implications, and the part that's hardest to satisfy with conventional privacy tooling.
Three distinct requirements in the settlement all point to this need for contextual consent:
- Authentication context. Covered above: the system has to know the user is logged in and respond accordingly. A static banner doesn't know this.
- Profile context. Paragraph 32 requires Sling to allow consumers to create kids profiles that default off the sale and sharing of personal information and cross-context behavioral advertising. The consent state for a kids profile isn't a user preference — it's a function of the profile type itself, and it overrides normal defaults. The consent layer has to be connected to product state.
- Content context. Paragraphs 33 through 36 require Sling to default off behavioral advertising on any channel designated as "made for children or minors." Paragraph 35 states:
"For channels designated as MADE FOR CHILDREN OR MINORS, DEFENDANTS shall not make available to advertising partners the display of advertising that is based on or inferred from PERSONAL INFORMATION related to the CONSUMER or household."
What the consumer is watching changes the rules that apply to that session. It doesn't matter what their account-level settings say. If the channel is made for children, behavioral advertising is off. The consent state is a function of content context.
A company could implement all three of these requirements without touching their consent management platform. Hardcoding rules in the ad server, building one-off product logic, managing channel designations manually, etc. Some will. But that approach produces exactly the kind of fragmented, unauditable compliance infrastructure that gets companies into enforcement actions in the first place.
The more important takeaway is this: the CA AG clearly understands consent as something that varies based on who the user is, what they're doing, and what they're interacting with. Most privacy programs were not built with that understanding. A consent management system that can only record a preference and fire a tag is not equipped to satisfy what this settlement describes. What's required is closer to a rules-based decisioning layer — one that takes in context signals and produces the correct consent behavior dynamically.
What to do: Map every system that currently has a say in a consent decision — your CMP, your ad server, your profile/identity service, and whatever holds content or channel metadata — and check whether they actually talk to each other at decision time. Does your ad server know, at the moment it decides whether to serve a targeted ad, which profile is active and how that piece of content is classified? If that information lives in a separate system the ad call never queries, that's the exact gap this settlement targets. Start by inventorying every place a "kids" or minor-status flag exists in your product — profile creation, parental controls, content/channel metadata — and confirm each one actually suppresses targeting at the ad decision, not just in a settings screen a user can toggle. If satisfying this today means writing separate logic for each product surface rather than applying one rule your consent layer enforces everywhere, that's the sign you're treating consent as a UI feature instead of as infrastructure.
4. Non-browser surfaces need their own opt-out mechanism (in this case, CTV)
Cookie-based consent tools have nothing to attach to once a consumer leaves the browser, and Connected TV is where that gap is most visible. Complying with a cookie consent choice is not the same thing as honoring a CCPA opt-out — they're legally distinct obligations. On a website, you can at least pretend they're the same thing. On a Roku or a Fire Stick, you can't: there's no browser, no cookie, and no banner to display.
The settlement is direct about what's required. Paragraph 26 states that for every platform and device used to access the Sling app, a native in-app opt-out mechanism is required:
"For each platform or device used to access the SLINGTV app, DEFENDANTS shall implement an in-app, easy-to-use opt-out method with minimal steps such as a simple toggle, not requiring use of a second device."
The only alternative to a native toggle that the settlement permits is a QR code — and even that comes with conditions: it must capture the consumer's login state, and it must either immediately effectuate the opt-out account-wide or route the consumer to a compliant opt-out notice, without requiring them to log in again or fill out a webform. A destination that fails to meet that bar, like a cookie preference center that only touches one browser and does nothing for the app, isn't an acceptable substitute. The opt-out mechanism has to live on, or lead directly to, the surface where the data sharing is happening.
This matters beyond streaming because the device identifier question applies anywhere a company has a non-browser digital surface. A CTV device has its own advertising ID — a Roku advertising ID, an Amazon Fire device ID, ACR signals — and those identifiers are being used for targeting. Under the symmetry principle in section one, that means they are in scope for opt-out. Not via a cookie. Via whatever technical mechanism reaches that device's advertising ID and suppresses it in the ad stack.
Companies that have built their entire privacy program around a cookie consent platform have, in practice, built a program that covers one surface and leaves everything else unaddressed. That was always technically true. CTV enforcement makes it legally undeniable. The data processing happening on a connected TV is subject to the same opt-out requirements as anything on a website — it just requires completely different technical infrastructure to honor.
What to do: List every surface where your product shares data for advertising and isn't a browser: CTV apps, mobile apps, kiosks, connected devices. For each one, check whether opting out actually suppresses the device identifier (RIDA, AFAI, whatever that platform uses) at the ad call itself, not just in a settings screen. If the only opt-out path for that surface routes back to a website or requires switching devices, that's the exact gap Sling was written to close.
Beyond the fine – three years of reporting to the AG
Sling pays $530,000, split into two installments. That number is what gets reported, but it's not the part of this settlement that matters most operationally.
Paragraphs 38 and 39 require Sling to implement and maintain two separate compliance monitoring programs, one covering the opt-out provisions and one covering the children and minors provisions, for three years from the judgment. Each program has to produce an annual report to the California Attorney General's Office documenting that it's actually working.
Those reports are confidential and exempt from public records laws, which suggests the AG expects real operational detail in them, not a polished summary written for public consumption.
What this adds up to is a shift in what compliance actually requires: proving, on an annual basis for three years, that a program continues to function, rather than simply fixing the specific issue that triggered the complaint. That's a different obligation than most privacy programs have had to meet before.
Takeaways for your program: five questions to ask
None of what's enforced in the Sling settlement is specific to streaming. The identity parity principle, the enumerated UX requirements, the contextual consent rules, the CTV opt-out gap, the ongoing oversight model: all five apply to any company running targeted advertising against a device or a profile. This is the CA AG's read on what CCPA already required. Sling just got caught first. The standards will travel.
Five honest questions for your own program:
- Does your opt-out obligation extend to pseudonymous profiles tied to a device, not just authenticated sessions?
- Does your consent infrastructure know who it's talking to before it decides what experience to serve?
- Are there contexts in your product (content types, profile modes, user segments) where the consent state should differ from the default? Is that logic actually built, or does it just live in a policy doc?
- Do you have non-browser surfaces (CTV apps, mobile apps, in-store kiosks) where data sharing happens with no native opt-out mechanism?
- Could you hand a regulator evidence your compliance program works, or just a document that says it does?
With every order, we learn more about what regulators expect. Sling is no exception, and I would encourage every privacy program leader to study this order as an example of what their program should require.






