The detections get faster. The dashboards get denser. And every year, analysts still miss things. Not because a tool failed. Because the thinking did.

We borrowed the words

Look at the language the industry runs on. Almost none of it is ours. War games come from Prussian Kriegsspiel. Triage from Napoleonic battlefield medicine. Kill chain from US Air Force targeting doctrine. OPSEC from a Vietnam-era operation. OSINT, red team, blue team, TTPs. We took the military's operational vocabulary wholesale, and we took some of its frameworks with it: the kill chain, the threat models, the exercises.

There is one thing we did not take. The discipline underneath the words: how their analysts learned to think.

The intelligence community spent generations on exactly that problem, why smart analysts make bad calls, and what to do about it. They wrote it down. Richards Heuer’s Psychology of Intelligence Analysis came out of the CIA in 1999. David T. Moore’s Critical Thinking and Intelligence Analysis came out of the National Defense Intelligence College. Both are public. Both are free.

We borrowed the words. We did not borrow the discipline. The gap is not in the stack. It is in how we read what the stack shows us.

Monday morning

It is Monday morning. The queue is full and it is not getting shorter.

You open the first alert. EDR-2026-04822. Severity medium. A developer workstation on the engineering subnet, the user signed in, business hours. Three commands in a single burst:

whoami
net group "Domain Admins" /domain
nltest /domain_trusts

Parent process is the interactive shell. No outbound traffic before or after. The EDR verdict is low confidence: recon-like, but probably an admin script or someone poking around.

You have seen this five times this month. Active session, known user, normal hours, nothing following it. It looks routine. Your cursor is already on the close button.

Routine false positive at thirty seconds or a missed breach uncovered in thirty days.

Here is the same alert, walked through one investigation template. Five sections, the telemetry you were about to dismiss.

Section 1 - Intake

Before you read the alert as a story, you fill in six cells. Five W's and an H, borrowed from journalism and formalized by police and intelligence services.

The cell that carries the weight is WHO. Not “the developer.” A session originating from the developer’s workstation. Those are two different things. The first phrasing smuggles in a trusted human and quietly decides which evidence will feel relevant later. The second leaves the question open. That single word is where anchoring loses its grip.

The rest fall into place once the framing is honest. WHAT is domain reconnaissance, the textbook shape of account and trust enumeration. WHERE is an engineering workstation, a tier that has no business mapping Domain Admins. WHY has no plausible answer for a developer mid-sprint. HOW looks like a human at a keyboard, which is a fact to hold, not a conclusion to trust.

Section 2 - Hypotheses

The fastest way to confirm what you already believe is to carry a hypothesis.

This is Analysis of Competing Hypotheses, Heuer’s method. The rule is at least two, better three. H1, a developer with a reason. H2, a real attacker operating through the live session. H3, an authorised red team that is functionally identical to H2 in the telemetry and completely different in the response it demands.

The third hypothesis is the one most queues never write down, and it is the one that decides whether the next hour is incident response or a phone call. Rank the three by the evidence that would disprove them, not the evidence that would confirm them. One hypothesis is not an investigation. It is a guess with paperwork.

Section 3 - Evidence

Evidence has two moves, and the order matters. First you assemble. Then you weigh.

Assembling means a multi-source timeline in UTC and a typed list of indicators. On this alert the timeline is short and the indicator list is thin. No hashes. No command-and-control. No file written to disk. That emptiness is not nothing. The absence of atomic indicators is itself a finding: this looks like hands on a keyboard, not malware on a host. A sixty-second gap with no outbound traffic is not innocence. Attackers and red teams both pause between recon and the next stage.

Then you weigh. Every piece of evidence carries a rating.

The Admiralty Code is a NATO standard, two characters: a letter for how reliable the source is and a number for how credible the information is. Most analysts have never seen it, and it is the cleanest defence against confirmation bias I know.

Rate the case. The user says they did not run those commands. That is a fairly reliable person making an unverified claim about one specific session: C3, not A1. The session telemetry shows the account logged in, which says the session is open, not that the human is at the keyboard: B2. The network silence is definitive log data supporting a doubtful inference: A4. Three pieces of evidence, and not one of them rates above C3 toward the benign story. The hypothesis you wanted to pick is not earning its weight. The point of the rating is that it makes you say so out loud.

Section 4 - Adversarial Review

The brain that built the bias cannot detect it alone. So you attack your own analysis before someone else does.

