2.2 Core Workflows and Decision Points

CompTIA CySA+ Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CompTIA CySA+ Orientation and Exam Strategy

1.1 Current CompTIA CySA+ Exam Facts 1.2 Eligibility, Application, and Scheduling 1.3 Blueprint Domains and Weighting 1.4 Question Style and Score Report Thinking 1.5 Study Calendar and Practice Plan

2 Chapter 2: Security Operations

2.1 Security Operations Overview 2.2 Core Workflows and Decision Points 2.3 Scenario Practice for Security Operations 2.4 Common Traps in Security Operations 2.5 Practice Drills and Readiness Markers

3 Chapter 3: Vulnerability Management

3.1 Vulnerability Management Overview 3.2 Scanning, CVSS, and Prioritization Workflows 3.3 Remediation, Mitigation, and Software Controls 3.4 Common Traps in Vulnerability Management 3.5 Practice Drills and Readiness Markers

4 Chapter 4: Incident Response Management

4.1 Incident Response Management Overview 4.2 Core Workflows and Decision Points 4.3 Scenario Practice for Incident Response Management 4.4 Common Traps in Incident Response Management 4.5 Practice Drills and Readiness Markers

5 Chapter 5: Reporting and Communication

5.1 Reporting and Communication Overview 5.2 Core Workflows and Decision Points 5.3 Scenario Practice for Reporting and Communication 5.4 Common Traps in Reporting and Communication 5.5 Practice Drills and Readiness Markers

6 Chapter 6: Final Review and Test Day

6.1 Timed Practice Strategy 6.2 Last-Week Review Map 6.3 Exam-Day Checklist 6.4 After the Exam and Next Steps

2.2 Core Workflows and Decision Points

Key Takeaways Explain This Topic AI

SOC monitoring flows from data collection (SIEM, EDR, netflow) to detection, triage, and escalation.

Know the standard log sources and their key event IDs, and which tool answers which question.

SOAR automates repetitive triage and orchestrates playbooks; it augments analysts, it does not replace them.

Correlation and a tuned baseline separate true positives from the alert noise that causes fatigue.

Last updated: June 2026

2.2 Core Workflows and Decision Points

A security operations center (SOC) runs a repeatable pipeline: collect telemetry, normalize and correlate it, detect, triage, and escalate . CySA+ tests each handoff in that pipeline, so learn the inputs, the controlling tool, and the output of each stage.

The monitoring pipeline

Stage Primary tool/data Decision you make

Collection Syslog, Windows Event Logs, NetFlow/IPFIX, EDR, packet capture Are the right sources feeding the SIEM?

Aggregation/correlation SIEM (Splunk, Sentinel, Elastic) Do separate events form one attack story?

Detection Signatures (IDS/IPS, YARA), behavioral/anomaly rules Is this a known bad or an unusual deviation?

Triage EDR, sandbox, Wireshark/tcpdump, threat-intel lookup True positive, false positive, or benign?

Response SOAR playbooks, ticketing, containment Automate, escalate to IR, or close?

Log sources you must read on sight

Windows security auditing event IDs are frequent PBQ fodder. Commit these to memory:

4624 – successful logon; the Logon Type field matters (Type 3 = network, Type 10 = RemoteInteractive/RDP).

4625 – failed logon; a burst of 4625 across many accounts = password spraying .

4648 – logon using explicit credentials (lateral movement / runas indicator).

4672 – special privileges assigned at logon (admin/SYSTEM session).

4688 – new process created (command-line auditing reveals living-off-the-land abuse).

On Linux, watch /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) for sshd authentication failures and sudo escalations, and /var/log/syslog for daemon activity. NetFlow/IPFIX records summarize conversations (source/destination IP, ports, byte and packet counts) without payload, which is ideal for spotting beaconing and exfiltration volume at scale; full packet capture (PCAP) adds payload for deep inspection but is storage-expensive, so most SOCs keep flow data long-term and capture packets selectively.

Detection methods you must distinguish

The exam separates two detection philosophies. Signature-based detection (traditional IDS/IPS rules, antivirus, YARA) matches known-bad patterns: it is precise and low-noise but blind to novel attacks. Behavioral/anomaly-based detection compares activity to a learned baseline and flags deviations: it can catch zero-day and fileless activity but produces more false positives until tuned. Heuristic detection sits between, scoring suspicious characteristics.

Most mature SOCs layer all three, and CySA+ expects you to pick the method that fits the threat described — signatures for known malware, behavioral analytics for living-off-the-land abuse.

Correlation beats single alerts

A single failed login is noise. The same source IP producing 4625 across 50 accounts in two minutes, then one 4624, then a 4672 is a credible compromise. CySA+ rewards the answer that correlates events into a chain rather than reacting to one line. This is why SIEM correlation rules and a tuned baseline are emphasized: without a baseline, you cannot define "anomalous," and untuned rules drown analysts in false positives (alert fatigue).

SOAR: automation and orchestration

Security Orchestration, Automation, and Response (SOAR) platforms execute playbooks that perform the deterministic steps of triage: enrich an IP against threat intel, pull the EDR process tree, disable an account, or open a ticket. The exam-correct framing is that SOAR augments analysts by automating repetitive tasks and orchestrating tools , freeing humans for judgment-heavy investigation. It does not replace analysts, eliminate firewalls, or by itself generate threat intelligence.

A practical correlation tool the exam references is the SIEM use case , a saved rule that joins data sources to detect a specific scenario — for example, "VPN login from country A followed within an hour by a login from country B" flags impossible travel . Building and tuning these rules is core SOC work: too loose and analysts drown in false positives; too tight and real attacks slip through. The metric that captures this balance is the true-positive vs. false-positive rate , and reducing false positives is the single biggest lever against analyst alert fatigue .

Common decision-point traps

Watch for stems that tempt you to act before you have evidence. Containing a host on one suspicious DNS lookup may destroy volatile memory you needed; conversely, "keep monitoring" is wrong when you already have confirmed C2. The defensible answer matches the confidence the evidence supports : enrich and correlate when uncertain, contain when confirmed.

Remember the order of volatility when a stem implies evidence collection: capture the most fleeting data first — CPU registers and cache, then RAM and running network connections, then disk and logs, then archival media and backups. An analyst who powers off or reimages a host on a hunch loses the memory-resident artifacts that fileless malware lives in. The exam-correct sequence almost always preserves volatile evidence before any destructive containment, and it documents each step so the action holds up in an investigation.

When two actions seem reasonable, prefer the one that gathers confirming evidence while keeping the cleanest, most defensible audit trail.

Standardizing and automating processes

Objective 1.5 of Domain 1.0 covers standardizing and automating SOC work, and the exam tests why it matters, not just the buzzwords. Standardization through documented playbooks and runbooks ensures every analyst handles the same alert the same defensible way; it makes onboarding faster and makes outcomes auditable. Automation through scripting and SOAR removes human latency and error from repetitive steps — enrichment, ticket creation, blocklist updates, and account disablement.

Two terms to keep straight: orchestration is coordinating actions across many tools (firewall, EDR, ticketing), while automation is executing an individual task without a human. The exam-correct view is that automation handles volume and speed so analysts can spend judgment on the ambiguous cases that scripts cannot resolve. A related concept is single pane of glass — consolidating tool outputs into one console — which reduces context-switching and the missed correlations that cause incidents to slip through. Automating a bad process only scales the mistake, so standardize first, then automate.