Skip to content

Don't Let Confirmation Bias Derail Incident Response

A construction site in Texas offers a powerful reminder that the biggest mistake in incident response isn't missing an attack, but letting confirmation bias convince you one exists before the evidence does.

From the latest episode of CYBR.Signal. Full Episode:

Confirmation Bias in Cybersecurity Can Cause Real Damage
Michael Farnum explains how confirmation bias can turn suspicious activity into bad security decisions.

I was recently driving through Tomball, Texas when I came across a construction site that had been completely shut down. Fencing surrounded the property. Police tape stretched across the entrance. At first glance, it looked like a crime scene.

It wasn't.

Workers had been demolishing an old building when they uncovered what appeared to be a possible gravesite. Because Tomball is one of the older communities in Texas, officials immediately halted construction while experts investigated whether the site contained a historic cemetery.

That response made perfect sense.

If there's even a possibility that you're disturbing human remains or an important historical site, you stop. You bring in archaeologists. You involve historians. You figure out exactly what you're dealing with before anyone resumes work.

Standing there, though, I couldn't help thinking about how often we make the exact opposite mistake in cybersecurity.

We see something that looks suspicious, assume the worst, and immediately start treating possibility as certainty.

That's a dangerous place to operate.

A PowerShell command shows up in your environment. Maybe it's malicious. Maybe it's a perfectly legitimate administrative task. A previously unknown server appears on the network. It could be unauthorized. It could also be a system that another team deployed without your knowledge.

The point isn't that these things are safe.

The point is that they require investigation before they require assumptions.

Too often, confirmation bias takes over. We see one indicator that fits the story already forming in our heads, and suddenly every piece of evidence reinforces the conclusion we've already decided is true. Instead of asking, "What is this?" we start asking, "How do I prove this is an incident?"

Those are two very different questions.

Unlike the construction site in Tomball, most organizations can't afford to shut everything down every time something looks suspicious. Security exists to reduce risk, but businesses still have to operate. If your response to every uncertain event is to pull the plug, you'll quickly become the reason work stops instead of the team that enables it to continue safely.

That doesn't mean you ignore warning signs. Quite the opposite.

It means you investigate them with discipline.

The city didn't simply restart construction because it was inconvenient to wait. They paused, brought in qualified experts, and followed a process designed to gather facts before making a decision. Whether the final answer is "yes, this is a cemetery" or "no, construction can resume," the important part is that they didn't let assumptions determine the outcome.

That's exactly how incident response should work.

Bring in the right people. Collect evidence. Understand the context before you make decisions that could impact the business.

Context is the part we often overlook.

There are situations where shutting everything down absolutely is the right decision. If you're operating critical infrastructure, public safety systems, or environments where human safety or national security is involved, the business case may take a back seat. Regulations may require immediate action. The potential consequences are simply too great to take chances.

But that's not every organization.

For many businesses, security decisions require balancing operational continuity with risk reduction. Sometimes the safest response isn't to stop everything. Sometimes it's to isolate a system, increase monitoring, collect more data, or investigate before taking broader action.

That's why policies and playbooks matter so much.

You don't want to invent your response strategy in the middle of an incident. The decision-making framework should already exist. Your organization should understand what constitutes a critical event, when business operations should continue, when systems should be isolated, and when a full shutdown is warranted.

If those conversations happen before an incident, your response becomes deliberate instead of emotional.

The construction site in Tomball has now been sitting idle for weeks while investigators determine exactly what was found beneath the surface. That's the appropriate response because the stakes justify the delay.

Cybersecurity isn't always that simple.

Sometimes the right answer is to act immediately. Sometimes it's to slow down just enough to separate evidence from assumptions. Knowing the difference is what separates mature security programs from reactive ones.

Every alert doesn't deserve panic.

Every anomaly isn't automatically an attack.

And every suspicious event deserves the same thing that construction site received: a thoughtful investigation before conclusions become decisions.

If we can avoid letting confirmation bias drive our incident response, we'll make better security decisions, better business decisions, and ultimately build organizations that are both more resilient and more trustworthy.

HOU.SEC.CON CTA

Latest