At first glance, it looks like yet another chapter in the long history of regulatory efforts to protect digital privacy – and at the same time, a textbook example of why those efforts continue to fail in practice. Recent findings suggest that even basic opt-out signals, actively set by users, are not consistently respected by major technology platforms. What makes this particularly striking is that we are not dealing with grey areas or complex interpretations, but with clearly defined technical signals that are visible in network traffic – and yet still ignored.
At the center of this discussion is the Global Privacy Control (GPC), a mechanism introduced under the California Consumer Privacy Act (CCPA). The concept is straightforward: users should be able to signal, once and universally, that their data must not be sold or shared. This signal is transmitted automatically when a website is accessed and is supposed to be honored across all participating systems. However, this is precisely where the breakdown begins. Despite the presence of this signal, analyses show that tracking technologies remain active and cookies continue to be set – clearly serving the purpose of user identification and behavioral tracking.
The real significance of this issue, however, goes far beyond the behavior of individual companies. What we are witnessing is a structural gap between what is defined at a regulatory level and what actually happens at a technical level. And it is exactly at this intersection that two worlds—traditionally treated as separate—begin to collide: cybersecurity on one side, and information security and compliance on the other.
From a technical standpoint, the situation is surprisingly transparent. Any reasonably equipped Security Operations Center (SOC) using a modern SIEM platform would be able to trace these activities without much effort. Network traffic can be inspected, headers are visible, and the setting of cookies can be clearly identified. In other words: the failure to honor opt-out signals is not hidden – it is observable, measurable, and in many cases, obvious.
This is where things become particularly interesting from our perspective. As operators of Darkgate, and at the same time as an internationally active recruiting agency focused on IT security, cloud, and infrastructure, we don’t just observe these discrepancies theoretically – we see them in the market. We see them in conversations with candidates, in ongoing projects, and in the expectations companies place on security roles.
We speak daily with SIEM engineers, SOC analysts, CISOs, and also with consultants from firms such as Deloitte, PwC, EY, and KPMG. Across these conversations, a consistent pattern emerges—one that is rarely addressed openly.
In several projects across the DACH region, SIEM architects and SOC leads have described situations where they can clearly trace how data flows across systems, including tracking mechanisms, third-party calls, and cookie behavior. Yet at the same time, these insights often have little to no impact on formal compliance assessments. Audits are passed, certifications are granted, and governance frameworks appear intact – while the technical reality tells a different story. This disconnect frequently leads to internal friction, as operational security teams are fully aware of existing gaps, but lack the organizational leverage to address them within formal compliance structures.
Another example comes from our day-to-day recruiting work in information security. Increasingly, companies are searching for hybrid profiles—professionals who understand both technical security and regulatory frameworks. Traditional role boundaries are dissolving. A pure compliance manager without technical depth is no longer sufficient, just as a purely technical engineer without an understanding of risk, liability, and governance is no longer enough. This shift directly reflects what we see in the GPC debate: the separation between “paper compliance” and “technical reality” is no longer sustainable.
And yet, despite this awareness, many organizations still operate within outdated control frameworks. Traditional audits – often led by large advisory firms – continue to focus heavily on documentation, process descriptions, and formal controls. The key question tends to be whether a policy exists, whether a consent mechanism is implemented, and whether procedures are defined. What is often missing is a continuous, technical validation of whether these controls actually work in real-world conditions.
This is where the concept of “privacy theater” becomes relevant. Organizations invest significant resources into presenting compliance—designing consent banners, drafting policies, and implementing governance frameworks. From the outside, everything appears controlled and aligned with regulatory expectations. But beneath the surface, a different reality unfolds—one that is not reflected in documentation, but in actual data flows and system behavior.
This gap becomes even more critical when looking at the role of large advisory and audit firms. Organizations such as Deloitte, PwC, EY, and KPMG have significantly expanded their cybersecurity and compliance capabilities in recent years. At the same time, they are increasingly moving into technical domains such as Managed Detection & Response and SIEM-driven analytics. This is not coincidental—it is a direct response to the growing realization that traditional compliance approaches are no longer sufficient.
As organizations recognize the limitations of static audits, the demand for systems that measure actual behavior not just theoretical controls is increasing. In this context, SIEM platforms are evolving beyond their original role as pure security monitoring tools. They are becoming sources of evidence—providing verifiable, technical proof of what is actually happening across systems and networks.
This evolution is driving a fundamental shift in how information security is understood. Instead of focusing solely on policies and control definitions, organizations are beginning to question whether these controls are effective in practice. And effectiveness cannot be proven through documentation alone—it must be observable, testable, and continuously validated at a technical level. This creates a new intersection between security engineering and risk management—one that many organizations have not yet fully integrated.
At the same time, the current situation raises an uncomfortable question: who is ultimately responsible when such systems fail? Is it the technology provider offering tracking infrastructure? The website operator implementing it? Or the auditors who certify the system as compliant? In practice, responsibility is so widely distributed that it often becomes diluted. Each party can argue that it has fulfilled its role—while the overall system still fails to deliver on its intended purpose.
This fragmentation of accountability is one of the key reasons why these issues persist. It creates an environment in which non-compliance is not necessarily the result of deliberate misconduct, but rather a systemic byproduct. At the same time, it makes effective enforcement extremely difficult, because there is no single point of control where technical reality, governance, and accountability converge.
For organizations, this leads to growing uncertainty. Regulatory pressure is increasing, fines are rising, and expectations around transparency are becoming more stringent. Yet the question remains: how can true compliance be ensured in such a fragmented environment? The answer increasingly points toward continuous monitoring and technical validation. Passing an annual audit is no longer sufficient. Systems must be able to demonstrate—at any given moment—that they function as intended.
This is also where the opportunity lies. The convergence of SIEM, GRC, and real-time analytics offers a path toward closing the gap between theory and practice. Instead of relying on static reports and periodic reviews, organizations can gain dynamic visibility into their actual data flows and detect deviations as they occur.
In the end, one conclusion becomes unavoidable—and it is not just derived from reports, but from direct market experience: as long as compliance cannot be technically verified, it will remain inherently fragile. The ongoing discussion around ignored opt-out signals is not an isolated issue, but a symptom of a much deeper structural problem. One that can only be addressed by shifting the focus from documentation to verifiable technical truth.
Or put differently: if compliance cannot be proven in the network traffic, it likely does not exist at all.