Start with the bias checklist: keep the actor’s name out of the ticket until evidence supports it, check the base rate for your environment, ask what you would conclude without the tool. Then put the story in front of a devil’s advocate, someone whose only job is to break it. That can be a team member, an LLM, or you after a short break with fresh eyes.

One move decides this case. Deconfliction rules out friendly fire. A single question to the security manager: is anyone authorized running offensive testing in this environment right now. The answer sorts an incident from a learning conversation, and skipping it is how teams either burn response ressources on their own red team or close on a real intruder. The pre-mortem comes last, a final stress-test: assume the analysis was wrong and write what you missed before you commit.

Section 5 - Decision

Analysis that does not move is a diary entry. The decision is a loop, not a checkbox.

John Boyd built the OODA loop for fighter pilots deciding under fire. Observe pulls the full process tree and prior host activity. Orient places it against the three hypotheses: H2 and H3 both hold, H1 does not. Decide is not "close." It is escalate to a hunt and run deconfliction in parallel. Act executes both. Then the loop turns, because the act produced new data: the hunt finds two more workstations running the same recon pattern inside forty-eight hours. One event was an anomaly. Three is a campaign.

The reveal

Deconfliction comes back. There was an authorized, no-notice red team running that month. Initial access was a spearphish to a finance employee two weeks earlier. The developer workstation was the third stop in their lateral movement and they were heading for the Tier Zero tier.

Same telemetry as a real attacker, same urgency and same TTPs.

Different attribution:

Closed as a false positive, this is a missed breach. The red team writes a friendly debrief. A real adversary deploys ransomware to your environment.

Same analyst, Same tooling but different discipline. Eight minutes from the alert you could have closed to an escalation. The only thing that changed was the order of your thinking.

The full walk is one page

Five sections, one artifact. The filled template is the handover: the next analyst inherits your reasoning, not just your verdict.

Triage is not investigation

Everything above is an investigation. Most of your day may not.

When the queue is full and you have minutes per alert, you are triaging, not investigating. Triage is the decision of which alerts earn the full template and which do not. It is a different job, and it has its own version of the discipline.

Three questions. What is my primary hypothesis right now. How would I rate my strongest piece of evidence on Admiralty. What single thing would change my mind. A couple minutes per alert, run on the queue, not on a single case. Not every alert is a case. Triage is how you find the one that is.

The work is already done

The intelligence community already figured out why good analysts make bad calls. They wrote it up and gave it away.

If you have followed this series, you have been collecting the pieces. The four biases. The two systems. The W + H questions. Each post was one tool. This is the piece where they live together in a single page you can run on a real shift.

We do not have to redo it. We borrowed the words. Now borrow the discipline.

What is on the horizon

The next version of this problem is already coming. AI writes the first-draft triage now, fluent and confident and sometimes wrong, the job is shifting from producing the analysis to judging the machine's analysis. An LLM verdict starts unverified, the same as any other source. The discipline that rates a person's claim is the discipline that rates the model's.

Subscribe now

Appendix: The Investigation Template

Copy this into your notes app, your ticketing system, or a markdown file. It is a living document. Fill it as the investigation moves.

# Investigation Template

*Companion artefact to "Why Your Best Detection Tool Is Critical Thinking"*

---

## Case Header

- **TLP Classification:** [ ] RED  [ ] AMBER+STRICT  [ ] AMBER  [ ] GREEN  [ ] CLEAR
- **Case ID:**
- **Analyst:**
- **Opened (UTC):**
- **Status:** [ ] Open  [ ] Escalated  [ ] Closed

---

## Timeline (UTC, Multi-Source)

| Timestamp (UTC) | Source | Event Description |
|------------------|--------|-------------------|
| YYYY-MM-DD HH:MM | | |
| YYYY-MM-DD HH:MM | | |
| YYYY-MM-DD HH:MM | | |
| YYYY-MM-DD HH:MM | | |

> Mark timezone differences explicitly. Look for gaps. Hours with no log data indicate often missing evidence, not absence of activity.

---

## Section 1 - Intake (5W+H)

*Goal: structured first read of the alert before pattern-matching kicks in.*

| Question | Response |
|----------|----------|
| **WHO**  | Victim(s), suspected actor(s), beneficiaries |
| **WHAT** | Exactly what happened, in one sentence |
| **WHEN** | First observed AND earliest indicator (UTC) |
| **WHERE**| Systems, networks, geography |
| **WHY**  | Likely motive: ransom, espionage, sabotage, profit |
| **HOW**  | Initial access vector and kill-chain stage so far |

