For years, companies have treated privacy mainly as a legal and policy issue. Legal teams write notices, privacy teams establish requirements, and consent management platforms ask visitors whether they accept cookies. Marketing, engineering and product teams then implement those requirements.
The problem is that legal controls policies, but code controls execution. A notice can describe what should happen. A consent banner can record what a visitor wants. Neither necessarily controls which technologies load, what they collect or where the data goes.
Outside the Traditional Perimeter
Websites and web applications rely heavily on third-party scripts, APIs, SDKs and client-side code. Much of what happens in a visitor’s browser is powered by advertising platforms, analytics providers, session replay tools, chat applications and payment providers.
Those third parties often bring their own partners, which may bring still more partners. The result is a daisy chain of tracking scripts that extends far beyond the vendors a company intentionally selected.
A company might install one advertising technology. That provider connects to bidding platforms and additional networks. Those networks use pixels, APIs and SDKs, triggering identity synchronization across still more platforms. In one example from our research, a single chain involved approximately 1,800 third parties.
This is where enormous amounts of data are transferred, shared, leaked and stolen, yet it remains one of the least visible and least controlled parts of most companies’ technology environments.
An example of this daisy chain:
Policy and Reality Often Diverge
Most companies assume their policies reflect reality. Their notice explains what’s collected and whether personal data is sold or shared. Their consent manager offers visitors a choice.
In more than 80% of the websites Lokker has scanned, what actually happens differs materially from what the company’s policies state or what its teams expect.
That doesn’t usually mean the company is intentionally disregarding its obligations. More often, it simply can’t see the complete chain of activity occurring in the browser. The tools make compliance sound easy, but getting it right while preserving revenue is far more complicated than advertised.
Even without internal changes, a provider may alter its script, introduce dependencies or fail to honor a consent signal. These changes can create data flows nobody approved, expected or knew existed.
An Inherited Architecture Problem
It’s tempting to frame this as corporate carelessness. That misses the larger issue.
Modern websites and digital advertising systems were built around frictionless data collection and sharing. Companies were rewarded for adding analytics, targeting, personalization and measurement.
Now they’re being told that practices considered routine for years may violate privacy laws, wiretapping laws, consumer protection laws or contractual commitments.
The architecture didn’t disappear when legal expectations changed.
Businesses must comply with new rules while still generating leads, measuring campaigns and supporting digital revenue. Telling them to “stop all tracking” isn’t realistic. They need a way to comply without dismantling the business models that keep them operating.
Consent Isn’t Enforcement
Consent management platforms present choices, maintain preference records and communicate consent signals. But recording a visitor’s preference isn’t the same as enforcing it.
A consent manager doesn’t guarantee that every tracker waits for consent, every downstream vendor interprets the signal correctly or an approved technology won’t load an unapproved dependency. It also doesn’t necessarily control what data appears in URLs, request headers, payloads, form fields or API calls.
The front-end code and tag manager determine what loads. The browser determines what gets transmitted.
The banner is the interface. The code is the control plane.
Where Privacy Controls Belong
Everyone owns one part of the problem, but nobody owns the complete data flow.
Businesses need findings distilled into concrete actions: Which technology creates the risk? What data does it collect? Who initiated it? Does it operate before consent or after an opt-out? What will break if it’s removed?
The practical answer is to place visibility and enforcement directly in the browser, where technologies load and data leaves.
This requires the privacy equivalent of a client-side web application firewall. It should identify downstream parties, reveal initiator chains and data transmissions, and provide granular controls based on consent, geography, page and data type.
That’s the layer where policies become executable.
Turning Visibility Into Action
We identify what loads, who initiated it, what information is transmitted and whether the website’s behavior matches its policies and consent requirements. We then turn that visibility into succinct, concrete remediation and enforcement actions.
The objective isn’t to eliminate every analytics, advertising or customer engagement technology. It’s to give businesses control over which technologies may operate, under what circumstances and with what data.
Companies shouldn’t have to choose between compliance and revenue. But they need more than policies, contracts and consent banners.
Legal establishes the rules. Privacy defines the requirements. Marketing and product determine the business objectives.
Code decides what actually happens.
That’s where privacy must be enforced.