Huntbook by Predefender

part-1

OODA Loop

A practical explanation of the OODA Loop and how threat hunters can use it to structure observation, orientation, decision-making and action during investigations.

Author: Roger C.B. Johnsen

Introduction

The OODA Loop is a decision-making framework built around four activities: Observe, Orient, Decide and Act.

The model is commonly associated with United States Air Force Colonel John Boyd and was originally developed in a military context. It is often used to explain how people and organisations make decisions in competitive, uncertain and fast-moving environments.

Personally, I think the OODA Loop is one of those models that is far more useful than its original context suggests. It can be used in military strategy, business, sports, security operations, incident response, detection engineering, threat hunting and ordinary daily life. Any time you have to understand a situation, make sense of incomplete information, choose what to do and then adapt based on the result, you are already close to OODA thinking.

That is why the model works well in security. A SOC analyst does not simply receive an alert and press a button. A threat hunter does not simply run a query and declare an answer. A detection engineer does not simply write a rule because a technique exists in ATT&CK. All of these roles depend on the same basic movement:

Observe what is happening.
Orient around context.
Decide what to do next.
Act in a way that creates new information or improves the situation.
Repeat.

This is the real value of the OODA Loop. It reminds us that good security work is not a straight line from signal to conclusion. It is an iterative process where each action should improve the next observation.

The OODA Loop is useful because it reminds the analyst that investigation is not a straight line. Every action should create new observations.

– Roger Johnsen

What the OODA Loop Is

The OODA Loop is often shown as a cycle.

OODA loop

Courtesy of online.visual-paradigm.com

The four parts are:

StepMeaning
ObserveGather information from the environment.
OrientInterpret the information in context.
DecideChoose what to do next.
ActCarry out the decision and create new observations.

The model looks simple, but the real value is not in memorising the four words. The value is in understanding the movement between them.

Observation without orientation is just data collection. Orientation without decision becomes endless analysis. Decision without action produces no effect. Action without renewed observation becomes blind movement.

The loop matters because every action changes the situation in some way. A query produces new results. A containment action changes attacker behaviour. A conversation with a system owner adds business context. A false positive teaches something about normal behaviour. Each of those outcomes feeds back into the next loop.

That makes OODA useful for threat hunting, incident response, detection engineering and everyday security operations.

Observe

Observe means gathering information from the environment. In threat hunting and SOC work, observations may come from many places:

  • alerts
  • process telemetry
  • command lines
  • authentication logs
  • DNS queries
  • proxy logs
  • firewall logs
  • cloud audit logs
  • email logs
  • endpoint telemetry
  • user reports
  • threat intelligence
  • asset and identity context

But observation is not the same as understanding. This is an important distinction. A suspicious command line is an observation. A rare domain is an observation. A failed login pattern is an observation. An EDR alert is an observation. None of those things explain themselves.

The analyst still has to understand what was observed, where it came from, how reliable it is and what else may be needed before any conclusion makes sense.

Useful questions in the Observe phase include:

QuestionWhy it matters
What exactly did we observe?Prevents vague investigation notes.
Which data source produced it?Helps assess reliability and completeness.
Is the observation complete?Avoids conclusions based on partial evidence.
Is this rare, suspicious, expected or unknown?Starts the orientation process.
What else should we observe before deciding?Prevents premature action.

A weak observation is often too vague:

Suspicious PowerShell.

A better observation is more specific:

WINWORD.EXE spawned powershell.exe with encoded arguments on a finance workstation shortly after the user opened an attachment.

The second version gives the analyst something to work with. It includes process context, command-line context, host context, user context and timing. That makes the next step possible.

Orient

Orient is the most important part of the loop. This is where the analyst turns observation into context. It is also where experience, environment knowledge, threat intelligence and scepticism matter. In security work, orientation may include:

  • understanding the user
  • understanding the host
  • understanding the business process
  • checking asset criticality
  • comparing against baseline behaviour
  • reviewing related telemetry
  • considering threat intelligence
  • testing alternative explanations
  • mapping behaviour to ATT&CK or another framework
  • deciding whether the evidence actually supports suspicion

This is where many investigations succeed or fail. If the analyst orients badly, the rest of the loop becomes weak. Benign activity may become a false incident. Malicious activity may be dismissed because it does not match the expected pattern. A noisy alert may be closed too quickly, or a weak signal may be over-escalated without enough evidence.

For example:

ObservationPoor orientationBetter orientation
PowerShell launched by OfficeMalicious PowerShellOffice-spawned PowerShell is rare in this environment and should be reviewed with user, command-line, parent process and network context.
Login from foreign countryAccount compromisedCheck user travel, VPN, impossible travel, device, MFA result and session behaviour.
Large file transferData exfiltrationCheck destination, user role, business process, file type, time, volume and approval context.
New scheduled taskPersistenceReview creator, command, path, timing, host role and whether it matches software deployment activity.

