For years, cybersecurity has been sold as a fortress-building exercise. The language is dramatic — military-grade encryption, zero-day protection and ironclad infrastructure. Yet, breach after breach tells the same unremarkable story: Someone clicked something they shouldn’t have; someone left a port open; someone trusted the wrong system. 

As someone who’s spent years in the trenches of cybersecurity, I have seen this play out time and again. The most sophisticated attacker rarely defeats the most sophisticated system. They defeat the least careful person connected to it. 

In other words, the flaw isn’t in the code — it’s in the conduct. We like to think of cybersecurity as a highly technical thing, but the threat landscape is far more human and complicated. The errors that bring down multimillion-dollar infrastructures are often laughably simple: A reused password, a forgotten environment or a permission granted out of habit. 

Cybersecurity isn’t just about defending systems. It’s about analyzing how humans behave under stress, distraction or convenience — and designing around that, not despite it. 

In almost every high-profile breach, it wasn’t that the hackers outsmarted the technology. They exploited trust, routine and human fallibility. Until we stop treating these as edge cases, but as the default state of the world, we’ll keep building walls with the wrong blueprint. 

What we need isn’t a fantasy of flawless systems. We need a framework built for fallibility — resilient enough to expect mistakes and functional enough to survive them. 

People are the Real Attack Surface 

You can encrypt data. You can isolate networks. You can audit every line of code. But you can’t stop a user from clicking a link that looks like it came from a friend; or reusing the password they created in 2007 for a long-dead forum; or skipping the security prompt because they’ve ‘never used it anyway’. 

We have architected entire infrastructures to keep bad actors out. But we forget that the easiest way in isn’t through the firewall — it’s through the front door, wearing a trusted face. Phishing, credential stuffing and social engineering — none of these are new. But they are disturbingly effective because they target the one thing that never gets updated: Human instinct, especially in emotionally charged environments such as gaming or social platforms, attackers mimic urgency, reward and familiarity to sidestep the logic gates entirely. 

It’s not about recklessness — it’s about reflex. These attacks target the lizard brain — triggering panic, desire and fear of missing out (FOMO). And in that split second, policy becomes irrelevant. What matters is your gut reaction. 

Here are several now-infamous examples: 

• The Slack token attack at EA, where hackers simply asked an employee for access.
   

• The Twitch data leak, when misconfigured permissions and stolen credentials collided.
   

• The Google Docs worm, which spread like wildfire by impersonating a Google permission request. 

None of these were zero-day exploits. They were trust exploits.  

You can’t patch curiosity. You can only design for it. 

My approach? Make the secure choice the easy one. Not by punishing mistakes, but by studying the psychology that leads to them. Phishing simulations aren’t witch hunts. They’re behavior audits. Usability testing isn’t fluff, it’s critical infrastructure. 

Security that frustrates users will always be bypassed. So, don’t design for perfection. Design for real people, in real workflows, under real pressure. At the end of the day the people will click.
The question is: What happens next? 

When the Call is Coming from Inside the House 

It’s easy to imagine attackers as outsiders breaching the perimeter. But some of the most dangerous failures start inside, with the people building the system. A rushed configuration, an exposed development tool or a last-minute code commitment that skips review — these aren’t acts of sabotage. They’re decisions made under pressure, with limited visibility. The issue isn’t bad actors — it is system complexity and the gap between speed and safety. In fragmented environments, no one sees the whole picture. Risks build quietly. 

That’s why I advocate for intentional security: A shared culture where responsibility extends beyond the security team. It’s not about turning developers into experts, but giving them ownership, secure defaults, embedded tools and a safe space to raise concerns. One of the worst-case scenarios? Someone notices something off but says nothing. Not because they don’t care, but because they’re unsure it’s their job. By the time it is — it’s too late. 

Policies can’t catch mistakes. People can. But only if speaking up is expected, not questioned. 

Error Chains — Why Mistakes Happen Despite Best Intentions 

No breach ever starts with a grand, cinematic act of sabotage. It starts with a missed update or a stale test account or a security alert flagged one too many times as a false positive. Like a row of dominoes, each small, understandable lapse quietly lines up until the last one topples the system. It’s never one thing. It’s a dozen tiny things, all happening in the wrong order, under the wrong circumstances. 

During my work leading global application security at Sony, I saw firsthand how failure travels. The public is rarely wrong. It’s the execution that collapses under pressure: Deadlines, shifting priorities, product launches that can’t be delayed and systems that don’t tolerate friction. Security doesn’t fail in theory, it fails in the field — where stress is high, time is short and vigilance feels optional. 

Real-world examples are abundant: 

• Capital One’s 2019 breach began with a misconfigured AWS firewall, paired with access by a former contractor.
   

• Uber’s 2016 incident was the result of hardcoded AWS keys left exposed in a public GitHub repo.
   

• Facebook’s 2021 leak of over 500 million records stemmed from an abused contact importer API with poorly throttled permissions. 

None of these were the result of a single glaring mistake. They were chains of plausible decisions, made under duress, in fragmented systems without enough safeguards. The myth that strong policies equal strong outcomes is seductive but naïve. Policies are only as good as the environment they live in — resilience trumps rigidity every time. 

Instead of punishing errors, I build systems that expect them. For instance, guardrails that limit blast radius, automated checks that don’t rely on perfect attention spans and incident reviews that aren’t about blame, but about how we understand the anatomy of failure. Every breach is a lesson plan; yet if you treat it like an embarrassment instead of a dataset, you’ll learn nothing. 

