The Zero-Incident Lie
I've been in cybersecurity for over 20 years. I've hired hundreds of engineers. And I can tell you one universal truth:
If your security team reports zero incidents, they're either phenomenally lucky, or they're lying.
More often than not, it's the second one.
Why? Because in most organizations, admitting failure is career suicide. Incidents trigger blame. Blame triggers fear. Fear triggers cover-ups. And cover-ups are where the real disasters live.
The best security teams I've worked with—from Link11's own operations to Fortune 500 partners—do the exact opposite. They celebrate failure. They turn every incident into a team training session, a documentation update, and a process improvement.
Here's how you build that culture without letting chaos reign.
The Blameless Post-Mortem: Not a Feel-Good Exercise
The term "blameless post-mortem" gets thrown around in DevOps circles like it's some kind of kumbaya ritual. It's not. It's a strategic discipline.
A blameless post-mortem doesn't mean no one is accountable. It means you focus on the system that allowed the failure, not the human who triggered it.
Example: An engineer accidentally deploys a bad firewall rule that takes down customer traffic for 12 minutes. Do you fire the engineer?
No. You ask:
- Why was a single engineer able to push this rule without review?
- Why didn't our staging environment catch it?
- Why did it take 12 minutes to detect?
- Why didn't our rollback automation trigger?
That's a blameless post-mortem. It surfaces five different process improvements from a single mistake.
The engineer who made the mistake? They now have the deepest understanding of that failure mode. They're not a liability—they're your best asset for preventing it next time.
The "Public Incident Log" Strategy
At Link11, we maintain an internal incident log that's visible to the entire engineering org. Every outage, every breach attempt, every configuration mistake—it's all documented.
The visibility does two things:
- It normalizes failure. When everyone can see that incidents happen to everyone, the stigma disappears.
- It creates a living knowledge base. New engineers can read the history and learn from 20 years of mistakes in their first month.
Some companies go even further and publish their post-mortems externally. Cloudflare (yes, a competitor, but credit where it's due) does this brilliantly. Their transparency builds trust with customers and sets a standard for the industry.
You don't have to go that far. But internal transparency is non-negotiable.
The "Chaos Day" Drill
If you're not actively breaking things, you're not prepared for when things break on their own.
Once a quarter, we run a "Chaos Day" at Link11. We intentionally simulate failure scenarios:
- Kill a critical database node
- Simulate a BGP hijack
- Revoke API keys mid-traffic
- Inject malicious payloads into our scrubbing layer
The goal isn't to see if we survive (we know we will—most of the time). The goal is to measure how long it takes and how much manual intervention is required.
Every Chaos Day surfaces at least three things we didn't automate properly. And those three things become the roadmap for the next sprint.
Metrics That Encourage Honesty
If you measure your security team on "number of incidents," you're incentivizing them to hide problems.
Instead, measure:
- Mean Time to Detection (MTTD): How fast do we notice something is wrong?
- Mean Time to Resolution (MTTR): How fast do we fix it?
- Post-Mortem Completion Rate: Did we document what happened and why?
- Process Improvements Implemented: Did we actually fix the root cause, or just the symptom?
These metrics reward speed of recovery and learning, not the illusion of perfection.
The "First Failure Bonus"
This one sounds insane, but hear me out.
At one point, we experimented with a "first failure bonus"—a small financial reward for the first person to discover and report a new class of vulnerability or failure mode.
The idea was simple: we want people hunting for problems, not hiding them.
Did it work? Mixed results. Some engineers loved it. Others felt it was gamifying something serious. We eventually retired it, but the spirit remains: finding problems early is a win, not a penalty.
The Red Flag: When Failure Becomes Recklessness
Let me be clear: celebrating failure doesn't mean tolerating negligence.
If someone repeatedly makes the same mistake, or ignores documented procedures without cause, that's not a learning opportunity—that's a performance issue.
The difference:
- Failure: You tried something reasonable, it didn't work, you learned.
- Recklessness: You ignored known risks, skipped safeguards, or didn't care.
A blameless culture isn't a free pass. It's a framework for distinguishing between the two.
Why This Matters for Leadership
If you're a CTO, CISO, or CEO, your team's relationship with failure is a mirror of your own.
If you publicly criticize an engineer who caused an outage, you've just trained the entire org to hide mistakes. If you respond with curiosity ("What did we learn? How do we prevent this?"), you've trained them to surface problems early.
I've made this mistake. Early in Link11's history, I got visibly frustrated during an incident debrief. The engineer involved withdrew. The team noticed. It took months to rebuild that psychological safety.
Now, I make it a point to thank the person who reports or triggers an incident. Not sarcastically—genuinely. Because they just gave the entire company a free lesson.
The Bottom Line
Security is not about achieving perfection. It's about shortening the feedback loop between failure and learning.
The teams that win in the long run aren't the ones with zero incidents. They're the ones that:
- Document failures openly
- Fix root causes, not symptoms
- Build processes that prevent repeat mistakes
- Create an environment where reporting a problem is seen as valuable, not career-limiting
If you never have an incident, you're not secure. You're just uninformed.
Build a team that celebrates failure. Not because failure is good—but because learning from it is the only path to resilience.
Follow the journey
Subscribe to Lynk for daily insights on AI strategy, cybersecurity, and building in the age of AI.
Subscribe →