Most analysts do the same thing: they dive, straight into the logs, straight into the tool stack, straight into whatever data is closest. No structure. No sequence. Just motion.

Motion feels productive. It is not the same as progress.

The problem is not speed. The problem is that without a framework for what to ask first, the investigation is shaped by whatever data happens to land in front of you. The first log entry anchors your thinking. The first IOC becomes the theory. And from there, you are not investigating, you are confirming.

If you read the first post in this series, you recognise that pattern. Anchoring bias meets confirmation bias, sixty seconds in, before the analyst even knows it is happening.

There is a countermeasure. It is old. It is simple. It works:

Six Questions, One Framework

Who. What. When. Where. Why. How.

The 5W+H framework has been used in journalism, military intelligence, and law enforcement for decades. It is not clever. It is not novel. That is the point. Its value is that it forces completeness before it allows depth.

When you open an investigation with the 5W+H questions, you are not solving yet. You are mapping. You are building the landscape of the problem before you pick a direction to walk.

• Who is affected? Who triggered the alert? Who owns the asset? Who else might be involved?

• What happened? What did the detection actually fire on? What is the observable behaviour, stripped of the tool’s interpretation?

• When did it start? When was it detected? Is there a gap between those two? What was happening in that gap?

• Where in the environment? Which system, which network segment, which cloud tenant? Where does this asset sit in your architecture, and what can it reach?

• Why does this matter? Why would an attacker target this? Why now? Or why might this be benign?

• How did it happen? How did the activity occur technically? How was access gained, or how was the process initiated?

None of these questions are hard. All of them are missed — routinely — when analysts skip straight to hypothesis.

The Blank Page Problem

Here is where it gets practical.

One of the biggest friction points in investigation work is the blank page. A ticket opens. The analyst stares at an empty notes field and a pile of raw telemetry. Where do you even start?

This is where automation earns its place, not as a replacement for the analyst, but as a pre-fill for the obvious.

A well-configured SOAR playbook, enrichment pipeline, or even an LLM integration can answer a significant portion of the 5W+H questions before the analyst touches the case. The factual, contextual baseline: Who is this user? What is their role? What asset is this? Where does it sit in the network? When did the alert fire, and what is the detection logic behind it? What does the raw event look like?

That pre-fill is valuable. It eliminates the blank page. It gives the analyst a starting point that is structured, not random. Instead of diving into logs with no direction, the analyst opens a case and sees a partially completed 5W+H matrix, a map with some terrain already sketched in.

This is the kind of work automation was built for. Gathering context. Correlating identifiers. Pulling asset data and user profiles. Fast, repeatable, boring. Exactly the tasks that should not consume analyst time.

But here is the part that matters more than the efficiency gain.

The Answers Are Not Settled

The pre-filled 5W+H is a starting point. It is not the investigation. Every line is a premise to question, not a fact to accept.

The moment you treat the automated answers as settled, you have swapped one blind spot for another, a page so complete it stops you from asking the questions that matter.

Think about what happens. Automation says the “Who” is a specific user. The analyst accepts that and moves on. But what if the account was compromised? Then the “Who” is not the user — it is an attacker using stolen credentials. The initial answer was technically correct (this is the account) and operationally misleading (this is not the person).

The “What” might say “suspicious login from unusual location.” That is the alert summary. But the actual “What” might be the third step in a multi-stage intrusion that started days earlier. The alert is not the event — it is the symptom that finally crossed a detection threshold.

Military intelligence analysts are trained to challenge their own assessments as rigorously as they build them. The 5W+H framework operates the same way. Each question is asked at least twice: once to establish the baseline, and again as the investigation develops to test whether the baseline still holds.

This is where you earn your value. Not in gathering the initial facts, automation handles that. In asking the second-order questions that automation cannot reach.

Who — beyond the account name, who actually performed this action? Is there evidence of shared credentials, compromised tokens, delegated access?

What — beyond the alert description, what is the full sequence of activity? What happened before and after the detection? What did the attacker do that the detection did not catch?

Why — beyond “it looked suspicious,” why would an attacker choose this path? What is the strategic value of this asset, this account, this timing? Or, what benign explanation accounts for all the evidence, not just most of it?

These are judgment questions. They require context that no enrichment pipeline carries: knowledge of the business, understanding of the environment’s normal patterns, awareness of what happened last week and what is planned for next week. The analyst brings this. The tool does not.

A Bias Check Built Into the Structure

