The Blame Game

Working Security · Chapter 3

When security fails, we blame people. But individual failure is almost always a structural failure wearing a name badge.

It often goes like this. A mid-size company — about 200 people, with a software product — has a security incident. Not catastrophic, but real. An employee has reused a password across a personal account and a company system. The personal account gets breached. The attacker uses the same password to access the company’s environment. From there they pivot to a shared drive with company data. Nothing is taken, locked, or altered, as far as anyone can tell — but it’s close enough to hurt, and you can never be sure.

There is a post-incident review. A timeline is built. The root cause is identified: “Employee failed to follow password policy.”

Problem named. Nothing is solved. The password policy exists as a PDF on the company wiki that nobody has read since onboarding. The environment has no MFA because someone keeps extending the grace period. The shared drive permissions haven’t been reviewed in two years. No monitoring for lateral movement.

The incident report says: employee failed to follow password policy.

Nothing surprising, except how comfortable we are with the problem. The employee feels guilty. The security team has a root cause. Management has someone to hold accountable. The systemic problem that created the vulnerability remains as it was.

This is the blame game. And many organisations play it without meaning to — it’s built into policies that exist to meet formal requirements.

“Security culture” is doing a lot of heavy lifting

There’s a phrase that gets thrown around, a lot: we need to build a better security culture.

It sounds reasonable. It sounds mature. It sounds like the kind of thing a thoughtful CISO would say at a board meeting. The board would nod and feel good about the direction of things.

But what does it mean in practice? When someone says “we need a better security culture,” what usually follows? Mandatory awareness training. A phishing simulation programme. Reminders sent about password hygiene. Maybe a Slack channel gets resurrected. Maybe an annual e-learning module gets an update. The one that everyone in the company opens after five reminders and clicks through as fast as possible to get back to their actual job.

This is what passes for security culture in many organisations. Here’s the thing that isn’t obvious: it’s also blame pre-loading.

When you tell employees to “be security-aware” without giving them specific guidance for their specific role, you haven’t enabled them. You’ve created a paper trail. When they inevitably make a mistake — because humans make mistakes, that’s the one thing we’re all reliably good at — we point to the training record and say: “We told them. They knew.” So, that’s a liability shield.

A culture where people actually behave differently doesn’t come from policies. It comes from ways of working that make the secure thing the easy thing. From context that helps people understand why something matters. From feedback loops that tell you whether what you did worked.

Very few build this, because it’s hard. The training module is easy, and that’s what the auditor asks for.

The anatomy of blame pre-loading

Let me describe how this happens, because it’s subtle enough that well-meaning organisations do it without realising.

Step one: create a policy. Write a document that describes the ideal behaviour. Make it comprehensive. Cover every scenario. Use language that’s precise enough to be defensible, but don’t overinvest in making sure a normal person would understand and remember it — mandatory training will “fix” that.

Step two: distribute the policy. Email it or put it on a shared drive. Maybe require a signature or a checkbox during onboarding. The important thing is that you can prove people received it.

Step three: deliver training. An annual session. Maybe online, maybe in person. Cover the key points. Test comprehension with a quiz. Record completion. This is your evidence that people were informed.

Step four: monitor for failure. It will come. Someone will click a phishing link, use a weak password, share a file they shouldn’t have, misconfigure a system, or simply forget to do something they were supposed to do.

Step five: point back to steps one through three. The policy existed. The person was trained. They acknowledged the policy. The system worked. Therefore, the human failed.

This is a perfect system — if your goal is accountability theatre. If your goal is actually minimising the failure rate, it isn’t. The policy was written because it was required. The training was generic, disconnected from the person’s actual work. There is a real gap between “received training” and “changed behaviour”, and nobody is responsible for closing it.

I’m not saying policies and training are worthless. They’re necessary. But they’re not sufficient, and when we treat them as sufficient, we’ve built a machine that stops when it finds someone to blame.

The task assignment problem

Another example.