Orientation is also where the other frameworks in this book become useful.

MITRE ATT&CK may help describe the behaviour. The Diamond Model may help structure the relationship between adversary, infrastructure, capability and victim. The Kill Chain and Unified Kill Chain may help place the behaviour in a larger intrusion progression. OODA is different because it describes the analyst’s decision process rather than the adversary’s behaviour.

Observation tells you what appeared. Orientation helps you understand what it may mean.

– Roger Johnsen

Decide

Decide means choosing what to do next based on the current understanding. This does not always mean making a final conclusion. In threat hunting, a decision is often much smaller and more practical. It may simply be the next investigative move. Possible decisions include:

  • pivot to related hosts
  • review parent and child processes
  • check network activity
  • enrich an indicator
  • search for similar behaviour
  • validate with the asset owner
  • escalate to SOC or incident response
  • create a detection candidate
  • document a false positive pattern
  • close the lead as benign
  • continue the hunt with a refined hypothesis

The decision should match the evidence. If the evidence is weak, the right decision may be to gather more context. If the evidence is strong, the right decision may be to escalate. If the evidence points to benign activity, the right decision may be to document the pattern and improve future triage.

A useful decision is explicit:

Search for the same Office-spawned PowerShell pattern across all endpoints for the last 30 days.

A weak decision is vague:

Investigate more.

The difference matters. A clear decision can be reviewed, repeated and challenged. A vague decision usually leads to wandering.

Act

Act means carrying out the decision. In security work, actions may include:

  • running a query
  • pivoting across telemetry
  • enriching data
  • reviewing endpoint evidence
  • contacting a system owner
  • escalating to incident response
  • creating a detection
  • updating a playbook
  • documenting a finding
  • suppressing known benign activity
  • recommending a control improvement

The action should do something useful. It should produce new information, reduce uncertainty, improve detection, improve response or change the situation in a deliberate way.

For example:

DecisionActionNew observation
Search for similar PowerShell behaviourRun query across endpoint telemetryThree additional hosts show the same pattern.
Validate whether activity is administrativeContact system ownerActivity matches software deployment script.
Check for C2 after executionReview DNS and proxy logsEndpoint contacted rare external domain after execution.
Improve future detectionDraft detection logicCandidate rule identifies rare Office-spawned PowerShell.

This is why the loop repeats. The result of the action becomes a new observation. That new observation changes the next orientation. The next orientation changes the next decision. This is the discipline of OODA in practice.

OODA in Daily Life

One reason I like the OODA Loop is that it is not limited to security work. People use this pattern all the time, often without naming it. You observe that traffic is heavier than usual. You orient by considering the time of day, weather, route options and whether you need to be somewhere at a specific time. You decide to take another route. You act, and then you observe whether that decision helped.

The same pattern appears in conversations, planning, problem solving, leadership, incident handling and technical troubleshooting.

This matters because OODA is not an artificial process forced onto the analyst. It describes a natural decision cycle and gives us a way to make that cycle more deliberate. In stressful environments, that can be valuable.

When pressure increases, people often skip orientation. They observe something, decide too quickly and act. Sometimes that works. Often it creates unnecessary noise, wrong conclusions or avoidable damage. OODA is a reminder to keep the full loop intact.

The Loop in Threat Hunting

For threat hunters, the OODA Loop can be written as:

Observe → Orient → Decide → Act → Repeat

A simple hunt may move through the loop many times.

Example:

LoopObserveOrientDecideAct
1EDR alert for suspicious PowerShellOffice spawned PowerShell on finance workstationSearch for similar behaviourQuery endpoint telemetry
2Three more hosts show similar patternSame parent process, similar attachment timingReview email deliverySearch email logs
3Same sender targeted multiple usersPossible phishing campaignCheck network activity after executionReview DNS and proxy logs
4One host contacted rare domainPotential command and controlEscalate for containment and deeper IRHand over structured findings

This is not a straight path. The hunter learns something, adjusts and continues. The value is not speed alone. The value is reducing uncertainty while maintaining enough tempo to remain useful.

OODA and Tempo

The OODA Loop is often associated with speed, but speed alone is not the point. A fast wrong decision is still wrong.

In security operations, the goal is not simply to move faster than the adversary. The goal is to observe better, orient faster, decide with enough confidence and act in a way that changes the situation.

Sometimes that means acting quickly. Sometimes that means slowing down long enough to avoid a bad conclusion.

For example, disabling an account may be the right action if there is strong evidence of compromise. But if the evidence is weak and the account belongs to a critical business process, the team may need more context before acting.

Tempo is useful movement. Panic is just movement.

Moving fast is not the same as thinking well. The defender needs tempo, but the tempo must be connected to evidence.