There is a second benefit to the 5W+H framework that goes beyond investigation efficiency.

The structure itself is a bias countermeasure.

When you force yourself to answer all six questions — not just the ones that feel relevant — you are resisting the pull of confirmation bias. Your hypothesis might explain the What and the How beautifully. But can it explain the When? Does the timing actually make sense? And the Where, does the affected system fit the theory, or did you quietly ignore that the activity originated from a segment that contradicts your hypothesis?

The 5W+H questions create a completeness check. They make the gaps visible. And gaps — missing answers, questions you cannot explain — are often more diagnostic than the data you have.

The questions you cannot answer tell you more than the ones you can.

This is why the framework matters even for experienced analysts who think they do not need a checklist. Especially for experienced analysts. Experience builds pattern recognition, but it also builds assumptions. The 5W+H framework forces those assumptions into the open where they can be examined.

Combine this with a habit from earlier in this series. The deliberate pause: that moment before closure where you stop confirming and start challenging. Before you close the case, revisit each 5W+H. Has the answer changed since the investigation started? If your final “Who” is the same as your initial “Who”, are you confident because you verified it, or because you never questioned it?

The Handoff Model

So the practical model looks like this:

Layer 1 Automation: Pre-fill the 5W+H matrix with factual, contextual data. User identity, asset information, alert metadata, geolocation, network context, related recent alerts. Fast. Structured. Consistent across every case.

Layer 2 Analyst baseline review: Read the pre-fill. Your first question is not “does this look right?” Your first question is: what assumptions are embedded in these answers? What does the automation not know? What is missing? Flag anything that feels incomplete and flag anything that feels too clean.

Layer 3 Analyst deep investigation: Pursue the second-order W questions. Test whether the initial answers survive scrutiny. Build competing explanations. Look for what the automation could not see: intent, context, strategic meaning, absence of expected evidence.

Layer 4 Bias check: Before closing, walk the full 5W+H one final time. Compare your final answers to the initial pre-fill. Where they differ, you learned something. Where they match, verify that you actually confirmed them, rather than simply never challenged them.

This is not a workflow diagram for a SOAR platform. It is a thinking model. The automation handles the context gathering so the analyst can focus on the cognition. That is the division of labour that actually works.

What Comes Next

The 5W+H framework gives you a structure for the first minutes. But an investigation is more than its opening. In the next post, we will tie everything together — the bias countermeasures, the reasoning chain, the 5W+H questions — into a full investigation template. A single, practical document that carries you from alert to closure with structured thinking at every stage.

The tools will change. The thinking compounds.

Not because you are a bad analyst. Not because you lack training or tools. But because you are human, and human brains take shortcuts. Those shortcuts kept our ancestors alive when a rustling bush might be a predator. In a SOC during an active incident, those same shortcuts make you miss things.

Cognitive biases are not personal flaws. They are features of how the human brain processes information under time pressure, uncertainty, and cognitive load. In cybersecurity, we rarely talk about this. We talk about tools, detections, frameworks, and playbooks. But we almost never talk about the human operating all of it.

This is part one of a series. Todays focus: The four biases I see hit SOC analysts the hardest, with real-world examples and practical ways to counter each one.

Confirmation Bias: Seeing What You Expect to See

You are investigating a suspicious authentication alert. Early in the triage, you find one indicator matching a known APT group. Your brain locks in: this is APT activity.

From that moment, everything you see gets filtered through that lens. Log entries that support the theory. Evidence. Log entries that contradict it. Noise, probably unrelated. You stop looking for alternative explanations because you already have one that fits.

The problem is that “fits” is not the same as “correct.” While you were building your APT case, you missed the data exfiltration that started three days before the alert fired. You missed it because you were not looking for it. You were looking for confirmation.

This is confirmation bias. The tendency to search for, interpret, and remember information that supports what you already believe, while ignoring or dismissing what contradicts it.

How to counter it: Before closing any case, ask yourself one question: “What evidence would prove me wrong, and have I looked for it?” If you cannot answer that, your investigation is not finished. In my training sessions, I teach the Analysis of Competing Hypotheses method. You must generate at least two competing explanations before settling on one. If you only have one theory, you do not have an investigation. You have a confirmation exercise.

Anchoring Bias: The First Data Point Wins

The SIEM flags an alert as “Critical.” You open the ticket, and before you have looked at a single log, your brain has already decided this is serious. That severity label has become your anchor.

