CCPA enforcement lessons for enterprise consent

In February 2026, California's Attorney General settled with a major global entertainment company for $2.75 million — the largest CCPA enforcement action to date — over failures in its consumer opt-out infrastructure. The fine revolved around the company’s consent architecture only working per-device and per-service, while the company's ad tech worked across accounts, devices, and services simultaneously.

In the enforcement decision (https://oag.ca.gov/news/press-releases/california-wont-let-it-go-attorney-general-bonta-announces-275-million), AG Rob Bonta noted, “A consumer’s opt-out right applies wherever and however a business sells data — businesses can’t force people to go device-by-device or service-by-service.”

The decision asserts that If a business can associate consumer identities across devices and services to serve targeted advertising, it must apply the same capability to honor opt-out requests no matter where they occur. Claiming technical or vendor limitations as a defense doesn't hold when the technical capability demonstrably exists in your marketing stack and the wider market.

The Settlement in Technical Terms

California's Department of Justice launched its investigation in January 2024 as part of a sweep of streaming services for potential CCPA violations. What it found was revelatory even if incidental: the company’s privacy controls were architecturally disconnected from its data infrastructure.

The company offered consumers three ways to opt out of the sale or sharing of their personal data, but all three ways failed. This wasn’t due to missing intent, but presumably because of missing engineering. The company’s setup captured consent signals at the surface level, but never fully propagated those choices downstream to the systems that actually moved the data.

This is the statement every IT and engineering leader at a data-driven enterprise needs to read carefully. It establishes a technical parity standard: your privacy infrastructure must be at least as sophisticated as your marketing infrastructure.

But that is the neat takeaway from CalPrivacy’s press release. What is more pressing on IT teams is what happens before the press release goes public.

That process starts with a formal investigative letter requesting documented proof of how opt-out requests are enforced across all systems and services. That lands on IT because they're typically the only ones who can actually answer it in detail. That means reconstructing an enforcement audit trail across consent signals, identity logic, pipeline behavior, and third-party tags for a specific user across a specific time window, a task that pulls engineers off roadmap work for weeks.

For IT, the real problem isn't just the $2.75M fine, but potential months of unplanned work that precede a settlement.

Three Architecture Failures — and What They Mean

Each opt-out channel failed for a distinct technical reason. Taken together, they paint a clear picture of what the AG expects from a compliant consent architecture.

Failure 1: Toggle Architecture: Session-Scoped, Not Account-Scoped

In-app and in-browser opt-out toggles applied the user's request to the specific service and device where the toggle was activated. A user opting out on one streaming app and device had no effect on other streaming services and authenticated devices connected to the account.

That means the toggle was functionally a client-side event, signaling intent but not triggering backend propagation across the account's identity graph. For a company whose ad targeting operates across that same account and device graph, this discrepancy is legally untenable.

Technical root cause: Consent signals were scoped to the session or application instance. No mechanism existed to associate that signal with the authenticated account identity and propagate it system-wide.

Failure 2: Webform Suppression: Platform-Level, Not Data-Level

The company's webform opt-out suppressed data sharing through the company's own advertising platform. However, it did not stop data sharing with third-party ad tech vendors whose tracking code was embedded in the company's websites and apps. The opt-out managed the company's own ad delivery mechanism, but did not control the underlying data flows that fed external systems.

Additionally, many connected TV apps had no in-app opt-out mechanism at all. Users were simply redirected to a webform, meaning there was functionally no way to stop data sharing from within a connected TV experience.

Technical root cause: The consent system operated at the ad platform layer, not the data layer. Third-party tags and pixels continued firing regardless of stated preference because enforcement was not implemented at the system level where data actually moved.

Failure 3: GPC Signal: Device-Scoped Despite Authenticated Session

When a user sent a Global Privacy Control signal — a browser-level opt-out mechanism — the company applied that signal only to the specific device generating it, even when the user was authenticated in their account on that device. A logged-in user's GPC signal did not propagate to other devices associated with the same account.

This is the clearest example of the AG's core argument. A GPC signal from an authenticated user provides a resolvable identity. The company possessed the technical capability to associate that identity across its systems precisely because it did exactly that for advertising. Choosing not to apply that same capability to privacy compliance is what drove enforcement.

Technical root cause: GPC detection was implemented at the device/browser layer without triggering identity-resolved propagation to the account-level consent record.

The Identity Resolution Imperative

The thread connecting all three failure modes is identity resolution, or rather, the selective application of it. Identity resolution is the capability that allows a company to recognize that the same person is interacting across different devices, browsers, apps, and services, and to associate those interactions with a unified profile.

Every enterprise running a digital advertising operation has solved this problem. For example, retail media networks use identity resolution to connect in-store purchase behavior with streaming app views and mobile browsing sessions, building unified profiles that allow brands to target the right person at the right moment across every touchpoint. Cross-device attribution, frequency capping, lookalike modeling — all of it depends on linking disparate signals to a common identity.

The February CCPA settlement is far from the only enforcement action codifying what the new technical standard must be. Several 2025 cases explicitly called out similar issues around user choices propagating downstream, and CalPrivacy followed up this $2.75M fine with two additional enforcement actions in early March, including another 7-figure fine to a youth sports media company over failure to honor opt-out preference signals and to provide users its own native method to opt-out.

All of this translates to the fact that opt-out compliance is not simple, even if it appears to be.

The GPC Signal: A Backend Data Problem, Not a Frontend UX Problem

The Global Privacy Control deserves specific attention because it introduces a unique architectural challenge that this settlement and others make concrete.

GPC is a browser-level signal. It fires on every page load for users who have enabled it. For authenticated users — users who are logged into an account — the $2.75M enforcement action establishes that the GPC signal must be associated with that account identity and propagated system-wide, not limited to the current browsing session on the current device.

For unauthenticated users, a related compliance question emerges: if a site detects a GPC signal from an anonymous user who has an account but isn't logged in, what is the obligation?

The AG's reasoning implies that the site should, at minimum, inform the user that they can log in to fully effectuate their opt-out preference — connecting their anonymous signal to their resolvable identity so their opt-out preference can be enforced across all associated devices and services.

But handling GPC at this level requires instrumentation that goes beyond browser-side JavaScript. It requires the ability to detect the signal, resolve it against an identity graph, update a centralized preference record, and propagate that update to downstream systems in real time. This is a backend data engineering problem with a frontend trigger.

Why “No Code" Consent Tools Create Backend Liability

There is an active debate in the privacy vendor market about engineering requirements. Some vendors position themselves as solutions that legal and privacy teams can deploy without meaningful engineering involvement.

While that argument may be appealing on the surface, promising faster time to value, less friction with engineering backlogs, and privacy as a self-service capability, the CA AG's enforcement action is, effectively, a detailed rebuttal of that model.

A consent tool that a privacy team can deploy without engineering involvement is, almost by definition, a tool that operates at the interface layer through banners, toggles, webforms, preference centers.

It may be able to capture consent signals, but what it cannot do without deep integration into your data infrastructure, is enforce those signals where data actually moves: in your data pipelines, your event streams, your third-party tag management, your data warehouse, your advertising platforms, and your identity graph.

This distinction isn't about vendor sophistication in isolation either, but rather where in your architecture the consent logic is enforced. Enforcement at the interface is legally insufficient if your data continues flowing through backend systems, regardless of the signal captured at the surface.

Enforcement at the data-level is the only surefire way to be confident in your compliance posture, and that requires a level of system integration that is antithetical to the “no engineering” pitch some vendors make.

This is not an argument against involving privacy teams in vendor selection. It is an argument that consent infrastructure must be treated as a core engineering concern, embedded in the development cycle alongside your marketing and data infrastructure, not bolted on afterward. Only then can privacy teams lend their experience and expertise to lead privacy programs that deliver results and keep businesses moving forward confidently.