The security team needs to complete an access review. This is a standard control — periodically verify that the right people have the right access to the right systems. Sounds simple. It’s not.

The security team creates a task: “Complete Q1 access review for the customer support system.” They assign it to the lead of the team that uses the system daily.

The person receives the task. They have questions:

None of these questions are answered in the task. The task just says “Complete Q1 access review for the customer support system.”

So the team lead does one of two things. They either spend two hours figuring it out — asking, guessing, doing their best — and produce something that may or may not meet the security team’s expectations. Or they put it off, because they don’t have time to figure it out, and it sits in their task list for weeks until someone chases them.

Either way, the security team is frustrated. “We asked them to do one thing. It’s not that hard.”

But it is that hard, when you don’t have the context. The security team has the context because they live in this world. They know what an access review involves, what good looks like, and what the output should be. They just didn’t share any of that when they assigned the task.

This is a structural failure. The person didn’t fail. The handover failed. The system that should have provided context, criteria, process, and definition of “done” didn’t exist. And when the task is late or incomplete, who gets the blame? Not the system.

Why security people burn out

I want to talk about the security team for a moment, because the blame game eats the security people too.

If you’ve ever managed a security programme, you know the feeling. There’s always more to do than you can possibly complete. Not in the normal “busy at work” sense. In the “I genuinely cannot see the boundaries of this job” sense.

Security work has three properties that make it uniquely exhausting:

It’s invisible. When security works, nothing happens. That’s the point. But it means the work that prevents incidents is rarely seen, barely celebrated, and almost never understood by the rest of the business. You maintained a patch cadence that prevented a breach? Nobody knows. The breach that didn’t happen isn’t on anyone’s radar. You’re doing critical work that produces, by design, no visible output.

It’s unstructured. Unlike other jobs, there’s no natural “done” state. A developer ships a feature. A salesperson closes a deal. A security person… prevents an infinitely expanding universe of bad things from happening? The task list never gets shorter. A successful vulnerability scan produces more work. New regulations add more requirements. New vendors add more risk. There’s no finish line, just an ever-receding horizon.

It’s never-ending. Related but distinct: the work doesn’t just lack a “done” state — it actively regenerates. You complete the access review, and it’s immediately time to start thinking about the next one. You finish the risk assessment, and a new vulnerability disclosure means you need to reassess. You get through the audit, and the clock starts ticking toward the next one.

Put those three things together — invisible, unstructured, never-ending — and you get burnout. Not from working hard. Security people work hard and they’re generally fine with that. The burnout comes from working hard at something that is a constantly moving target, rarely gets acknowledged, and never feels finished.

And when something does go wrong — when there’s an incident, a failed audit finding, a missed regulatory deadline — who’s on the hook? The security person. The one who was already drowning in invisible, unstructured, never-ending work. The system that didn’t resource them properly, didn’t scope their role clearly, didn’t provide tools that match the scale of the job? Nobody holds the system accountable. The system doesn’t have a name on it.

The result is predictable. Security people leave. They leave for better-resourced teams, for consulting roles where the scope is defined by a statement of work, or for jobs outside security altogether. And when they leave, they take the programme with them — because the programme was in their head, because there was no way to externalise it, because the tools and processes never caught up to the reality of the job.

Chapter 2 talked about the knowledge concentration problem — one person holding the programme together. Here’s the human cost of that concentration: the person breaks.

The ownership vacuum

Another pattern that repeats across organisations:

A control exists on paper. Access review, vulnerability management, incident response, vendor assessment — pick any. The policy says it should be done. The auditor expects it.

But who, specifically, owns it?

The CISO owns it, in theory. But the CISO owns everything, which means they own nothing in particular. They’re accountable at the board level, but they’re not the person doing the work.

The IT team does the technical implementation. But they see it as a technical task, not a governance one. They’ll configure the access controls, but they won’t review whether the access is still appropriate in a business context.