Now everything you investigate gets measured against that anchor. Lower-severity alerts in the same timeframe? They seem less important by comparison. You deprioritize them. But the real initial access was buried in one of those lower-severity alerts three entries earlier. You missed it because the first thing you saw shaped everything that followed.

Anchoring bias is the tendency to rely too heavily on the first piece of information you encounter. That first data point, whether it is a severity score, an alert title, a colleague’s opinion, or the first IOC you find, it disproportionately influences every judgment that follows.

How to counter it: Always ask: “What if my first data point is wrong?” Start from the raw evidence, not from labels or scores. When investigating an alert chain, deliberately examine the full sequence rather than focusing on whichever alert triggered first. One technique I use in training: ban actor names and malware names from ticket titles. The moment you write “APT29 Investigation” at the top of your ticket, every analyst who touches it is anchored before they read a single log line.

Availability Bias: Recent Experience Distorts Your Judgment

Your team spent last week responding to a ransomware incident. It was painful, visible, and everyone remembers it. This week, an alert fires showing unusual file encryption activity on a server. Your gut says ransomware. It feels obvious.

But “feels obvious” is not analysis. What you are actually experiencing is availability bias, that is the tendency to judge the likelihood of something based on how easily examples come to mind, rather than on actual base rates.

Because ransomware is fresh in your memory, your brain overestimates the probability that this new alert is also ransomware. Meanwhile, the actual cause — a backup process using encryption that was recently reconfigured — gets overlooked because you are preconditioned.

This works in the other direction too. A high-profile APT campaign hits the news, and suddenly every lateral movement alert in your environment feels like nation-state activity. The base rate for nation-state attacks against your organization has not changed. But your perception of the risk has.

How to counter it: Check base rates. What does the monitoring in your environment actually show? Use historical data, not recent memory. When you catch yourself thinking “this looks just like last week,” pause and ask: “How common is this attack type in our environment, based on data, not based on what I remember?”

Automation Bias: Trusting the Tool Over Your Own Judgment

The EDR scans the endpoint. "No malware detected." The SOAR enrichment comes back clean. The risk score says "Low."

You see all of this. Something about the alert still feels off — maybe the timing, maybe the process chain. But the tools say it is clean. So you close the ticket and move on.

That is automation bias. Not the tool auto-closing the ticket without you seeing it. You closing the ticket because the tool told you it was fine, even though your instinct said otherwise.

The analyst is still in the loop. The analyst still makes the decision. But the decision is shaped by the tool’s verdict rather than by independent analysis. The tool becomes the authority, and the analyst becomes the one who clicks “close.”

This bias is going to get worse as LLMs enter the analyst workflow. An AI-generated investigation summary sounds confident and well-structured even when it is wrong. If you do not have the skills to critically evaluate that output, you have a bigger problem than alert fatigue.

How to counter it: Trust but verify. Build a habit of spot-checking automated verdicts. When a tool gives you a clean bill of health, ask yourself: “What would I decide if the tool did not exist?” If you cannot answer that, you are not augmenting your analysis with automation , you are replacing your analysis with automation.

What’s Next

These four biases are not the full picture. They are the ones I see most often in SOC environments. Knowing they exist is the first step. But awareness alone does not fix the problem, you need practical tools to fight them in real time.

In the next article, I will cover the W questions that structure your thinking from the first minute of an investigation. Continuing we build the full investigation template that ties it all together.

Remember: Biases are not something you fix once. They are something you manage every day.

Subscribe now

We took their offensive frameworks. We took their defensive models. We took their vocabulary.

But I realized we skipped the one thing that makes all of it work: how they train their analysts to think.

Two weeks ago I posted five critical thinking habits for security analysts on LinkedIn. The response surprised me, not just the engagement, but the conversations it started. Team leads sharing what they struggle to teach. Analysts admitting they’d never been trained to think, only to follow playbooks. Career changers asking where to even begin.

It confirmed something I’ve believed for a long time: cybersecurity has a thinking problem, not a tools problem.

So I want to go deeper. Not just five habits, but the actual frameworks behind them, where they come from, why they work, and how you can apply them starting today.

The intelligence community figured this out decades ago

Here’s something most security professionals don’t know: the military and intelligence community have been formally training analysts in critical thinking for over 30 years. They had to. When a wrong assessment can cost lives, you can’t afford analysts who only follow procedures.

The CIA published “Psychology of Intelligence Analysis”, a book specifically about the cognitive biases that cause analysts to reach wrong conclusions. Not technical biases. Human biases. Confirmation bias. Anchoring. Mirror imaging. The same traps that cause a SOC analyst to close a ticket too fast, because the evidence looks like something they’ve seen before.

