A comprehensive study guide covering the OODA Loop decision-making framework, defensive capabilities (Detect/Destroy/Degrade/Disrupt/Deny/Deceive), IOC detection sources, incident classification into benign/suspicious/malicious, impact analysis (organizational/localized/immediate/total), impact-based vs. taxonomy-based triage approaches, and eight incident classification factors.
The OODA Loop is a decision-making model created by Colonel John Boyd to help responders think clearly and act decisively during the fog of war. In cybersecurity, it provides a structured cycle for moving from observation to action during an incident — faster than the adversary can adapt.
Exam note: The OODA Loop is not in the CySA+ exam objectives and you won't be tested on it directly. It is covered here because it's a widely-used framework in incident response practice. Focus your exam study on sections 3–7 of this chapter.
Identify the problem. Gather all available data about the current situation.
→
O
Orient
Reflect on findings. Build situational awareness. Generate courses of action.
→
D
Decide
Choose a course of action. Create a response roadmap considering all outcomes.
→
A
Act
Execute the decision. Then re-enter Observe to assess the effect.
⟳ After Act → return to Observe. Repeat until the incident is resolved.
Observe
Identify the threat and gather environmental information — alerts, logs, user reports. Example: a SIEM alert fires because an employee clicked a phishing link. Gather everything you can, but avoid paralysis by analysis. A small amount of data is enough to begin.
Orient
Build situational awareness from the observed data. Identify what permissions the affected user had. Determine what changes occurred after the click. Assess the attacker's likely goals. Orient produces a set of possible response options.
Decide
Select a course of action from the options generated during Orient. Which malware was installed? How will the system be isolated? Decisions may be made in a meeting or rapidly by a single analyst — either way, produce a clear action plan.
Act
Execute the decision. Isolate the compromised system. Begin forensic collection. Notify relevant parties. Then immediately re-enter Observe — did the isolation work? Are there other indicators? The loop continues until the incident is resolved.
The key principle — agility over completeness: The OODA Loop stresses speed. Don't wait for perfect information before acting. Take a small action, then observe the result. An adversary with a faster OODA loop than yours has the initiative — they're doing damage while you're still analysing. Make a decision with the data you have, act, then update based on what you observe next.
2
Defensive Capabilities — The 6 D's
From the Lockheed Martin Intelligence-Driven Computer Network Defense white paper (~14 pages — recommended reading): defenders have six categories of capability they can use against adversaries. These map across the Kill Chain phases (reconnaissance → weaponisation → delivery → exploitation → installation → C2 → action on objectives). Most commercial organisations can only use five — Destroy requires legal authority that private companies don't have.
D
Detect
Identify the presence of an adversary or their resources. Your SIEM alerts, IDS signatures, and log analysis are your primary detect capability. First line of response — you can't act on what you can't see.
D
Destroy
Render adversary resources permanently useless. Available only to government/military with legal authority ("hack-back"). Commercial organisations do NOT have this capability. The Destroy column in a private org's matrix is always empty.
D
Degrade
Reduce adversary capability temporarily. Example: block a VPN IP range being used in an attack. Buys time but isn't permanent — the attacker can simply get new IP addresses and resume. Useful for slowing the adversary while you respond.
D
Disrupt
Interrupt adversary communications, frustrate, or confuse their efforts. Adding MFA, blocking C2 ports, resetting compromised credentials. Any action that interferes with the attacker's ability to operate inside your network.
D
Deny
Prevent adversary from accessing your assets or learning about your capabilities. The ideal defensive posture — keep them out entirely and keep them uninformed. Strong perimeter controls, least privilege, and minimal footprint all contribute to Deny.
D
Deceive
Supply false information to distort the adversary's understanding. Honeypots, fake credentials, canary documents. If an attacker steals false documents you planted, they waste time and expose their exfiltration method without gaining real intelligence.
Kill Chain mapping: Each defensive capability can be mapped to the phases where it's most effective. Web analytics → Detect at reconnaissance. Network IDS → Detect at weaponisation. Vigilant users → Detect at delivery. Honeypots → Deceive at installation/C2. Build this matrix for your organisation to understand your defensive coverage gaps.
3
Detection Sources — Technical & Non-Technical IOC Inputs
The Detection & Analysis phase relies on a wide variety of IOC sources — both automated technical alerts and human-reported non-technical observations. A well-tuned SIEM serves as the central repository, aggregating all of these into a single view for the analyst.
Anti-malware software — signature match fires when known malware hash or behaviour is detected on an endpoint.
Network IDS/IPS — automated alerts on port scans, signature matches, known-bad IP traffic patterns.
Internal personnel — employees who witnessed a suspicious event or noticed anomalous behaviour. Non-technical but valid IOC source.
External parties — security researchers who found your data on the web; partners notifying you of a breach involving shared systems.
Cyber threat intelligence — third-party feeds, vulnerability databases, threat research sharing your IOCs or providing new ones.
Event correlation: No single log tells the whole story. Correlate across systems — if a host log shows an attempted SQL injection, check the database server log to see if it succeeded. A failed attack may warrant a re-image of the source machine. A successful attack launches a full incident response beginning with the database server.
4
IOC Classification — Benign, Suspicious, or Malicious
Once an IOC is detected, an incident handler must classify it into one of three categories. This classification determines whether an incident response begins, is escalated for further analysis, or is closed as a false positive. Knowing your baseline — what "normal" looks like — is the foundation of accurate classification.
✓ Benign
False positive. The analyst weighs the evidence and concludes there is no actual threat. The alert fired due to normal activity matching a rule imperfectly. No incident response action required — but tune the rule to reduce future false positives.
? Suspicious
Analyst is uncertain. The evidence is inconclusive — could be benign or malicious. Passed to a more senior analyst for a second opinion. Kept under observation. Additional data collection may help resolve the classification.
✗ Malicious
Confirmed incident. The analyst determines a security policy has been violated. Incident response begins immediately — containment, eradication, recovery and post-incident phases activate based on playbooks.
What enables accurate classification
Baseline knowledge
File integrity hashes, network traffic baselines, average CPU/memory per machine. If you know what normal looks like, abnormal is immediately visible. A process using 155 MB when it normally uses 15 MB is suspicious — but only if you know the baseline.
Subject matter experts
No single person knows everything. An incident handler who can't determine if a SQL statement is malicious should call in a DBA. Knowing who to call is as important as what to look for.
Event correlation
Look at the same event across multiple systems, logs, and timeframes. A single alert may be ambiguous; the same event correlated with three other system logs may be clearly malicious.
Automation
Modern SIEM triage is increasingly automated for known IOCs. But automation can't replace human judgement for novel or ambiguous indicators — and it can't make business impact decisions. Automate what you can, but keep humans in the loop for classification.
5
Impact Analysis — Four Impact Types
Impact analysis is the triage function — determining how severe an incident is so you can allocate resources appropriately. The question is not just "what happened?" but "what does it cost us, and how quickly do we need to respond?" System downtime alone can cost $300,000–$5 million per hour for larger organisations (2019 survey). Not all impacts are equal, and not all impacts are obvious.
Organizational Impact
Incident affects mission-essential functions across the whole organisation. Many users affected. Example: email server goes down — all staff lose communication capability. Typically highest priority due to breadth of impact.
Localized Impact
Limited to a single department, small user group, or one system. Example: one manager's workstation is compromised. Warning: localized does not mean lower priority — a single payroll system going down the day before payday has more urgency than enterprise email outage.
Immediate Impact
Direct costs incurred because of the incident: downtime cost, asset damage, regulatory penalties, contractual fees. Quantifiable in dollars — provides a hard number for prioritisation decisions. "This costs us $50,000 per hour" is a compelling escalation argument.
Total Impact
All costs during and after the incident, including long-term reputational damage. A cybersecurity company getting hacked has higher total impact than a piano lessons website getting hacked — same breach, vastly different reputational consequences. Industry context matters enormously for total impact.
Don't assume scope equals priority: "10 machines affected" vs. "1 machine affected" doesn't automatically make the 10-machine incident higher priority. A single compromised payroll server the night before payday is more urgent than 10 compromised employee workstations. Always ask: what does this system do? before assigning priority based on scope.
Triage categories and costs
Data integrity
Has data been modified without authorisation? Can I still trust this data? A tampered checking account balance, modified medical records, or altered financial data — integrity breaches can have cascading consequences even without exfiltration.
Unauthorised changes
Has the system configuration been altered? Registry keys, user accounts, service states? Changes made without going through the change management process are both an IOC and a triage factor.
Data theft or disclosure
Has confidential data been stolen or made public? Was PII, PHI, or financial data exfiltrated? These trigger regulatory reporting requirements and have the highest reputational and legal consequence.
Service interruption
Is a business process or system unavailable? Quantify the cost per hour — this number drives escalation decisions and resource allocation. Most orgs should know their downtime cost per hour before an incident happens.
6
Triage Approaches — Impact-Based vs. Taxonomy-Based
Impact-Based (preferred in industry)
Categorises incidents by severity — emergency, significant, moderate, low. Focuses on scope and cost: a large scope + high cost = high priority; small scope + low cost = lower priority. More flexible and better suited to business decision-making. Most organisations in practice use this approach. Requires assessing business impact rather than just incident type.
Taxonomy-Based
Categorises incidents by type — worm outbreak, phishing, DDoS, account compromise, internal privilege abuse, external host, etc. Each category has pre-defined procedures and priorities. More structured and consistent — every worm outbreak follows the same playbook. Less flexible when the incident doesn't fit neatly into a category.
In practice: Most organisations use impact-based as their primary triage method — it directly drives resource allocation decisions. Taxonomy-based categories are still useful for triggering the right playbook once the severity level is established.
Beyond the four impact types, incidents can be classified using eight specific factors that affect their overall priority. Each factor represents a dimension of risk — the more factors point to a high-severity rating, the higher the combined priority of that incident.
Data Integrity
Has data been modified or does it lack integrity? Modified financial records, tampered database entries, corrupted logs. If data can't be trusted, every system and process that relies on it is affected. High priority because you may not know the full scope of the corruption.
System Process Criticality
Does the incident disrupt or threaten a mission-essential business function? A compromised video delivery server for a training company. A payment processor going down. Even if there's no immediate financial cost, the longer a critical process is disrupted, the larger the business impact grows.
Downtime
Does the incident degrade or interrupt availability? System downtime costs $300K–$5M+ per hour for larger organisations. Even non-technical downtime (overloaded phone queues) counts. Longer downtime = higher priority because of compounding costs.
Economic
What is the short and long-term financial cost? Even incidents without downtime have economic cost — data recovery, contractor fees, staff overtime, and regulatory fines. A destroyed server may be replaced quickly but the forensic and remediation work still costs money.
Data Correlation
Is this incident linked to a known adversary group's TTPs? If IOCs match APT28 or another nation-state group, the threat level is dramatically higher than a script kiddie stumbling onto your network. Known TTPs = known capability level = better threat assessment.
Reverse Engineering
Does reverse engineering the malware reveal a known threat actor? If analysis of captured malware code reveals signatures or techniques associated with a specific adversary group, the incident's classified threat level rises. Advanced malware linked to APT groups demands a more comprehensive response.
Recovery Time
How long will full recovery take? Extensive recovery time due to scope or severity means longer downtime and higher cost. A ransomware attack encrypting all file servers may take weeks to recover from. High recovery time = high priority because everything else is waiting for resolution.
Detection Time
How long was the attacker present before detection? Only 10% of breaches are discovered within the first hour. 40% take months. 40% of adversaries exfiltrate data within minutes of starting. A high detection time = more time for damage. Incidents with long dwell times get elevated priority for forensic investigation — the attacker had more time to move laterally, escalate, and exfiltrate.
Detection time statistics — why speed matters: 10% of breaches detected within 1 hour. 20% took days to discover. 40% took months. 40% of adversaries exfiltrate data within minutes. The math is stark — in 90% of cases, the attacker has at least an hour before detection, and in nearly half of those, they have your data already. Reducing detection time is one of the highest-ROI security investments.
Exam
Quick Reference Cheat Sheet
OODA Loop
Observe (gather data) → Orient (build situational awareness + generate options) → Decide (choose a course of action) → Act (execute) → repeat. Key principle: agility over completeness. Don't wait for perfect information — act, then observe the result. A faster OODA loop than the adversary = initiative.
Technical: anti-malware, NIDS/HIDS, Windows Event Logs, firewall logs, SIEM, flow data. Non-technical: internal personnel reports, external party notification, cyber threat intelligence feeds. SIEM = central aggregator. Correlate across multiple sources — no single log tells the full story.
IOC classification
Benign = false positive (close, tune the rule). Suspicious = uncertain (escalate to senior analyst, monitor). Malicious = confirmed incident (begin IR). Classify using: baseline knowledge, subject matter experts, event correlation, automation (for known IOCs). Human decision for ambiguous cases.
4 Impact types
Organizational (affects whole org — broad). Localized (one dept/system — but may be high priority e.g. payroll server). Immediate (direct dollar cost: downtime + damage + fines). Total (immediate + long-term reputational cost — cybersecurity company breach hits harder than a piano lesson company). Scope ≠ priority.
Triage approaches
Impact-based (severity: emergency/significant/moderate/low — based on scope + cost) = industry preferred. Taxonomy-based (category: worm/phishing/DDoS/account compromise — triggers specific playbook). Most orgs combine: impact-based for priority, taxonomy for playbook selection.
8 classification factors
Data integrity (can you trust the data?). System process criticality (mission-essential disrupted?). Downtime ($300K–$5M/hour). Economic (total financial cost). Data correlation (linked to known APT TTPs?). Reverse engineering (malware linked to threat actor?). Recovery time (scope/severity). Detection time (how long was attacker present?).
Detection time stats
Only 10% of breaches detected within first hour. 20% took days. 40% took months. 40% of adversaries exfiltrated data within minutes. → In 90% of cases, the attacker had at least 1 hour in your network before you knew. High dwell time = higher severity classification = more extensive forensic investigation needed.