The business team uses the system. They know who should have access and who shouldn’t. But they don’t think of access management as their job. That’s “a security thing.”

So the control sits in the space between three groups, owned by all of them and none of them. When the auditor asks to see evidence of the last access review, there’s a scramble. Everyone assumed someone else was doing it. The control exists on paper but not in practice.

This is the ownership vacuum. And it’s not fixed by assigning ownership on a spreadsheet. Organisations create elaborate RACI matrices that span dozens of controls and dozens of people. The matrix exists. Everyone was informed. And the controls still don’t get maintained, because the matrix doesn’t solve the underlying problem.

The underlying problem is this: ownership without clarity, resources, and context is just pressure. You’ve given someone a name on a spreadsheet and no tools to succeed. You’ve told them they’re accountable without telling them what accountability looks like in practice. What specifically do they need to do? What does “done” look like? What support is available?

This pressure and lack of clarity produces anxiety, avoidance, and eventually — when things go wrong — blame.

The phishing simulation problem

An example.

Your organisation runs a phishing simulation. You send a fake phishing email to all employees. 7% click the link. Your response: mandatory security awareness training for the people who clicked. Maybe a second simulation a few months later.

Second simulation: 5% click. Improvement. Maybe the same people, maybe different ones.

What have you learned? That a few per cent of your people will click a well-crafted phishing email at any given time. That’s not a training failure. That’s a human reality. Large benchmark studies — millions of simulated emails across thousands of organisations — show click rates bottoming out around 4–5% even after a year of sustained training. You can’t train your way below that floor, because the people clicking aren’t stupid or careless — they’re busy, distracted, and targeted by increasingly sophisticated attacks.

But the simulation programme doesn’t acknowledge this. It treats the click rate as a failure that training can fix. When it doesn’t fix it, the response is more training.

Think about what message that sends. You’re punishing someone for being human — for having a moment of inattention in a 10-hour day during which they receive 40 emails. Meanwhile, the organisation hasn’t implemented basic controls that would make phishing significantly harder to succeed.

The technical controls aren’t perfect, but they reduce the blast radius dramatically. A clicked link matters a lot less when the email was already flagged, the link was rewritten, and the credential entry page was blocked.

Here’s the uncomfortable truth: phishing simulations, as commonly practised, are not primarily about reducing risk. They’re about producing a metric that demonstrates “security culture.” They’re about having something to put in the board report. They’re about being able to say, after a real phishing incident, that you had a programme in place.

They’re blame pre-loading, automated and scaled.

I’m not against simulations. Done well — with contextual training, with technical controls backing them up, with results used to improve the system rather than punish individuals — they can be part of a meaningful programme. But “done well” is rare. What’s common is a tick-box exercise that lets you feel you’re doing something about the human problem without changing the conditions that create it.

What people actually need

So if blame pre-loading doesn’t work, what does?

I think it comes down to three things. They’re not complicated. They’re just not what many prioritise.

Clarity: what specifically do I do?

“Complete the access review” means nothing to someone who’s never done one. “Review the list of 23 people with access to the customer support system. For each person, confirm they still need access for their current role. Flag anyone who’s changed roles or left the company. Here’s the current list, and here’s who had access last quarter for comparison.” That’s clarity.

This is the task assignment problem from earlier, and the solution is straightforward even if it’s not easy: every task that lands on a non-security person’s desk should include enough context that they can complete it without having to reverse-engineer the intent. What to do. How to do it. What “done” looks like. Who to ask if they’re stuck.

People are more likely to do the right thing when they understand why it matters. That’s why context matters — it’s the basis for clarity. Not in the abstract — “data breaches are expensive” — but in the specific. “This access review matters because this system holds customer data, and stale access is how breaches begin — quietly, with a legitimate login.”

That’s a different sentence than “please complete your access review by Friday.” It connects the task to a consequence the person can understand. It answers the question every busy person asks before doing anything discretionary: “Why should I care about this right now?”

Context isn’t free. Someone has to create it. But this is one of the key differences between washing security and working security.

