A Privacy Policy Is Not a Faraday Cage

There is something wonderfully literal about putting a car inside a Faraday enclosure because you want to know whether it is talking behind your back.

Consumer Reports and researchers from Northeastern University recently did essentially that. They tested 21 late-model vehicles and 30 companion apps to understand what information was leaving connected cars and where it was going. To isolate some of the traffic, researchers placed vehicles inside a specially constructed Faraday enclosure that blocked cellular signals, forcing communications through channels they could observe.

The results were not .... subtle.

Nineteen of the 21 vehicles contacted at least one third party over Wi-Fi. Twenty-eight of the 30 companion apps contacted advertising or analytics companies. Seven apps transmitted personally identifiable information such as VINs, email information or precise location to outside companies. The full Northeastern study, Automatic Transmission: An Empirical Study of Data Privacy in the Connected Vehicle Ecosystem, is worth reading because the researchers were measuring real network activity, rather than simply comparing privacy notices.

There is plenty to say about connected-car privacy. But there is another lesson in the experiment that is useful far beyond cars.

Here's what I like about it: the researchers did not simply ask what the privacy policy said, they tested what the system actually did. (And security could stand to do a lot more of that.)

What is the difference between policy and evidence?

Policies matter because they define expectations, responsibilities and intended controls. A privacy notice may explain how data should be handled. A security policy may require multifactor authentication. An AI policy may prohibit staff from entering confidential information into consumer tools. A manager may be completely sincere when they say everyone understands the escalation process, just as a supplier questionnaire may contain an entirely reassuring set of affirmative answers.

None of those things is useless. The problem begins when we treat the statement of intent as evidence of the operating reality.

A policy tells us what should happen. An attestation tells us what somebody says is happening. A control description tells us what has been designed. None of those, by itself, tells us what people or systems are actually doing when the work gets messy.

That distinction seems obvious when somebody is building a signal-blocking enclosure around a car. Inside an organization, it is surprisingly easy to lose. We have written about the same gap from a different angle in From Compliance to Confidence: How to Build Forward-Looking Security Programs: passing an audit or satisfying a framework is useful, but it does not automatically establish that people, processes and controls will behave as intended when conditions change.

The connected-car study is really an assurance story

The Northeastern research is interesting because the system being examined was largely invisible to the person using it. A modern car does not flash up a notice every time a VIN is transmitted, an analytics platform is contacted, or another third party enters the data chain. (Maybe it should?)

The complexity sits underneath the user experience.

So the researchers changed the environment until the system became observable. They monitored network traffic, separated vehicle and application behavior, blocked communication paths and compared what happened across different products.

That is the heart of assurance. You move beyond asking what controls are meant to exist and start looking for evidence of what is actually happening.

We run into exactly the same problem in Human Risk Management.

How do you know a human-risk control is actually working?

A typical security program can look healthy on paper. Training completion may be above 98 percent. Phishing simulation click rates may be trending down. Employees have attested to the acceptable-use policy. Managers say security is taken seriously.

All of that can be true and still leave some very important questions unanswered.

Can people recognize the situation the training was meant to prepare them for when it appears in a less obvious form? Do they behave differently when the decision is ambiguous? Do they report mistakes quickly, or hide them because they are worried about the response? Do they understand which AI tools they can use, what they can put into them, and when they are expected to escalate? Are employees working around controls because the approved process does not fit the work?

Those questions move us from activity into capability, behavior and environment.

That is why, in our own work, a Human Risk Baseline is useful precisely because it does not start with the assumption that the existing metrics are telling the full story. The point is to establish a more grounded view of competency, behavior, psychology, culture and exposure, then understand where the lived reality differs from the intended one.

We have seen this directly with clients. In one global workforce Human Risk Baseline, training data could show that learning had been delivered, but it could not show where policy understanding, confidence, behavior or culture differed across regions and functions. Once those layers were measured together, the organization could see where risk actually existed and, more importantly, why.

The same principle applies whether the system under examination is a connected car, a workforce or an AI-enabled process.

Stated design is not observed operation.

Why do organizations mistake documentation for reality?

Partly because documentation is easy to inspect.

You can find the policy, count the attestations, export the LMS report, pull the configuration and point to the control description. Those artifacts are tidy. They travel well into audit meetings and dashboards.

Reality is less cooperative.

People improvise. Teams interpret requirements differently. A process that worked perfectly well before a reorganization starts to break at the edges. A control technically exists, but the approved workflow is slow enough that people route around it. A manager quietly tells the team that the official process is optional because the business needs to move faster.

None of this means the organization is dysfunctional. It means organizations are living systems.

That is one reason mature Human Risk Management looks less like an awareness calendar and more like an operating discipline. Strategy, measurement, governance, behavior, culture and intervention have to connect if you want to understand whether the program is changing actual risk rather than generating reassuring activity. That is also why we describe Human Risk Management as an operating model, rather than simply another software category.

What does ground truth look like in Human Risk Management?

There is rarely a single source that can tell you the whole truth, and that is where measurement gets difficult.

A survey can tell you what people believe or report. A simulation can tell you how they respond in a constructed scenario. System telemetry can show that an event occurred. Incident data can reveal where controls failed under pressure. Interviews can expose how work is really done. Managers can tell you where friction appears. Training results can show where knowledge is weak.