Cybersecurity isn’t a game of perfect execution. It’s a game of absorption — absorbing pressure, mistakes and chaos without letting it become catastrophic. 

Can Automation Save Us? 

If human error is inevitable, the next question practically writes itself: Can we automate our way out of it? 

Yes, and no. 

Automation is one of the most powerful tools in a security leader’s arsenal, especially when it comes to repetitive, error-prone tasks. Enforcing secure configurations, scanning code for known vulnerabilities, flagging leaked credentials and blocking outdated libraries are chores that machines handle better than humans ever could. Machines don’t get tired; they don’t cut corners because they’re late for a meeting. They simply execute, and that’s a huge advantage. 

My teams have used automation to run static and dynamic code analysis, enforce policy at the continuous integration/continuous delivery (CI/CD) level and spot drift before it becomes breach material. But for every case where automation works beautifully, there’s another where it introduces new, more insidious risks. Automation reflects the assumptions of the people who built it. If those assumptions are flawed, the automation won’t just replicate the mistake — it’ll scale it. 

I have seen companies deploy bots that sent alerts into dead channels, or auto-approved changes that violated every security principle, simply because no one thought to build a failsafe into the system. Some rules flagged erroneous behavior, while others flagged too many, burying real threats under noise. 

The goal, then, isn’t to replace human decision-making, but amplify it. I see automation as a co-pilot, not a commander. Its job is to clear clutter, surface anomalies and reduce the cognitive load on the people doing the hard thinking. The true power of automation is consistency. It frees your team to focus on edge cases and nuance — things machines can’t reason through. This creates space for judgment. 

Judgment must still exist. Someone must still ask, ‘Does this make sense’? Automation won’t challenge your blind spots. It won’t stop a bad idea if it’s implemented cleanly. 

Cybersecurity is still a human problem. So, your tooling should support the people, not sideline them. When deployed well, automation restores your team’s most precious resource: Attention. When deployed blindly, it becomes a liability hiding in plain sight. 

The Simulation Approach — Penetration Testing and Red Teams 

In cybersecurity, there’s a difference between knowing how a system might break — and watching it actually collapse. 

That’s why the smartest security teams don’t just build defenses. They attack their own infrastructure before anyone else can. Red teaming, ethical hacking, chaos drills and phishing simulations — these aren’t buzzwords. They are full-contact stress tests designed to mimic real-world failure before it gets a chance to go live. 

You don’t wait for a fire to check if the exits work. You run the drill. You block the hallway. You pull the alarm and see who panics. 

I see simulations as a form of institutional memory. Not just about detection speed, but about muscle memory. 

Who spots the breach first?
Who communicates it?
Who patches?
Who handles legal, press and stakeholders? 

A breach isn’t just a technical event, it’s a company-wide crisis. If you haven’t rehearsed your roles, you’ll default to chaos. 

I’ve led tabletop exercises where product, engineering and executive teams came together to walk through complex breach scenarios. A developer uploads a key to GitHub — how fast is it caught? A spoofed login page captures credentials — does the security operations center (SOC) detect lateral movement? The goal isn’t to embarrass people. It’s to stress-test coordination under pressure. 

Simulations are where you discover that your alert went to the wrong Slack channel; or that your escalation policy is dependent on someone who’s currently on vacation. But these drills aren’t just for show. They produce data: How long does it take to respond, where do communications break down and how do assumptions crumble. In fact, perhaps most importantly, how your team behaves when the script disappears. 

Growth doesn’t come from pretending failure won’t happen — it comes from making failure mundane. Too many companies run penetration tests to check a compliance box. The report gets filed. Nothing changes. These exercises are only valuable if they lead to rewiring, not just reflection. 

A good red team exercise ends with a fix, not a summary. A great one changes how your entire organization thinks about risk. Simulation doesn’t eliminate human error, but it makes sure you meet it on your own terms, not the attacker’s. 

The Inevitable Truth 

Let’s make one thing clear: Human error isn’t a bug in the system — it is the system. 

We forget; we improvise; we trust easily and we skip steps when we’re tired. In terms of security, these aren’t exceptions, they’re the default operating conditions. Pretending otherwise leads to brittle systems, unrealistic expectations and a culture of blame.  

You can’t out-policy human nature. You have to design with it in mind; or it will design the breach for you. 

I’ve spent years watching teams chase the illusion of airtight security — adding more controls, stricter processes and longer checklists. But breaches still happen. Not because the rules were bad, but because life got in the way (for instance, timelines, miscommunications, a moment of inattention and so on). 

The companies that recover fastest from breaches aren’t the ones with the most tools. They’re the ones that know how to bend without snapping.  

They have margin built into their systems.
They run chaos drills like fire alarms.
They treat every incident as feedback, not failure. 

Every red flag you miss is a gift — because next time, you won’t. 

This is what mature security looks like: 

• Detection that moves faster than exploitation.
   

• Recovery that works without heroics.
   

• Teams that speak up instead of second-guessing.
   

• Systems that treat error not as a surprise, but as a known variable. 

Blame doesn’t prevent breaches, psychological safety does. If your engineers are afraid to raise their hand when something looks off, you’ve already lost. The mission isn’t to eliminate human error — that’s fantasy. The mission is to anticipate it, simulate it and mitigate it, and build an infrastructure that doesn’t crumble when someone, inevitably, screws up.