The Language of Security Culture

Most security programmes obsess over what people know. Almost none of them pay attention to what people hear. The language we use around security incidents isn’t neutral. It’s a culture signal. And right now, for most teams, it’s sending the wrong one.

The two words doing the most damage

There’s a phrase we hear constantly after a security incident.. “user error”. Two words. Mundane, yes. But genuinely one of the most culturally destructive things you can say.

Not because it’s always inaccurate. Sometimes someone did click something they shouldn’t have. But the moment you reach for “user error” as our explanation, you’ve made a decision about whose problem it is. You’ve named a culprit. You’ve closed the conversation. And everyone in ear shot has just learnt something about what happens when things go wrong around here.

The moment you reach for “user error”, you’ve closed the conversation. And everyone in earshot has learned to stay quiet next time.

That’s the thing about language in security culture. It doesn’t announce itself. Nobody holds a meeting and decides “this is the year we make our people afraid to speak up.” It happens through the accumulated weight of small phrases, repeated often enough that they become the background noise of how your organisation thinks about risk.

And once that noise becomes the norm.. it’s very hard to hear anything else.

Culture isn’t built in an all-staff briefing

People imagine security culture lives in policy documents, annual training completions, and the awareness campaign that lands in October like clockwork and gets ignored just as reliably.

It doesn’t.

Culture is built in the Teams message posted after an incident. The way a manager responds when someone admits they nearly fell for something. The default framing in the team meeting when a near-miss gets reported. The words your security team reaches for when they’re tired and frustrated and something’s gone wrong again.

“They should have known better.”

“This keeps happening.”

“I don’t know why people can’t just follow the process.”

Every one of those phrases tells your people something. It tells them whether security is a shared responsibility or a blame game. Whether admitting a mistake is safe or dangerous. Whether they should speak up next time, or say nothing and hope it passes.

Most organisations put significant effort into designing their security training and almost no effort into designing the everyday language that surrounds it.

Most organisations put significant effort into designing their security training and almost no effort into designing the everyday language that surrounds it. The training runs for an hour, once a year. The language runs constantly, in every team, at every level, in every conversation that touches on security. Guess which one does more of the cultural work.

The words that kill reporting

Here’s what the research is clear on: when people feel unsafe to admit mistakes, they don’t report them. And when near-misses go unreported, the first you hear about the problem is when it becomes an incident.

Blame language creates this silence more reliably than almost anything else. It doesn’t have to be dramatic. You don’t need a public humiliation or a written warning for the message to land. A single dismissive comment in a team meeting is enough. A slightly impatient response to a question that “should have been obvious” is enough. An all-staff email that frames a phishing simulation fail as a collective embarrassment is, astonishingly, enough.

People are perceptive. They read the room. They calculate the risk of speaking up against the cost of staying quiet, and they make a decision every single time. Change the language, and you change that calculation.

The organisations with genuinely strong security cultures aren’t the ones with the most comprehensive policies. They’re the ones where people say “I nearly fell for that” in normal conversation.

The organisations with genuinely strong security cultures aren’t the ones with the most comprehensive policies or the most frequent training. They’re the ones where people say things like “I nearly fell for that, let me tell you what happened” in normal conversation. Where a question about whether something looks suspicious gets treated as a sign of good instincts rather than a sign of incompetence. Where security is something you talk about rather than something that gets talked at you.

That environment is created almost entirely through language

Psychological safety is not a soft concept

This is where the language conversation gets serious.

Psychological safety is the term researchers use to describe the belief that you can speak up, ask questions, flag concerns, and admit mistakes without being punished or humiliated for it. It was identified by Google’s Project Aristotle as the single biggest factor in high-performing teams. It shows up in operating theatres, flight decks, and emergency rooms as one of the most powerful predictors of whether small errors get caught before they become disasters.

In security terms, psychological safety is not a wellbeing initiative. It’s a risk control.

When people feel safe to report, to question, to say “this doesn’t look right to me” without fear of looking stupid or getting into trouble, that is your early warning system. That’s the thing that catches incidents before they become breaches. It’s the call that gets made before the wire transfer goes through. The pause before the password gets typed. The “actually, wait” before the door gets held open.

Fear-led messaging and punitive policies don’t just fail to build culture. They actively dismantle it. They teach your most valuable asset – a workforce that will tell you something looks wrong – to say nothing.

All of that evaporates when the language around security becomes punitive. Fear-led messaging, public shaming through phishing simulations, and policies that punish mistakes rather than surface them don’t just fail to build culture. They actively dismantle it. They take the most valuable asset a security team has, which is a workforce that will tell you when something looks wrong, and they teach that workforce to say nothing.

What to actually listen for

A useful exercise: spend a week paying attention to how your organisation talks about security mistakes. Not what your policy says. Not what the training materials say. What people actually say.

What gets posted in the team channel after a near miss. How leadership frames things in the debrief. What the security team says in the retro. What the reaction is when someone asks a question that suggests they don’t know something they probably should.

You’re listening for the ratio of person-pointing language to process-pointing language. “They clicked the link” versus “the link got clicked.” “User error” versus “the design made that easy to miss.” “People just don’t care” versus “we haven’t made this feel relevant yet.”

The first framing in each pair closes the conversation. It locates the problem in a person, implies they’re the variable that needs fixing, and offers no useful information about how to reduce the risk next time.

The second framing opens the conversation. It treats the incident as information. It asks what the environment made easy, what the design could have prevented, what the system can learn.

That shift in framing is not just semantics. It produces different investigations, different conversations, different decisions, and ultimately a different culture.

Language is a design choice

None of this happens by accident, and it doesn’t fix itself. The default in most organisations, under pressure, when something goes wrong and someone needs to account for it, is to reach for blame. It’s faster. It’s tidier. It closes the loop.

It just doesn’t make you safer.

The organisations that build genuine security culture make a deliberate choice about how they talk about risk, mistakes, and near-misses. They train managers on it. They model it at leadership level. They notice when the old language creeps back in and they correct it, not because they’re soft on accountability, but because they understand that accountability and blame are not the same thing.

Accountability asks: what happened, what do we learn, what changes? Blame asks: whose fault was it? Only one of those questions makes you safer next time.

Your security culture is not a policy document. It’s in the conversations people have when something goes wrong, and whether those conversations make the next person more or less likely to speak up.

Your security culture is not in your policy document. It’s not in your training completion rate. It’s in the conversations people have when something goes wrong, and whether those conversations make the next person more or less likely to speak up.

That’s a language problem. And language is entirely within your control.