The Blame Reflex

On why your incident response culture is shaping everything else.

There is a moment that happens in almost every organisation after a cyber security incident. A moment so predictable… and so universally rehearsed… that it might as well be scripted, and it goes like this… somebody clicked something they should not have clicked, and now everyone wants to know who.

They don’t want to know what happened. Or what conditions made it possible. Or even what the environment was doing in the thirty seconds before the click that made clicking feel like the reasonable thing to do. Just “who?”. Because once you have a who, you have a story, and the story is simple and satisfying and, most importantly, it points away from anything structural. Dave in accounts clicked the link. Dave in accounts should have known better. Dave in accounts will be sent on a refresher course, perhaps with a slightly disappointed email from his line manager, and the organisation will carry on exactly as it was… confident that the problem has been addressed because the person has been identified.

This is the blame reflex. And it is, without exaggeration, one of the single most destructive forces in security culture, not because it is cruel (although it often is, in that bureaucratic, plausible deniability kinda way that organisations have perfected), but because of what it teaches everyone else.

Here is what it teaches everyone else: do not get caught.

Not “be more careful.” Not “report things early.” Not “ask for help if something looks wrong.” The lesson that blame culture actually delivers, with precision and efficiency, to every person who watches Dave get walked to his refresher course, is that the safest thing to do when something goes wrong is to say nothing, close the laptop, and hope that whatever just happened resolves itself before anyone starts asking questions.

Sadly, this is not speculation. Proofpoint’s State of the Phish report found that 96% of employees who took risky actions knew, at the time, that what they were doing was risky. They didn’t lack awareness. They didn’t need more information. They made a calculation, consciously or otherwise, about what would happen if they followed the process versus what would happen if they did not… and the environment had already taught them the answer. Following the process is slow… sometimes genuinely obstructive… and the reward for doing it correctly is nothing. There’s no recognition, no feedback, not even a nod, just the absence of trouble. Taking the shortcut is fast, gets the job done, and the consequence, on most days, is also nothing. Until the day it is not nothing, at which point the organisation reaches for the only tool it has practiced… find the who.

96% of employees who took risky actions knew, at the time, that what they were doing was risky.

This is culture. Not the culture anyone designed or the culture the policy describes. It’s not the culture the CISO presents to the board with a slide that says “Security Culture Programme” in a font that conveys authority. This is the culture that actually operates… the one people learn by watching what happens to other people, the one that forms in the gap between what an organisation says it values and what it actually does when something goes wrong

And the important thing about that gap is that your people are extraordinarily good at reading it. There is a reason that children learn more from watching their parents than from listening to them (like they ever listen)… and the same principle operates in every team, every department, every floor of every building where humans are trying to figure out the unwritten rules of how things work around here.

You can put the words “we encourage a no blame culture” on a poster in every breakroom from London to Leeds but the moment someone watches a colleague get moved sideways after a phishing incident… well… that poster becomes wallpaper. Expensive, well intentioned wallpaper that everyone walks past without seeing because the real information, the information that actually shapes behaviour, arrived through a completely different channel.

Psychological safety is not a soft concept. It is not an HR initiative or a wellness trend or something that belongs in a separate conversation from security. Psychological safety is the single biggest predictor of whether your security culture will actually function under pressure… because it determines the answer to one very specific question that every employee carries around with them. And that is “what happens to me if I report something?”

If the answer is “nothing bad, and probably something useful” then you’ll likely get early reporting, fast containment, small incidents that stay small, and a gradually accumulating body of knowledge about what threats actually look like in practice. If the answer is “I become the person who caused the incident even if all I did was notice it” then you get silence, delayed reporting, incidents that metastasise in the dark, and a security team that only finds out about problems once they have already become expensive. Ouch.

The research on this is.. once again.. unambigious. Google’s Project Aristotle, which spent two years studying what made teams effective, concluded that psychological safety was not merely important but was the foundational condition without which nothing else worked. Not talent, not resources, not process, not technology. If people did not feel safe to take interpersonal risks, to admit mistakes, to say “I think I might have just done something stupid” then every other investment the organisation made in that team was operating at a fraction of its potential.

Now… let’s put it into OUR context and apply that to security. Every phishing simulation that ends with a “you failed” screen is a tiny, almost imperceptible deposit into the blame account. Every incident review that starts by identifying the person rather than the conditions is another deposit. Every all-staff email that says “please be more vigilant” after a breach, as though vigilance were a resource that people were simply choosing not to deploy, is another deposit. And over time… those deposits compound into a culture where the rational response to making a mistake is not to report it but to hide it… not because people are dishonest but because the environment has made honesty expensive. And silence? Well, silence is free.

The organisations that have genuinely good security cultures, and they are definitely out there (though fewer than the conference circuit might suggest), have one thing in common that has nothing to do with their training platform or their phishing click rates or their awareness module completion percentages. They have figured out how to make reporting feel safe. Not safe in the abstract, policy document kinda way where a page somewhere says that reporting is encouraged. Safe in the felt, lived, Tuesday afternoon sense where someone who has just clicked something suspicious can walk over to a colleague or pick up the phone or fire off a message to the security team and say “I think I fucked up” without their heart rate increasing.

That is a culture achievement. And it is not built by training. It is built by what happens AFTER the training… by how leaders respond to mistakes… by whether the security team is seen as a source of help or a source of consequences… by a thousand small signals that accumulate over months and years into an environment where people either feel ownership over security or feel surveilled by it.

The blame reflex is so deeply embedded in most companies that it does not even register as a choice. It feels like accountability. It feels like rigour. It feels like the responsible thing to do, because someone HAS to be responsible, and identifying that someone feels like progress. But it is not progress. It is the organisation telling itself a nice little story about individual failure so that it does not have to confront the more uncomfortable truth about systemic design.

Dave did not click the link because he was careless. Dave clicked the link because the link was well crafted, the timing was right, the context was plausible, and nothing in Dave’s environment had prepared him to feel the difference between a real request and a manufactured one. That is not a Dave problem. That is a conditions problem. And until organisations stop treating incidents as character failures and start treating them as design feedback, the culture will keep doing exactly what it has been trained to do… which is punish honesty, reward silence, and call the whole thing awareness.

The irony is thick enough to spread on toast. (Not quite as nice as Nutella though). The very mechanism that most organisations use to “improve” security culture after an incident, finding the who and making an example of them, is the mechanism that guarantees the culture will not improve. It is like trying to encourage people to swim by throwing the ones who splash into the deep end. The lesson everyone learns is not to get in the water.

So if you are sitting in a security leadership role and you genuinely want to know what your culture looks like, stop looking at your training dashboard and start looking at your incident response. Not the technical response. The human one. What happens to the person who reports? What happens to the person who was involved? What does the post-incident review actually focus on? Is anyone tracking the time between incident and first report, and is that number getting shorter or longer?

Because that number, more than any completion rate or phishing simulation score or beautifully designed awareness metric your vendor is selling you, tells you exactly what your culture is doing when nobody is watching.

And if the number is getting longer… you don’t have a training problem. You have a trust problem. And trust is not built in a module.