---

## Section 2 - Hypotheses (ACH + TTPs)

*Goal: force at least two hypotheses. One hypothesis is not an investigation.*

### Hypothesis 1 (Primary)
- **Description:**
- **Confidence:** [ ] HIGH (70-100%)  [ ] MEDIUM (40-70%)  [ ] LOW (1-40%)
- **TTPs to hunt for:**
- **Disproving evidence would be:**

### Hypothesis 2 (Alternative)
- **Description:**
- **Confidence:** [ ] HIGH  [ ] MEDIUM  [ ] LOW
- **TTPs to hunt for:**
- **Disproving evidence would be:**

### Hypothesis 3 (Optional: Insider / Red Team / Supply Chain / Benign)
- **Description:**
- **Confidence:** [ ] HIGH  [ ] MEDIUM  [ ] LOW
- **TTPs to hunt for:**
- **Disproving evidence would be:**

> Rank hypotheses by which has the most disconfirming evidence, not the most confirming evidence. Heuer, Analysis of Competing Hypotheses.

---

## Section 3 - Evidence (Admiralty Scored)

*Goal: every piece of evidence carries a credibility rating. Unrated evidence gets a free pass it has not earned.*

| Type | Indicator | Admiralty | TTPs | Notes |
|------|-----------|-----------|------|-------|
| Hash | | | | |
| IP | | | | |
| Domain | | | | |
| URL | | | | |
| File Path | | | | |
| Other | | | | |

**Admiralty Code reference:**
- **Source reliability (A-F):** A = Completely reliable, B = Usually reliable, C = Fairly reliable, D = Not usually reliable, E = Unreliable, F = Cannot be judged
- **Information credibility (1-6):** 1 = Confirmed by other sources, 2 = Probably true, 3 = Possibly true, 4 = Doubtful, 5 = Improbable, 6 = Cannot be judged

> Example: B2 = Usually reliable source, probably true. LLM output on framed indicators starts at F6 until verified by independent evidence.

---

## Section 4 - Adversarial Review

*Goal: actively try to break your own analysis before someone else does.*

### Bias Checklist

- [ ] **Anchoring defence:** Actor / malware name banned from ticket until evidence supports it
- [ ] **Tool verdicts manually verified:** What would I conclude without the tool?
- [ ] **Base-rate check:** Is this common in OUR environment?
- [ ] **Null hypothesis considered:** Could this be benign?

### Devil's Advocate

> Someone whose only job is to break the primary hypothesis. Not for approval, for disagreement. It can be a team member, an LLM, or yourself after a short break.

**Who or what challenged it:**

### Information Gaps

- [ ] Missing log sources?
- [ ] Unchecked systems?
- [ ] Unverified IOCs?
- [ ] Memory not captured?
- [ ] **What single piece of evidence would change your primary hypothesis?**
- [ ] Other:

### Pre-mortem

> Imagine it is six months from now and this analysis was wrong. What did we miss? Write the postmortem before the incident.

**Response:**

---

## Section 5 - Decision (OODA)

*Goal: turn analysis into action and feed the result back into analysis. The loop runs until the case closes.*

| Phase | Question | Response |
|---|---|---|
| **OBSERVE** | What raw data is in front of you right now? | |
| **ORIENT** | What does it mean given your context and current hypotheses? | |
| **DECIDE** | Contain, escalate, investigate further, close? | |
| **ACT** | What did you execute, with what authority, with what outcome? | |

> Every action produces new data. Feed it back to OBSERVE. The loop runs continuously until the case is closed and handed over.

### Under-pressure version (5-minute triage)

When you do not have time for the full template, you are triaging, not investigating. The OODA loop collapses to three questions:

1. **What is my primary hypothesis right now?**
2. **How would I rate the strongest evidence on Admiralty?**
3. **What single thing would change my mind?**

Decide. Act. Loop.

---

## Overall Case Confidence

**Confidence in hypothesis:** [ ] HIGH (70-100%)  [ ] MEDIUM (40-70%)  [ ] LOW (1-40%)

**Justification (2-3 sentences):**
- What evidence supports this confidence level?
- What evidence still has gaps?
- Which assumption, if wrong, would drop your confidence by one level?

---

**Analyst:** ___________________  **Date:** ___________________  **Case ID:** ___________________

> The filled template IS the handover. The next analyst inherits your thinking, not just your conclusions. Write it so they can pick up the case without asking you a question.