Each source matters, but each answers a different question.

This is where security programs often get into trouble. A phishing click gets treated as a measure of security competence. A failed quiz answer gets treated as evidence of risky behavior. A DLP alert becomes shorthand for poor judgment. A survey score gets reported as if it were observed behavior.

The issue is not that these signals are bad. It is that we often ask them to carry more meaning than they can support. We explored the same measurement problem in How Do You Measure Human Risk in AI-Driven Work?, where the difficulty is not a lack of data so much as knowing which signals genuinely tell us something about behavior, capability, reliance or risk.

A stronger approach is to triangulate. If multiple forms of evidence point in the same direction, confidence increases. If they conflict, that conflict is itself useful information.

That is much closer to how assurance should work.

It is also why our Human Risk Assessment and measurement work looks across knowledge, behavior, psychology, culture and exposure rather than trying to make one metric explain the whole human system.

Why does this matter more as systems become harder to see?

Because increasingly, the interesting risk exists in the relationships between things.

That is exactly what the connected-car study exposed. A VIN on its own may not seem terribly sensitive. An email address is hardly unusual. Location is necessary for navigation. A companion app needs information to provide useful features. An analytics platform is a routine part of modern software.

The risk emerges when those elements are connected.

A persistent vehicle identifier linked to identity, location, application behavior and a third-party data ecosystem becomes more consequential than any single piece of information involved.

Organizations are heading in the same direction.

An employee may use an approved AI assistant. The assistant may have access to enterprise information. It may also have tools, delegated permissions and the ability to act. A manager assumes somebody is reviewing the output. A policy says a human remains accountable.

Every individual part of that arrangement may look reasonable. The important question is whether the combined system still behaves inside the boundaries everyone thinks it does.

That is an assurance problem.

It is also one of the reasons we argue that AI workforce risk belongs inside Human Risk Management. The technical system may be functioning exactly as designed while risk is emerging through the way people rely on it, supervise it, work around it or interpret what it produces.

As agentic systems expand, that boundary becomes even more important. Our recent work on the human permission layer in AI risk looks at the same problem from the perspective of authority: who can authorize, supervise, intervene or expand what an AI system is allowed to do?

Is policy still important?

Of course.

Policy defines intent. Governance establishes accountability. Controls shape what is possible. Learning builds capability. Culture influences what people actually do. Measurement gives us evidence.

Assurance is where those things are compared with reality.

The mistake is expecting one layer to prove another.

Training completion cannot prove competence any more than a policy can prove behavior. Technical deployment does not prove adoption. An attestation does not prove comprehension. A dashboard cannot prove the validity of its own measurement model.

This is particularly visible in AI governance. You can build the framework, publish the policy and establish the approval process, while everyday behavior quietly develops somewhere else. We explored that gap in AI Governance Culture: The Invisible Backbone of Trustworthy, Responsible, and Resilient AI: governance becomes real through the decisions, norms and behaviors that occur after the document is published.

At some point, somebody has to look at the thing itself.

What should security teams do differently?

The answer is not to verify everything. That way lies an impressive amount of paperwork and very little progress. So we think a better question is where stronger evidence would materially change your understanding of risk.

Which assumptions are carrying the most weight? Where could the stated control and the lived reality diverge in a meaningful way? Where does the organization depend on people making a particular decision under pressure? Where are you using a proxy because the real behavior is difficult to observe?

Those are the places worth examining more carefully, and it doesn't all enter into the HRM Team in the same way. 

Sometimes the right evidence is a survey. Sometimes it is behavioral telemetry. Sometimes it is an interview, a simulation or an end-to-end test of a workflow. Sometimes the most useful thing you can do is simply watch how the work actually gets done. (Hopefully, with snacks). 

Testing itself also needs to be designed carefully. A phishing program, for example, can tell you far more than who clicked if it is built to examine recognition, reporting and susceptibility rather than simply generating another percentage. That is the approach behind our Managed Phishing work, while our Cyber Learning Experience helps build the underlying knowledge, confidence and safer habits those tests are supposed to exercise.

The point is not surveillance. The point is to understand enough of the real system to improve it.

That is also why Human Risk Management should not reduce people to a score. The interesting question is rarely whether a person is "risky." It is why a particular behavior is happening, what conditions are shaping it, and whether the organization can change those conditions in a way that makes safer behavior easier.

For organizations dealing with the additional uncertainty introduced by AI, our AI Enablement & Change work applies the same principle: measure readiness, capability, confidence and behavioral risk first, then target the intervention rather than assuming that publishing guidance will make adoption safe.

Assurance gets interesting where the policy stops

The connected-car research gives us a wonderfully physical illustration of an increasingly digital problem. The policy can describe the system. The architecture diagram can describe the system. The manufacturer can describe the system. But if the question matters enough, somebody eventually has to ask what the system actually does. (POSIWID! IYKYK) 

That question belongs everywhere: in privacy, cyber, Human Risk Management, AI governance, culture and control design. Anywhere the documented version of reality and the lived version of reality have had enough time to quietly drift apart.

Policies still matter. But every now and then, you need the Faraday cage.