Security Lives in the Variance: When Averages Help (and Hurt)

In the 1950s, the U.S. Air Force ran into a problem that should have put the phrase “the average person” in the bin.

They were designing cockpits around the “average” pilot. Proper measurements. Multiple dimensions: height, arm length, leg length, chest size, and so on. The logic was straightforward: design for the middle and you’ll fit most people well enough.

Then they checked the actual pilots.

Not a single one matched the average across all the measures. Not one. The “average pilot” existed in the spreadsheet, and nowhere else. So they stopped designing for an imaginary human and redesigned the cockpit around variation: adjustability, flexibility, range.

That lesson matters in cybersecurity more than we like to admit, because “average” thinking is everywhere in human risk. To be clear: averages aren’t useless. They’re often a decent directional signal at level. The problem is treating them as the whole story. In practice, the interesting part is almost always how people and teams differ from their own normal. That’s where baselines earn their keep.

The annoying part is that the average is often statistically fine. It’s just operationally misleading. We roll out one training programme for everyone. We publish one policy for everyone. We set one threshold for everyone. We look at a department’s mean score and talk as if it describes the people inside it. We celebrate improvements in “the average” and then wonder why the same incidents keep happening.

With humans, the thing that matters is rarely sitting politely in the centre of the distribution. Risk lives in the spread: the pockets of people with unusually high exposure, high workload, unusual access, odd working hours, or simply a different day-to-day reality. In security terms, that might be the small group handling sensitive documents constantly, the admins with elevated privileges, the team working out of hours, the new starters who haven’t yet learned what “normal” looks like in your environment, or the one department quietly doing a very different job than everyone assumes.

If you design for the average employee, you end up with the cockpit problem: something that looks fair on paper, but fits nobody particularly well. The people who need the most support get generic advice. The people who are already doing fine get more noise. And the security team gets a dashboard full of averages and a vague sense that the programme is “running” without actually changing much.

This is also why benchmarking so often fails to meet information expectations. “Compared to the industry average” sounds useful until you remember what that average is made of: wildly different organisations with different tooling, different reporting cultures, different access models, different maturity, different exposure. It smooths away the context that actually determines risk, then hands you a single number and asks you to feel something about it.

What works better is designing — and measuring — for range.

That means baselines (you compared to you), segmentation (teams, roles, access levels), and patterns over time rather than one headline number. It means treating “normal” as something you establish and revisit, not something you borrow from a benchmark report. It also means being honest about variance: the point isn’t to punish people at the edges, it’s to stop pretending the edges don’t exist.

At Praxis Security Labs, this is exactly what we build for. Praxis Navigator helps teams see behavioural security signals against their own baselines and distributions, so you can spot where risk is concentrated, what’s shifting over time, and whether an intervention did anything beyond nudging an average.

If you’re tired of security programmes designed for a mythical “average employee”, try Praxis Navigator. You’ll get a clearer view of what “normal” looks like in your environment — and what sits outside it.