Thirty alerts are already closed. The dashboard is calm. You can see the finish line. The handover meeting is twenty minutes away, and for the first time today, the queue is almost empty.

One last incident pops.

You open it. It looks routine. The kind of alert you have seen a hundred times. Same pattern, same source, same shape. You scan the evidence, run two quick checks, and close it. Clean.

You hand over. The incoming analyst sees a green dashboard. You log off, and for the first time in eight hours, your shoulders drop.

It feels good.

The Unease

Three hours later, you are eating dinner, and the thought arrives uninvited.

You cannot name what. There is no smoking gun in your memory, no specific detail your mind is flagging. Just a low background hum of unease, sitting under everything else, refusing to leave.

You try to dismiss it. The ticket was routine. You have closed a hundred like it. The dashboard was green.

The hum gets louder overnight.

The next morning, before your first coffee, you pull the ticket up again. You read it properly this time, line by line, not pattern-matching, not skimming. And whether or not you find anything you missed, one thing is now clear.

You closed a ticket yesterday on a verdict you had never actually tested.

Two Systems

What happened in those two moments, the close at the end of shift and the unease three hours later, is the cleanest possible illustration of a framework Daniel Kahneman won a Nobel Prize for naming. In his book Thinking, Fast and Slow, he describes two distinct systems running inside every human mind.

System 1 is fast. It is automatic. It recognises patterns, completes sentences, drives your car on a road you know. It is low-effort and almost always on. It is how you closed the ticket in ninety seconds at the end of shift.

System 2 is slow. It is deliberate. It is the system you use to multiply two three-digit numbers, to read a sentence with care, to reconstruct a chain of reasoning. It is high-effort, and you cannot run it for long without depleting yourself. It is the system that arrived three hours later, after dinner, when the noise of the day had subsided and your mind finally had the bandwidth to revisit what your fast brain had already disposed of.

System 2 did not arrive too slowly because something was wrong with you. It arrived too slowly because the SOC, by design, runs on System 1.

System 1 Is Not the Problem

This is the first thing to get right, because the rest of the article depends on it.

System 1 is not the enemy. It is the only reason you can do this job. If you ran every alert through full deliberate reasoning, you would close four tickets a shift instead of forty. You would burn out by month three. The analysts who have lasted in this work for ten or twenty years are not the ones who suppress their fast brain. They are the ones who have trained it on enough cases that its pattern-matching is sharp.

The problem is not that you used System 1 at the end of shift. The problem is that nothing in the room told you that this particular ticket was one where you needed to switch. Not the tooling. Not the workflow. Not the dashboard going green.

That is the analyst’s job. Not to run on System 2 always. That is impossible. Not to abandon System 1. That is suicidal at SOC volumes. The job is to read the evidence in front of you, including the evidence of your own thinking, and recognise when the fast version of the answer is going to be wrong.

The clearest signal that System 2 needs to take over is the one we covered in the last post. The moment you notice you are running into a bias, your fast brain is producing exactly the kind of cheap answer it evolved to produce, and you are about to commit to it. Confirmation pulls you toward the easy hypothesis. Anchoring fixes your reading to the alert label. Availability nudges you toward last week’s case. Automation hands you a verdict you never checked. Each one is a flag. Each one is the switch.

Five Triggers That Should Force the Switch

You will not catch every System 1 close in real time. Nobody does. But there are five conditions where you can install a small, repeatable habit of pausing before you commit.

One. You notice you are matching the pattern, not reading the evidence. This is the bias signal. The moment you find yourself thinking I have seen this before before you have actually looked at the data, you are on confirmation-and-anchoring autopilot. Stop and read the ticket as if you have never seen it.

Two. End of shift, or cognitive depletion. The scenario at the top of this article is not rare. It is the most common single failure mode in SOC work. Your last five tickets of a long shift deserve more scrutiny than your first five, not less. The dopamine of a clean dashboard is not evidence.

Three. An inherited verdict. A handover, a peer, or a previous shift hands you a conclusion. Looks like a false positive.We already cleared this. Your System 1 will accept the verdict and start working downstream of it. Rebuild the reasoning from raw evidence, or you are not investigating. You are inheriting.

Four. Conflicting evidence inside the same ticket. When two data points disagree and your brain quietly resolves the conflict in favour of the more familiar one, that resolution is System 1 erasing inconvenient information. Surface the conflict explicitly. Write it down. Do not let it dissolve.