– Roger Johnsen

OODA in the SOC

In a SOC, the OODA Loop appears constantly.

OODA stepSOC example
ObserveAlert fires, user reports phishing, EDR records suspicious behaviour.
OrientAnalyst reviews context, asset, user, telemetry, history and threat intelligence.
DecideAnalyst chooses to close, investigate, escalate, contain or enrich.
ActAnalyst performs the chosen action and documents the result.

The quality of SOC work often depends on the quality of orientation. If analysts are forced to move directly from alert to action without context, the SOC becomes reactive and noisy. If analysts observe and orient well, their decisions become more reliable.

The OODA Loop also helps explain why playbooks matter. A good playbook does not remove judgement. It helps the analyst orient and decide faster by showing what evidence to collect, what questions to ask and what actions are available.

OODA in Detection Engineering

OODA also applies to detection engineering. Detection engineering is not only about writing rules. It is a decision process where the engineer observes adversary behaviour, orients around available telemetry, decides what logic may detect the behaviour and acts by building, testing or tuning detection content.

A simple detection engineering loop might look like this:

OODA stepDetection engineering example
ObserveThreat intelligence describes a technique, or a hunt identifies suspicious behaviour.
OrientEngineer reviews telemetry, data quality, expected noise and environment-specific context.
DecideEngineer chooses whether to build detection logic, improve enrichment, create a hunt query or document a telemetry gap.
ActEngineer builds, tests, tunes or documents the detection approach.

This is important because detection engineering can fail in the same way investigations fail. If the engineer observes a technique but does not orient around local telemetry, the result may be a noisy rule, a brittle rule or a rule that cannot work in the environment.

Good detection engineering is OODA with engineering discipline.

OODA in Threat Hunting

Threat hunting is usually less urgent than incident response, but it still benefits from OODA thinking. A hunt begins with an observation, hypothesis, intelligence report, detection gap or question. The hunter orients by understanding the environment and the behaviour being tested. The hunter then decides how to test the idea and acts by querying data, pivoting, enriching and validating.

The loop repeats until the hunt reaches a useful output. That output may be:

  • a confirmed finding
  • a rejected hypothesis
  • a detection candidate
  • a visibility gap
  • a triage improvement
  • a control recommendation
  • a better understanding of normal behaviour

This matters because a threat hunt should not be a long browsing session through logs. Each loop should improve the investigation. If the loop does not produce better understanding, the hunt is probably drifting.

Where OODA Fits With Other Frameworks

The OODA Loop works differently from the other frameworks in this section.

FrameworkMain value
Lockheed Martin Kill ChainDescribes intrusion progression and disruption opportunities.
Unified Kill ChainDescribes broader adversary progression and operational phases.
MITRE ATT&CKProvides behavioural vocabulary for adversary techniques.
Diamond ModelStructures relationships between adversary, infrastructure, capability and victim.
OODA LoopStructures decision-making under uncertainty.

The other frameworks help describe the adversary, the intrusion or the evidence. OODA helps describe the analyst’s process.

That makes it useful as a mental model for investigations, SOC work, detection engineering and daily decision-making. It helps the analyst avoid two common failure modes: getting stuck in observation without decision, and acting without orientation.

What Usually Goes Wrong

Several problems appear when teams use OODA poorly.

ProblemWhy it hurts
Observing without orientingThe analyst collects data but does not understand what it means.
Orienting with weak contextThe analyst makes decisions based on incomplete or misleading assumptions.
Deciding too earlyThe team acts before the evidence supports the action.
Never decidingThe investigation becomes endless analysis without output.
Acting without feedbackThe team takes action but does not observe whether it changed anything.
Treating speed as the goalThe team moves quickly but makes poor decisions.
Ignoring documentationLater loops lose the reasoning behind earlier decisions.

The loop should improve decision quality. It should not become a slogan for rushing.

Working Position for This Book

For this book, the OODA Loop is best treated as a decision-making model for threat hunters and security analysts.

It helps explain how an investigation moves from observation to context, from context to decision, and from decision to action. It also helps explain why good security work is iterative. The analyst should not expect the first observation to be enough, or the first decision to be final.

The model is simple:

Observe.
Orient.
Decide.
Act.
Repeat.

But the discipline is in how the analyst uses it. Observe carefully. Orient with context. Decide explicitly. Act in a way that creates new information or improves security. Then repeat the loop with what you have learned.

A good hunt is not only about what the hunter finds. It is also about how the hunter thinks, decides and adapts while the hunt is unfolding.

– Roger Johnsen

Resources

Revision

Revised DateComment
2026-07-10Major rewrite. Reframed the article as a practical guide for using the OODA Loop during daily decision-making, SOC analysis, detection engineering, threat hunting and decision-making under uncertainty.
2024-10-06Improved formatting and wording
2024-06-22Added page