Feedback: did it work?

Many security tasks disappear into a void. You complete the access review. You hear nothing. Was it right? Was it what the security team needed? Did it actually contribute to the programme? No idea.

Feedback matters because it’s how people learn and improve. It also matters because it’s how people feel valued. When you do work and get no response, the implicit message is that the work doesn’t matter. Next time, you’ll invest less effort. The time after that, even less. Eventually you’ll do the minimum to tick the box, which is exactly the behaviour you were trying to prevent.

Simple feedback loops make an outsized difference. “Access review completed — three changes identified and actioned. This control is now current. Thank you!” That sentence costs almost nothing and changes the experience entirely.

Proportionality: is this the right amount of effort?

People have a strong sense of whether a task is proportionate to its importance. When a low-risk task requires high effort, they disengage. When everything is presented as equally critical, nothing is actually prioritised.

Many security programmes are not very good at proportionality. Every control is important. Every task is urgent. Every risk needs attention. When you can’t distinguish between “this access review covers a system with customer financial data” and “this access review covers the office Kahoot! account,” you’re asking people to apply the same effort to both. They won’t. And they shouldn’t.

Proportionate task assignment — where the effort required matches the risk involved — is a sign of a mature programme. It’s also a sign that you respect people’s time.

The alternative

I’ve spent most of this chapter describing what’s broken. Let me be clear about what I’m not saying.

I’m not saying individuals have no responsibility for their behaviour, or that security awareness is worthless.

What I am saying is that when you design a programme that depends on perfect behaviour — on every person, every time, making the right security decision — you’ve designed a programme that will fail more often. And then when it fails, you blame the imperfect humans rather than the system that demanded perfection.

The structural alternative is a programme that assumes people will be imperfect — because they will — and builds resilient systems to recover from the inevitable mistakes. Technical controls that reduce the blast radius of human error. Task assignment that provides enough context to make the right action obvious. Feedback loops that reinforce good behaviour and correct mistakes early. Clear ownership that’s backed by actual resources, not just a name on a matrix.

This isn’t radical. It’s how other critical domains work. Aviation doesn’t depend on pilots never making mistakes. It builds systems — checklists, automation, redundancy, crew resource management — that catch mistakes before they become catastrophes. Healthcare doesn’t depend on doctors never misdiagnosing. It builds systems — second opinions, diagnostic protocols, adverse event reporting — that reduce the frequency and impact of errors.

But in security we persist in designing programmes that depend on human perfection and then act surprised when humans turn out to be human.

The blame game is comfortable. It gives us someone to point to. It produces a root cause that fits in a report. It absolves the organisation of having to fix the harder, structural problems.

But it doesn’t make you more secure. It does the opposite, because people who fear blame stop reporting mistakes. And unreported mistakes are the ones that become incidents.

What to do Monday morning

  1. Pull your last three incident reports and read the root causes. If any of them end with a person — “employee failed to follow policy,” “admin misconfigured the system,” “user clicked a phishing link” — ask: what structural condition allowed that mistake to become an incident? Was there a missing control, an unclear process, an ownership gap? Write down the structural root cause next to the individual one. That’s your real finding.

  2. Pick one recurring security task that gets assigned to non-security staff and rewrite it. Add why it matters (specific consequence, not generic risk), what specifically to do (steps, not just a title), and what “done” looks like. Send it to the person who usually receives it and ask: “Is this clearer? What’s still confusing?” Their answer will teach you more about your programme than your last audit did.

  3. Stop measuring phishing click rates as a standalone metric. If you run simulations, pair the click rate with the report rate — how many people flagged the email as suspicious? That’s the behaviour you actually want. A programme where 10% click but 40% report is healthier than a programme where 5% click and 2% report. One is building a response culture. The other is building a fear culture.

People aren’t the vulnerability. Your approach to people is.

← The Overwhelm

The Standards Trap →

From Working Security. Not washing it.