Five. A tool or AI verdict that feels right too easily. Automation bias is System 1 outsourced. When a SIEM rule, an EDR verdict, or an LLM-generated summary lines up with your first instinct, you are receiving two System 1 outputs reinforcing each other. That is not corroboration. That is correlated error. Ask what you would have decided if the tool had said nothing.

Why the Unease Worked. Signal and Noise.

Now back to the dinner-table moment.

The unease three hours later was not magic. It was not intuition in the mystical sense. It was a signal.

Somewhere in the ticket you closed, there was a detail that did not fit the pattern your fast brain matched it to. System 1 noticed it. System 1 notices almost everything. But it did not flag it loudly enough to interrupt the close. During the shift, that signal was buried under the noise of thirty other alerts, the rhythm of the queue, and the dopamine of a clean handover.

After the shift, the noise floor dropped. The other thirty tickets were gone. The queue was someone else’s problem. And the signal that had been buried all afternoon finally rose above the noise.

This is the same signal-versus-noise problem you already understand from detection engineering, applied now to your own cognition. The goal of System 2 is not to manufacture suspicion. It is to lower the noise floor of your own thinking enough that the real signal, the detail that did not fit, has a chance to be heard before the close, not three hours after it.

The five triggers are how you do that without burning yourself out trying to be slow all the time. They are not a discipline of constant vigilance. They are a small set of conditions in which you have agreed, in advance, that the fast version of the answer is not good enough.

What Comes Next

If this post has done its job, the next time you reach the end of a long shift and one last ticket lands, you will hear a different question in your head. Not can I close this and go home, but which system is about to close this ticket, and is it the right one for the job.

This piece is part of the Analyst Framework series on The Analyst Mind. The series builds the cognitive toolkit a SOC analyst actually needs, one principle at a time. The biases that distort fast thinking. The questions that structure an investigation. The competing hypotheses that test your reasoning. The deliberate pause that catches what you almost missed. The moments where AI augmentation quietly becomes correlated error. Stay tuned.

You have pulled authentication logs. You have pulled endpoint telemetry. You have checked the user directory, cross-referenced the asset database, queried the firewall. Your notes field is full. Your tabs are full. Your coffee is cold.

And if someone asked you right now - what do you think happened? - you would struggle to answer.

That is the moment most analysts mistake for investigation. It is not. It is browsing.

Evidence Without a Theory Is Just Data

Here is the uncomfortable truth about most SOC work. Analysts believe their job is to find evidence. To pull logs. To correlate indicators. To chase down the unusual thing until it resolves into something nameable.

That is not the job.

The job is to build and kill theories. The evidence only matters in relation to the theories it supports or contradicts. Without a hypothesis, you are not investigating, you are scrolling through data hoping the answer will surface itself. It rarely does. And when it does, you cannot explain why.

If you cannot state what you think happened in a single clear sentence, you are not investigating yet. You are preparing to investigate.

The First Hypothesis Is a Trap

So you force yourself to state a theory.

“The account was compromised via stolen credentials from a phishing email earlier this week.”

Now you have a hypothesis. And the moment you have one, something dangerous happens.

Your brain starts working for it, not against it. Every log line that fits the theory becomes “evidence.” Every log line that doesn’t fit becomes “noise.” You start searching for confirmation, and confirmation is cheap. If you only have one theory, every piece of matching data feels like progress. But you are no longer investigating. You are assembling a case for a verdict you have already reached.

This is the pattern the first post in this series named as confirmation bias. It hits every analyst, every day. The only reliable countermeasure is structural: refuse to work with a single hypothesis.

If you have one theory, you do not have an investigation. You have a confirmation exercise with extra steps.

The Minimum Is Two

The rule is simple. You need at least two competing hypotheses before you touch the evidence again.

For any suspicious authentication alert, the starting pair might be:

• Hypothesis A: The account is compromised. Credentials were stolen and are being used by an external actor.

• Hypothesis B: The account is legitimate. The unusual pattern has a benign explanation — VPN routing, a new device, travel the user forgot to mention.

That is not enough. You push for a third.

• Hypothesis C: Misconfiguration. A recent change to the authentication system is producing false signals.

And if you are serious, a fourth.

• Hypothesis D: Insider activity. The user themselves is doing something they should not, using their own valid credentials.

Each hypothesis changes what evidence is meaningful. Under Hypothesis A, the absence of VPN logs is damning. Under Hypothesis B, the absence of VPN logs is trivial, maybe the user is on their home network. The same data carries different weight depending on which theory you are testing.