David T. Moore, writing for the National Defense Intelligence College, published “Critical Thinking and Intelligence Analysis” which laid out a core principle: analysts must simultaneously build a logical reasoning chain AND objectively challenge their own logic. Not one or the other. Both at the same time.

This isn’t abstract philosophy. This is operational tradecraft. And it translates directly to cybersecurity.

Applying this in the SOC

Let me make this concrete. You get an alert: a user account is authenticating from two geographic locations within an impossible travel timeframe.

An analyst following a playbook checks the VPN logs, confirms whether the user has a travel ticket, and either escalates or closes.

An analyst using critical thinking does something different:

Purpose: what am I actually trying to determine? Not “is this a true positive” but “is this account compromised?”

Assumptions: I’m assuming the geolocation data is accurate. I’m assuming the user only has one device. Am I sure about both?

Information: what data do I have? What data am I missing? Are there other signals I should correlate — endpoint telemetry, email activity, privilege changes?

Inferences: if this account IS compromised, what would the attacker do next? What evidence would I expect to see? If it ISN’T compromised, what benign explanations exist and what evidence supports them?

Point of view: am I looking at this only from a defensive perspective? If I were the attacker, would this alert even be the real concern, or would it be a distraction?

This is the difference between an alert handler and an analyst.

Why this matters more now than ever

LLMs are becoming part of the analyst workflow. They’re impressive tools. But they are pattern-matching engines that generate the most probable answer, not necessarily the correct one. They sound authoritative even when they’re wrong.

If you don’t have the critical thinking skills to evaluate an LLM’s output with the same rigor you’d evaluate a suspicious process execution, you have a problem. AI amplifies the analyst, but only if the analyst has the judgment to question its conclusions.

The intelligence community understood this about their analysts decades ago. Cybersecurity is only now catching up.

Where to start

You don’t need a certification or a master’s degree to start thinking more critically. But if you want structured paths, the best part is that these foundational texts are available for free.

But the real starting point is simpler than any book:

The next time you investigate an alert, PAUSE. Ask yourself what you’re assuming. Consider the opposite of your first conclusion. Explain your reasoning out loud. Check whether your thinking would hold up if someone challenged every step.

That pause — that moment of deliberate, structured thinking — is what separates good analysts from the ones who catch what everyone else missed.

Tools change every year. Thinking compounds forever.

Further reading:

• Psychology of Intelligence Analysis — Richards J. Heuer Jr., CIA (free PDF):https://www.cia.gov/resources/csi/static/Pyschology-of-Intelligence-Analysis.pdf

• Critical Thinking and Intelligence Analysis — David T. Moore, National Defense Intelligence College (free PDF):https://apps.dtic.mil/sti/tr/pdf/ADA481702.pdf

I’ve spent nearly two decades in cybersecurity. Hands on networks before the cloud existed. Protecting systems where a breach doesn’t just cost data, it costs safety.

In that time, I’ve trained analysts and teams across red team, blue team, and everything in between. And one pattern keeps showing up.

The people who perform best — in exercises, during incidents, when troubleshooting at 3am — aren’t the ones with the longest cert list or the latest tools. They’re the ones who think differently.

They question before they escalate. They sit with discomfort instead of closing the ticket. They understand the why, not just the what.

That’s what this newsletter is about.

The Analyst Mind is where I share what I’ve learned from years of training, incident response, detection engineering, troubleshooting, and building secure infrastructure — not as a tool guide, but as a thinking guide. Whether you’re a SOC analyst, a sysadmin, a network engineer, or somewhere in between, the mindset is what makes the difference.

What you can expect here:

Deeper dives into the topics I post about on LinkedIn — critical thinking, offensive skills for defenders, AI in security operations, threat hunting, and incident preparedness.

Frameworks and mental models that make you better at your craft — not because you memorize more, but because you reason better.

Behind-the-scenes lessons from real training exercises, tabletop scenarios, and operational troubleshooting — what worked, what failed, and why.

My honest take on where this industry is heading — especially as AI reshapes how we work.

I started this because I believe our industry doesn’t have a tools problem. It has a thinking problem. And the people who solve that — whether they sit in a SOC, a server room, or a red team engagement — will be the ones who define the next era of security.

If that resonates, subscribe. I publish every two weeks, and I keep it practical.

Welcome to The Analyst Mind.