This is the reason Analysis of Competing Hypotheses from intelligence tradecraft works. It forces you to look for the absence of expected evidence, not just the presence of confirming evidence. The hypothesis with the least contradicting evidence is the strongest. Not the one with the most confirming evidence. Confirmation is cheap. Disconfirmation is diagnostic.

Where the Augmented Analyst Wins

This is the place in modern SOC work where AI earns its keep, if the analyst knows how to use it.

A well-prompted language model can do two things with hypotheses that no enrichment pipeline can do.

1. It can pre-fill the hypothesis space. You describe the observed behaviour and ask for five plausible explanations. The model returns a list. Some are obvious. Some are things you would have reached on your own. And sometimes, not always, but often enough to matter, one or two are paths you would not have considered. Not because you lack experience, but because you are thinking inside the constraints of your current case. The model is not. That breadth is the value.

2. It can challenge the hypothesis you already hold. You hand it your theory and ask: what evidence would prove this wrong? What alternative explanations fit the same facts? Where does this reasoning break down? Used this way, the model is a structured devil’s advocate — the role intelligence analysts have assigned to senior reviewers for decades, now available in real time.

Neither of these is a replacement for analyst judgment. Both are amplifiers.

The augmented analyst is not an analyst who defers to the model. The augmented analyst is one who uses the model to stress-test their own thinking and who still owns every conclusion. The AI expands the hypothesis space. The analyst decides which hypotheses are worth pursuing, which evidence actually supports them, and what the answer means for the business, the environment, and the decision at hand.

There is a trap here, and it is worth naming. If you prompt an LLM with your existing theory and ask it to help you build the case, it will - willingly and convincingly. The model is a compliance machine unless you deliberately instruct it otherwise. It will generate supporting reasoning, surface matching indicators, construct a coherent narrative. Every one of those outputs feels like progress. None of it is investigation. It is confirmation bias with machine-grade production values.

The discipline is to always ask the model the second question. Not just “does this theory hold?” but “what would make this theory wrong?” If you only ask the first, you are not using AI as a thinking partner. You are using it as a yes-machine.

Hypotheses Are Living Documents

Treat your hypotheses the way a scientist treats them: as things that must be written down, compared against evidence, and updated as the investigation develops.

Not held in your head.

The moment your hypotheses live only in your head, two things happen. First, you lose track of which ones you have actually considered and which ones felt obvious enough to skip. Second, you quietly revise your theory as new evidence comes in without noticing you are doing it. A phenomenon behavioural scientists call hindsight bias, and it is lethal to investigation quality.

Writing them down forces honesty. A hypothesis you wrote at 14:05 that no longer matches the evidence at 15:30 is a hypothesis you killed. That kill is useful. It tells you what you learned. An unwritten hypothesis that silently morphed to fit the new evidence teaches you nothing, because you were never testing it in the first place.

Your investigation notes should answer three questions at any moment:

• What hypotheses am I currently considering?

• What evidence supports or contradicts each one?

• What would I need to see to rule any of them in or out?

If your notes do not answer those three questions, you are not building an investigation. You are building a timeline of your own attention.

Your Hypothesis Depends on Your Assumptions

Before you get too attached to any theory, pause on one question: what am I assuming about the data that this hypothesis depends on?

Your theory might be “the account was compromised at 14:32.” But if the timestamps you are reasoning from are in the wrong timezone, you are testing the wrong hypothesis entirely. A 14:32 UTC event interpreted as local time shifts the entire narrative. Suddenly the “suspicious login after hours” is a routine login during business hours. Your whole case collapses - not because the analysis was flawed, but because the assumption underneath it was.

This is the opening into the next post in this series. Hypotheses live or die by the timeline they are tested against. And timelines are harder to build than most analysts realise. That is where we go next.

The Starting Move

Starting tomorrow, make this the first thing you do after the W+H baseline is in place: write down at least two competing hypotheses in plain language. No jargon. No actor names. Just what you think might have happened, in sentences a peer could challenge.

If you cannot write two, you do not know enough to investigate yet. That is useful information. Go gather more context.

If you write two and one of them feels obviously correct before you examine the evidence, that is the hypothesis you should interrogate hardest. Not because it is wrong, but because “obviously correct” is the sound confirmation bias makes when it is working.

The evidence is not the investigation. The theories are the investigation. The evidence is how you choose between them.

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.