A free study companion keyed to the officially published exam domains of CompTIA CySA+ (CS0-004): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. CompTIA CySA+ (CS0-004) objectives
A free, source-cited study companion built on CompTIA's published CS0-004 exam objectives — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
A free CySA+ program blueprint pinned to current CS0-004, turning security operations, vulnerability management, incident response, and reporting into isolated defensive analyst evidence without treating retired CS0-003 samples as current scope or claiming instructional completeness or an exam or employment outcome.
This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.
Modules
4
Labs
4
Concept checks
12
Resource mix
1 official / 0 community
Choose an outcome
Three routes through the same evidence
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Certification-focused
Learners targeting current CySA+ CS0-004 who already have enough security and networking foundation to practice intermediate analyst decisions.
Completion emphasis: Complete all four modules and defensive labs, the synthetic analyst-case capstone, current-versus-retiring version checks, and a final gap review against the V4 page.
Required phases: Version, foundation, ethics, and evidence baseline, Telemetry, baseline, detection, and triage, Discovery, context, priority, and verification, Evidence, containment, response, and recovery, Technical findings, executive decisions, and metrics, Synthetic analyst case capstone
Analyst skills first
Security learners and practitioners who want reviewable baselining, triage, vulnerability-prioritization, evidence, response, verification, and reporting artifacts.
Required phases: Version, foundation, ethics, and evidence baseline, Telemetry, baseline, detection, and triage, Discovery, context, priority, and verification, Evidence, containment, response, and recovery, Technical findings, executive decisions, and metrics, Synthetic analyst case capstone
Analyst career-fit sprint
Learners deciding whether intermediate log analysis, vulnerability prioritization, incident judgment, and high-stakes communication fit their interests and current foundation.
Completion emphasis: Complete the diagnostic plus one local-log baseline, one owned-target vulnerability queue, one fictional incident decision, and two-audience report; record whether to continue, bridge through foundations, or choose another security route.
Required phases: Version, foundation, ethics, and evidence baseline, Telemetry, baseline, detection, and triage, Discovery, context, priority, and verification, Evidence, containment, response, and recovery, Technical findings, executive decisions, and metrics
Start safely
Prerequisite diagnostic
Verify version, foundation, authorization, isolation, and evidence practices before intermediate analyst labs; this is not a formal prerequisite or pass prediction.
Have you confirmed that this program targets current CS0-004 and separated any CS0-003 registration, objectives, or sample material as retiring-version context?
Ready when: Yes, with CS0-004 controlling every domain and study-gap decision.
If not yet: Verify the current V4 page and the exact exam booked before using objectives, samples, or logistics.
Can you interpret addresses, ports, protocols, authentication events, common controls, basic vulnerabilities, and incident phases without starting from definitions?
Ready when: Yes, typically through equivalent Security+ and Network+ knowledge or demonstrable foundation artifacts.
If not yet: Bridge through foundational networking and security programs before treating CySA+ as the next exam target.
Can you limit every scan to localhost or a virtual machine you personally own and explain why public, employer, school, router, and third-party targets are excluded?
Ready when: Yes, with an explicit target allowlist containing only owned local addresses.
If not yet: Use synthetic Nmap/OpenVAS output and a written prioritization exercise; do not run a scanner.
Can your personal device safely run local logs, Nmap, and optionally a disposable VM, or do you need sanitized transcript/dataset alternatives?
Ready when: Either route is valid when active scanning stays owned/local and alternatives are labeled.
If not yet: Use the local-log transcript, synthetic service inventory, and fictional vulnerability results without installing a scanner or VM.
Can you preserve source, time, scope, fields, limitations, chain-of-custody assumptions, redaction, and retention for logs, scans, indicators, screenshots, and reports?
Ready when: Yes, with minimum necessary evidence and no real employer, user, credential, or target data.
If not yet: Use only synthetic evidence and complete the evidence-quality/redaction checklist before saving any local output.
Can you keep fact, hypothesis, confidence, business impact, severity, exposure, exploitability, and remediation priority separate?
Ready when: Yes, or you will complete the evidence-versus-inference warm-up before triage.
If not yet: Practice labeling what a finding proves, suggests, and cannot answer before making incident or vulnerability decisions.
Plan, then adapt
Pace options
Steady
12 weeks 8-10 hours/week
A planning estimate for learners stepping up from foundations: give operations and vulnerability work several weeks, then protect separate blocks for incident judgment, reporting, and integration.
Standard
8 weeks 10-14 hours/week
A planning estimate that follows the analyst workflow from telemetry through vulnerabilities, incidents, communication, and a two-week synthetic case and gap review.
Intensive
5 weeks 16-20 hours/week
For learners with existing SOC, vulnerability, incident, or equivalent lab experience; do not compress version checks, authorization, evidence review, or unfamiliar analyst reasoning.
Evidence-gated sequence
Program roadmap
1
Version, foundation, ethics, and evidence baseline
Pin CS0-004, assess analyst foundations, define owned/synthetic targets, and establish evidence, privacy, retention, and reporting rules.
Exit evidence
Confirm current CS0-004 domains/weights and label every CS0-003 sample or fact as retiring-version context.
Choose owned-local or synthetic routes for logs and scans and record the explicit target allowlist.
Complete the foundation, evidence-quality, fact/inference, redaction, and escalation diagnostic.
2
Telemetry, baseline, detection, and triage
Interpret authorized events and network/endpoint evidence, establish normal behavior, identify anomalies, form testable hypotheses, and document detection limits.
Retain a redacted local-log or synthetic dataset baseline with event source, fields, normal pattern, anomaly, filter, limitation, and candidate alert logic.
Investigate one initially unfamiliar event and document correlation, benign or suspicious conclusion, confidence, and what additional evidence would change it.
Correct every missed operations check and create one fresh event-to-alert-to-triage scenario.
3
Discovery, context, priority, and verification
Turn owned or synthetic scan/service findings into a context-rich remediation queue based on severity, exposure, exploitability, asset importance, controls, effort, and verification.
Retain Nmap/OpenVAS output from localhost/owned VM or a labeled synthetic equivalent plus a normalized finding table.
Rank findings using technical severity, exposure, known exploitation, asset/function, data, control, dependency, remediation, and exception context rather than CVSS alone.
Close one safe owned finding or simulate remediation, then record rescan/verification, residual risk, owner, due date, and exception route.
4
Evidence, containment, response, and recovery
Sequence analysis, evidence preservation, containment tradeoffs, eradication, recovery, monitoring, escalation, communication, and lessons for a fictional alert.
Retain a fictional incident runbook with facts, unknowns, hypotheses, evidence order, containment decision/tradeoff, authority, recovery, and monitoring.
Explain volatile/non-volatile evidence, chain-of-custody assumptions, scope expansion, business impact, false positives, and when not to act alone.
Pressure-test the runbook for a 2 a.m. handoff and remove every unstated dependency or unauthorized action.
5
Technical findings, executive decisions, and metrics
Translate the same evidence into actionable technical remediation, concise decision-maker communication, defensible metrics, and uncertainty without contradiction or alarmism.
Produce technical and executive versions of one finding with matching facts, explicit audience, risk, evidence, remediation, verification, owner, due date, and ask.
Complete the capstone and pass its source, evidence, priority, response, verification, communication, privacy, safety, and consistency review.
Crosswalk all four current domains to at least one artifact and one corrected or confidently explained check.
Record remaining gaps and choose a continue, foundation bridge, practice, defer, or exam-logistics-verification next decision.
Before a lab
Environment, access, and safety
Required and optional setup
Required
A personally owned computer for read-only local events or a sanitized synthetic event dataset/transcript
Localhost or a disposable virtual machine personally owned by the learner for any active Nmap/OpenVAS work, or a synthetic scan-output alternative
A text/spreadsheet workspace for events, findings, evidence, incidents, decisions, reports, metrics, and reflections
Optional
Nmap from the official project for localhost or owned-VM service/version discovery
Greenbone/OpenVAS Community Edition in an isolated local lab for a fuller owned-target workflow
A free local virtual machine and diagrams.net for isolated target and timeline/data-flow artifacts
Accounts and accessibility routes
Accounts
No online, cloud, paid, or employer account is required for the core program.
Nmap and Greenbone routes use local software; only legitimately obtained software/images and personally owned targets are permitted.
A spreadsheet may be local or paper-based; no hosted account is required.
Equivalent routes
Use sanitized event logs, service inventories, scan findings, evidence tables, and expected remediation/rescan output when installation, device, motor, visual, or authorization constraints block live tools.
Use written queries, filters, triage decisions, timelines, runbooks, and reports while labeling evidence synthetic or observation-only.
Split collection, normalization, analysis, decision, reporting, and reflection across sessions without reducing evidence-quality or safety requirements.
Safety baseline
Scan only localhost or a virtual machine you personally own and list the exact target before execution; never scan an employer, school, ISP router, public service, shared network, or third-party address.
Read only owned or synthetic logs and never clear, alter, collect, or export another person's telemetry or real workplace security data.
Never execute malware, deliver phishing, collect credentials, exploit a finding, create persistence, intercept traffic, or perform live containment/remediation on systems outside the isolated lab.
Redact host/user/account/address/time/path identifiers, minimize retained output, store findings privately, and treat vulnerability/incident reports as sensitive.
Show your work
Module evidence and missed-check protocol
Module exit evidence
A saved baseline/detection record, prioritized vulnerability queue, incident runbook/evidence table, technical/executive report, metric definition, or clearly labeled accessibility alternative tied to the domain map.
A plain-language explanation separating evidence, limitation, fact, hypothesis, confidence, business context, priority, action, owner, verification, and residual risk.
All authored checks attempted, with each miss corrected against its cited source and applied to a fresh analyst scenario.
After a missed check
Identify whether the question tests operations/detection, vulnerability context, incident management, or reporting before reviewing the answer.
Write why the distractor was plausible and which event field, exposure, exploitability, asset fact, evidence property, lifecycle order, audience, or metric definition distinguishes it.
Change one synthetic indicator, asset, exposure, control, business impact, containment constraint, or audience and explain whether the priority or response changes.
Completing this policy demonstrates current CS0-004 coverage and isolated analyst practice inside RoleMath; it does not predict a CySA+ score, replace recommended experience, or establish professional analyst work.
Integrated practice
Synthetic detection-to-decision analyst case
Analyze a coherent fictional security case from baseline and vulnerability context through incident response, remediation verification, technical/executive reporting, metrics, and handoff without scanning or acting on any live third-party system.
Workflow
Write a fictional environment brief for a forty-person services company with employee endpoints, identity provider, cloud email/files, public web application, VPN, centralized logs, vulnerability scanner, endpoint protection, and fictional data classifications and owners.
Create an evidence catalog and handling rules for synthetic authentication, DNS/proxy, endpoint, email, network, vulnerability, asset, change, and threat-intelligence data. Record source, field, time basis, scope, quality, retention, access, redaction, and what each source cannot prove.
Define a normal baseline and three candidate detections: repeated impossible or unusual sign-ins, endpoint process plus outbound-domain correlation, and a critical public-service vulnerability. For each, write logic, data dependencies, threshold, exclusions, tuning, false-positive risk, severity, and triage owner.
Build a synthetic vulnerability inventory with at least eight findings varying severity, exposure, known exploitation, asset criticality, data, control coverage, remediation availability, dependency, age, and exception status.
Prioritize the inventory and justify the top three using the full context rather than CVSS alone. Record owner, due date, proposed fix/mitigation, validation method, residual risk, and escalation or exception route.
Open a fictional incident when an endpoint detection and identity anomaly correlate with the top exposed vulnerability. Record alert time, reporter, assets, users, evidence, known facts, unknowns, initial scope, confidence, severity, business impact, and authority.
Build a timeline and evidence-quality table. For each item state whether it proves, supports, conflicts with, or cannot answer each hypothesis; avoid claiming compromise or attribution from a single indicator.
Write an investigation plan ordered by volatility, value, safety, and authorization. Include endpoint, identity, network, email, asset/change, vulnerability, and threat-intelligence checks plus explicit stop/escalation conditions.
Choose a fictional containment strategy and document the tradeoff among stopping harm, preserving evidence, operational impact, attacker awareness, legal/privacy needs, and decision authority. Do not execute containment in a real environment.
Write eradication, remediation, recovery, monitoring, and closure criteria covering root cause, persistence checks, credential/session actions, patch or mitigation, rebuild/restore where justified, rescan, detection validation, heightened monitoring, stakeholder approval, and residual risk.
Simulate a remediation verification package with before/after service or scan evidence, patch/configuration record, rescan result, negative test, monitoring confirmation, rollback, exception, and the condition that reopens the incident.
Produce a technical incident/finding report with reproducible evidence, queries, timeline, affected scope, severity rationale, actions, owner, due date, verification, limitations, and references to sanitized artifacts.
Produce a two-paragraph executive summary leading with business risk and the decision/ask, plus a stakeholder update and shift handoff that use different detail but exactly the same facts and uncertainty.
Define four program metrics such as alert precision, mean time to triage, critical exposure age, and remediation verification rate. Give formula, scope, window, source, owner, target or interpretation, quality caveat, and how the metric could be gamed.
Run an after-action review covering detection gaps, control failures, evidence quality, response decisions, communications, remediation, process/tool improvements, owner, due date, validation, and recurrence indicators.
Crosswalk every event, finding, decision, response, verification, report, and metric artifact to the four CS0-004 domain IDs; flag uncovered topics and record the next practice decision.
Retained artifacts
Fictional environment brief, data-flow view, evidence catalog, and handling rules
Normal baseline plus three detection hypotheses/rules and triage criteria
Prioritized vulnerability inventory with remediation and exception queue
Incident intake, timeline, evidence-quality/hypothesis table, investigation plan, and containment decision
Eradication/recovery/closure plan and remediation verification package
Technical report, executive summary, stakeholder update, and shift handoff
Metric definitions, after-action record, four-domain crosswalk, and gap reflection
Review checklist
Environment, evidence, detections, vulnerabilities, incident, timeline, hypotheses, response, verification, reports, metrics, and after-action record form one internally consistent synthetic case.
Every conclusion states what evidence proves, supports, conflicts with, or cannot answer and records source, quality, limitation, confidence, and alternative explanation.
Priorities combine severity, exposure, exploitation, asset/data/business context, controls, dependencies, remediation, verification, and residual risk rather than CVSS alone.
No real target scan, malware, phishing, credential collection, exploitation, persistence, unauthorized telemetry, packet capture, production containment, or live response action occurred.
No real employer, person, account, domain, IP, hostname, device, event time, vulnerability, query, credential, client data, or undisclosed weakness remains in the packet.
Technical, executive, stakeholder, and handoff documents contain the same facts, uncertainty, impact, ownership, action, due date, verification, and limitations at appropriate detail.
All four CS0-004 domains map to at least one artifact; uncovered topics remain explicit gaps rather than implied completion.
The packet does not claim exam success, official CompTIA training, analyst employment, professional incident response, or a RoleMath credential.
Safety boundary: Use only synthetic evidence, read-only logs from a personally owned device, or scans of localhost/an isolated VM you own. Never scan, exploit, contain, collect telemetry from, or otherwise test an employer, school, ISP device, public service, shared network, or third-party system. Treat all findings and incident artifacts as sensitive and remove real identifiers.
Finish honestly
Completion, portfolio, and maintenance
Completion evidence
All four current CS0-004 domain modules have been covered and checked against CompTIA's official V4 page.
Every domain lab has a saved owned/isolated/synthetic artifact or clearly labeled accessibility alternative.
Every authored knowledge check has been attempted and each miss has a cited correction plus a fresh analyst scenario.
Any retiring CS0-003 sample questions have been labeled version context only and were not used to define current scope or memorized as an answer bank.
The synthetic analyst capstone passes evidence, detection, vulnerability, incident, verification, reporting, metrics, privacy, safety, consistency, and four-domain coverage review.
The learner has recorded remaining foundation and objective gaps plus a next decision; completion is not represented as an exam result, credential, analyst job readiness, or professional experience.
Portfolio candidates
A sanitized detection/baseline and evidence-quality packet
A context-rich vulnerability-prioritization and remediation queue
A synthetic incident timeline, hypothesis table, and containment decision
A remediation verification and closure record
Matching technical and executive reports plus metric definitions
An after-action reflection describing one corrected analytical assumption
Present the artifacts as self-directed CS0-004 analyst lab work. Do not call them SOC employment, professional vulnerability assessment, real incident response, official CompTIA training, or a RoleMath credential.
Freshness controls
Objective source checked 2026-07-10. Recheck objectives every 30 days and resources every 60 days.
Stop and re-verify when
CompTIA changes the active CySA+ exam code, V4/CS0-004 scope, domain, published weight, lifecycle, recommended-experience guidance, or CS0-003 retirement date.
A current V4 practice resource becomes available or an existing V3 sample, official page, scanner, log tool, CVE/exploitation source, or other resource changes URL, version, access, reuse, or authority.
Nmap, Greenbone/OpenVAS, operating-system logs, virtual-machine tooling, or a lab output materially changes or cannot remain owned/local/isolated and safe.
A detection, vulnerability, incident, reporting, metric, or capstone artifact no longer matches current CS0-004 or fails evidence-quality, privacy, accessibility, or beginner/intermediate walkthrough.
Any module, lab, check, resource mapping, phase, version statement, or capstone fails technical, source, ethics, safety, privacy, authorization, accessibility, recommended-experience, or claims review.
Skills measured
The official objective domains and their exam weight — titles & weights only, straight from the vendor’s exam objectives. CompTIA CySA+ (CS0-004) objectives
Our default advice is to study the heaviest-weighted domain first, because the published weights tell you where the exam spends its questions — and for CySA+ (CS0-004) the weights and the natural workflow point the same direction, so no exception is needed. Security Operations (34%) is both the heaviest domain and the analyst's daily reality, so it leads. Vulnerability Management (26%) comes next; it is the proactive half of the job and feeds naturally into what operations monitors. Incident Response and Management (24%) follows, because it is what you do once monitoring and scanning surface something real. Reporting and Communication (16%) finishes, because it is the step that turns everything the first three domains produce into decisions other people can act on — it makes the most sense once you have something worth reporting. So we suggest strictly heaviest-first: Security Operations, then Vulnerability Management, then Incident Response and Management, then Reporting and Communication. This is sequencing advice based on the published weights and how the topics build on each other, not a claim about the science of learning — if a different order fits how you think, use it. CySA+ is an intermediate, analyst-level credential; CompTIA positions it after foundational study such as Security+ and Network+, with a few years of hands-on security experience recommended (see the eligibility note on the official page). Career changers can absolutely study it, but treat Security+ as the on-ramp rather than starting here cold.
Start here — it is the heaviest domain on the CS0-004 outline at 34% and the analyst's day job. Give it your largest block of study time; the other three domains all describe work that flows out of what happens here.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA CySA+ (CS0-004) objectives
This is the biggest domain on the CS0-004 outline and the one that most closely matches what a security analyst actually does between crises: watch, understand, and reason about what is happening across an environment. Where Security+ taught you the vocabulary of security, CySA+ pushes you up a level to the analyst's daily practice — reading telemetry, recognizing normal so you can spot abnormal, and turning a flood of signals into a short list of things worth investigating. Its 34% weight is the outline's honest signal that this is the core of the job, which also makes it the most useful domain to study deeply if your goal is analyst work and not just the credential.
The center of gravity is understanding systems and networks well enough to notice when they misbehave. That means being fluent in the ordinary shape of things — what normal process activity, network traffic, user behavior, and log volume look like on a healthy system — because detection is fundamentally the act of comparing what you see against what you expect. An analyst who does not know what normal looks like cannot recognize an anomaly; they can only react to alerts someone else tuned. The domain expects you to reason across the layers where evidence lives: endpoint processes and their parent-child relationships, network connections and the protocols carrying them, and the identity layer of who authenticated where and when.
A large part of the domain is threat intelligence and how it sharpens detection. Raw indicators — a suspicious IP address, a file hash, a domain name — are only the surface. The analyst skill is understanding attacker behavior: the tactics and techniques adversaries reuse, and the frameworks (like the widely used MITRE ATT&CK knowledge base) that catalog those behaviors so defenders can map what they see to what attackers are known to do. Thinking in behaviors rather than in individual indicators is what lets you catch a variant you have never seen before, because attackers change their file hashes far more easily than they change their fundamental methods.
The domain also covers the tooling analysts live in. A SIEM (security information and event management platform) aggregates logs from across the environment and correlates them so that a failed login here, a privilege change there, and an odd outbound connection can be seen as one story rather than three unrelated blips. Around it sit endpoint detection agents, network monitoring, email and web security, and increasingly automation — SOAR-style orchestration that scripts the repetitive parts of triage so analysts can spend attention on judgment. You are not expected to master any single vendor's product; you are expected to know what class of tool answers a given question and to reason about the output such tools produce.
Detection engineering and analysis techniques round the domain out: writing and tuning the rules and queries that turn raw data into alerts, reducing false positives so real signals are not buried, and applying structured analysis — correlation, aggregation, trend analysis — to make sense of volume. The recurring theme is that more data is not automatically more insight. The valuable analyst is the one who can take a firehose of events and produce a defensible short answer to 'is this worth waking someone up for?' That judgment, more than any tool, is what this domain is training.
Study this domain by getting your hands into real telemetry rather than only reading about it. Narrate an analyst's morning: an alert fires, you check what the host is and who owns it, you pull the surrounding logs, you compare the behavior against what normal looks like on that system, and you map any suspicious activity to a known technique before deciding whether to escalate. The log-triage lab below has you do exactly this on your own machine — reading your own operating system's security and event logs and hunting for anomalies you can reason about. And read the official CS0-004 objectives page for the exact topic list; this explanation deliberately paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Learn it free
Official · Official exam objectives
CompTIA CySA+ (CS0-004 / V4) exam objectives (certification page)The exam's own topic list for this domain — read its Security Operations section directly rather than relying on any summary, including ours. Confirm you are studying CS0-004, not the retiring CS0-003. (captured 2026-07-08)
Vetted independent · Free official framework (MITRE)
MITRE ATT&CK — adversary tactics and techniques knowledge baseThe behavior-focused framework this domain leans on for threat intelligence — free to browse, and the reference behind mapping observed activity to known techniques. (captured 2026-07-08)
Lab: read your own security and event logs and hunt for anomalies
Do the analyst's core skill on a system you own: open your operating system's security and event logs, learn what normal looks like, then filter for the events that matter — failed logins, privilege changes, service and process activity — and reason about whether anything looks anomalous. This is monitoring and detection in miniature, on your own machine only.
Free tools
Windows: Event Viewer — built into every Windows install, no download; optional PowerShell (Get-WinEvent), also built in
macOS: Console.app and the log command — both built into macOS Terminal, no download
Linux: journalctl (systemd) or the files under /var/log (for example /var/log/auth.log) — built into virtually every distribution
Optional: a plain-text file to note the event IDs and patterns you find
Steps
Open your log viewer. Windows: press the Start button, type 'Event Viewer', and open it. macOS: open Console from Applications > Utilities. Linux: open a terminal and run journalctl (or open /var/log/auth.log in a text viewer).
Find the security/authentication log first. Windows: expand 'Windows Logs' > 'Security'. macOS: in Console, use the search bar to filter for 'authentication' or 'login'. Linux: journalctl -u ssh or view /var/log/auth.log. This is where sign-ins and permission changes are recorded.
Read a handful of recent successful sign-in events to learn what normal looks like: your own account, at times you were actually using the machine, from your own device. Note the fields an analyst cares about — account name, time, source, and the event ID or type. Establishing normal is the whole foundation of detection.
Now filter for failed sign-ins. Windows: in the Security log, filter for Event ID 4625 (an account failed to log on). macOS: search Console for 'failed'. Linux: grep-style search auth.log for 'Failed password' or run journalctl | Select-String is not needed — use journalctl and read the failed-auth lines. A few failures from your own typos are normal; a burst of them, especially for accounts that do not exist, is the pattern that would matter in a real environment.
Look at privilege and account-management events. Windows: filter the Security log for Event ID 4672 (special privileges assigned to a new logon) and 4720/4726 (a user account was created/deleted). macOS/Linux: search for 'sudo', 'group', or account-creation entries. Ask of each: did I do this, and does it make sense at this time?
Switch to the system/application log (Windows: 'Windows Logs' > 'System'; macOS: Console system messages; Linux: journalctl -p err) and skim for services or processes starting, stopping, or crashing. Notice the difference between routine noise (updates, scheduled tasks) and anything you cannot explain.
Pick one event you did not immediately recognize and investigate it like an analyst: read its full detail, note the timestamp, and correlate it against what else happened in the same minute. Most 'unknown' events turn out to be benign background activity — and learning to confirm that quickly is exactly the triage skill the exam tests.
Write two or three sentences summarizing what 'a normal hour' looks like on your machine and which one event type you would most want an alert on if it spiked. That written baseline is the seed of a detection rule.
Optional (Windows): open PowerShell and run Get-WinEvent -LogName Security -MaxEvents 20 to see the same events as structured data you could filter or script against — a glimpse of how analysts query logs at scale rather than clicking through them.
What you should see
A readable timeline of your own machine's activity: successful sign-ins that match when you were actually using it, occasional benign failed logins from typos, routine service and update events, and — importantly — nothing you cannot eventually explain. The real skill you should feel developing is the contrast between the ordinary background hum and anything that stands out from it, because detection is that contrast made systematic.
This lab practices the log analysis, baselining, and anomaly-detection skills that Domain 1 (Security Operations) of the official CS0-004 objectives covers among its monitoring and detection topics — see the official objectives page for the exam's own wording.
Stay safe & legal: Read only the logs on a computer you personally own. Viewing your own system's logs is completely safe and changes nothing. Never access, collect, or analyze logs from a system you do not own or lack explicit authorization to examine — reading other people's security telemetry without permission can be illegal, and on a work machine it belongs to your employer's process, not to a personal study exercise. Do not disable, clear, or alter security logs; simply read them.
Check yourself
4RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 2 of 4 · domain 2 · 26% of the exam
Vulnerability Management
Second in our suggested order and the second-heaviest domain at 26%. It is the proactive half of the analyst's job — finding and prioritizing weaknesses before an attacker does — and it feeds directly into what the operations domain monitors.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA CySA+ (CS0-004) objectives
This is the proactive domain: instead of waiting for an alert, you go looking for the weaknesses an attacker could exploit and get them fixed first. At 26% it is the second-heaviest slice of CS0-004, and it reflects a large part of what analysts actually spend their weeks on — running scans, making sense of the results, and shepherding the important fixes through to completion. The center of the domain is not the scanner itself but the judgment around it: which of the hundreds of findings actually matter, in what order, and how do you get them remediated without breaking the business.
Start with the lifecycle, because vulnerability management is a repeating cycle, not a one-time event. You identify assets (you cannot protect what you do not know you have), scan them for known weaknesses, analyze and prioritize what the scan finds, remediate or mitigate, and then verify the fix actually took — before the cycle begins again. Each stage has traps the exam probes: incomplete asset inventories that leave systems unscanned, scans configured too narrowly to be useful, fixes that were reported as done but never verified. The lifecycle framing is what turns a pile of scanner output into an ongoing program.
A major skill is reading scan output critically. Scanners produce findings, but findings are not the same as risk. The domain expects you to understand scoring systems — most importantly CVSS (the Common Vulnerability Scoring System), which rates a vulnerability's severity on a numeric scale — while also understanding why a raw score is only the starting point. A high-severity flaw on an isolated test box may matter less than a medium-severity flaw on an internet-facing server holding customer data. Analysts also learn to spot false positives (the scanner flagged something that is not actually exploitable here) and false negatives (it missed something), because trusting scan output blindly is one of the fastest ways to waste a remediation team's time.
Prioritization is the heart of the domain and the thing the exam pushes hardest, because in the real world there is never enough time to fix everything at once. Good prioritization blends several inputs: the technical severity score, whether the flaw is actually being exploited in the wild right now (threat intelligence turns a theoretical risk into an urgent one), how exposed the affected asset is, and how critical that asset is to the business. Weighing those together to produce a defensible 'fix these five first' list is a genuinely analytical skill — and it is exactly the kind of reasoning CySA+ is built to certify.
The domain also covers the softer machinery that makes remediation actually happen: coordinating with the teams who own the systems, choosing between a full fix and a temporary mitigation (a compensating control or a configuration change) when patching now is not possible, handling the awkward cases of software that cannot be patched, and tracking exceptions where a risk is knowingly accepted for a documented reason. Special contexts get attention too — cloud and web-application weaknesses behave differently from a classic server flaw, and the analyst is expected to reason about each rather than apply one playbook everywhere.
Study this domain by running the cycle yourself on something you own. The lab below walks you through a free vulnerability scan against your own machine or a local virtual machine, reading what it reports, and — critically — thinking about how you would prioritize the findings rather than just collecting them. That prioritization step is where the real learning is. And as everywhere on this track, read the official CS0-004 objectives page for the authoritative topic list; our explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Lab: scan your OWN machine with a free vulnerability scanner and prioritize the findings
Run a genuine vulnerability scan against a system you own — your own localhost or a local virtual machine — using a free scanner, read what it reports, and practice the domain's central skill: turning raw findings into a prioritized 'fix these first' list. The scan is the easy part; the prioritization is the point.
Free tools
Nmap with service/version detection (the -sV flag) — free and open source, official builds for Windows, macOS, and Linux from the Nmap project; a lightweight way to enumerate open ports and running service versions on a host you own
Optional, for a fuller vulnerability scan: OpenVAS / Greenbone Community Edition — free and open source, best run inside a local virtual machine you control
Optional: a free local virtual machine (for example a fresh Linux VM in VirtualBox, which is free) to scan instead of your host, so you have a clearly-yours target
A plain-text file or spreadsheet to record and rank the findings
Steps
Decide on a target you unambiguously own. The safest choice is localhost (your own machine, address 127.0.0.1) or a virtual machine running on your own computer. Do not use anything else — this bright line matters more than any step below.
Install Nmap from the official Nmap project website (stable release for your OS). On Windows it includes a graphical front-end (Zenmap); the command line works the same on every platform.
Run a service-and-version scan against your own host: nmap -sV 127.0.0.1 (or the local IP of a VM you own). The -sV flag asks Nmap to identify which services are listening and what versions they are — the raw material of a vulnerability assessment.
Read the output as an analyst would: each open port is a potential doorway, and each service version is something you could look up for known weaknesses. Note anything you did not expect to be listening — an unexpected open port on your own machine is itself a finding worth understanding.
For a fuller picture, optionally stand up OpenVAS / Greenbone Community Edition inside a local virtual machine and point it at that same VM or your host. Let it complete a scan; it will produce findings with severity ratings. (Nmap alone is enough to learn the workflow if you prefer to keep the lab light.)
Take the findings — even just the open ports and service versions from Nmap — and build a small prioritization table. Columns: finding, affected service/asset, exposure (is this reachable from outside, or only local?), severity (use the CVSS rating if your scanner provides one, or a simple high/medium/low), and your reasoning.
For each finding, look up whether the service version has known vulnerabilities (the vendor's advisories or a public CVE listing) and note whether any are known to be actively exploited. Actively-exploited beats theoretically-severe every time — that is the prioritization lesson.
Sort your table so the finding that combines high severity, high exposure, and a business-critical asset sits at the top. Write one sentence justifying your number-one priority as if explaining it to the person who has to do the fix.
Decide a response for your top finding: patch/upgrade the service, disable it if nothing needs it, or mitigate (restrict it to localhost, add a firewall rule). On your own machine you can often actually close an unexpected open port — do it, then re-run the Nmap scan and confirm the port is gone. That verify step closes the lifecycle.
Optional: keep your prioritization table as a template. Reproducing this reasoning on demand — not memorizing CVSS numbers — is what the exam is really checking.
What you should see
A concrete list of open ports and service versions on a host you own, at least one item you did not expect (almost everyone finds one), and — most importantly — a small ranked table where your top priority is justified by combining severity, exposure, and asset importance rather than by severity alone. If you closed an unexpected port and confirmed it gone on a re-scan, you have run one full turn of the vulnerability-management lifecycle end to end.
This lab practices the scanning, finding-analysis, CVSS-informed prioritization, and remediation-verification skills that Domain 2 (Vulnerability Management) of the official CS0-004 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: Scan ONLY systems you personally own — your own localhost or a virtual machine running on your own computer. This is the single most important rule in security work: running a vulnerability or port scan against a system you do not own or lack explicit written authorization to test can be illegal and can get you fired or prosecuted, even if you meant no harm and nothing breaks. Never point these tools at your employer, your school, a public website, an ISP router, or any host that is not unambiguously yours. When in doubt, scan localhost or a VM and nothing else.
Check yourself
3RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 3 of 4 · domain 3 · 24% of the exam
Incident Response and Management
Third in our suggested order at 24%. It is what you do once monitoring and scanning surface something real, so it reads most clearly after the operations and vulnerability domains that feed it.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA CySA+ (CS0-004) objectives
This is the 'something is actually wrong — now what?' domain. When monitoring surfaces a real threat or a scan reveals active exploitation, incident response is the disciplined process that turns alarm into orderly action. At 24% it is a substantial slice of CS0-004, and it rewards process thinking: the exam is less interested in whether you can name a tool and more interested in whether you know what to do first, second, and third when the pressure is on and mistakes are costly.
The backbone is the incident-response lifecycle, a script the whole industry roughly shares. You prepare in advance — plans, contacts, tooling, and practice — so that when an incident hits, you are executing a rehearsed process rather than improvising. You detect and analyze to confirm something real is happening and understand its scope. You contain it so it stops spreading (isolating an affected host, disabling a compromised account) while being careful not to tip off the attacker or destroy evidence prematurely. You eradicate the root cause, recover normal operations, and then — the step organizations skip at their peril — conduct a lessons-learned review that feeds improvements back into preparation. CySA+ expects you to know this sequence cold and to reason about what belongs in each phase.
Preparation is more than paperwork, and the exam treats it seriously. It includes the incident-response plan itself, defined roles and an escalation chain (who decides, who is called, who talks to whom), communication plans, and the playbooks that spell out the standard moves for common incident types. A recurring theme is that decisions made calmly in advance are far better than decisions made in panic — which is precisely why writing a runbook before an incident, the skill this domain's lab practices, is such high-leverage preparation.
Detection and analysis deepen what the operations domain introduced. Here you are confirming and characterizing an incident: determining what happened, how far it spread, what data or systems are affected, and what the attacker did. This is where just enough digital forensics matters — collecting evidence in the right order (volatile data like memory before data on disk), preserving it without altering it, and maintaining a documented chain of custody so it holds up if the incident becomes a legal matter. You are not training to be a forensic examiner; you are training not to destroy evidence while trying to be helpful, which is a distinction the exam cares about.
Containment, eradication, and recovery carry their own judgment calls the domain expects you to weigh. Fast containment stops the bleeding but can alert the attacker or lose evidence; careful containment preserves more but gives the intruder more time. Eradication has to remove the actual root cause, not just the visible symptom, or the incident recurs. Recovery restores service while verifying the environment is genuinely clean before reconnecting it. And throughout, coordination and communication run in parallel — keeping stakeholders informed, meeting any legal or regulatory reporting obligations, and documenting decisions as you go so the after-action review has something to work with.
Study this domain by building the artifact analysts actually use: a runbook. The lab below has you write an incident-response runbook for a simulated alert — turning the abstract lifecycle into a concrete, ordered set of steps for a specific scenario. Writing one forces you to confront the sequencing and decision points the exam tests, and it is exactly the kind of preparation that makes a real incident survivable. Read the official CS0-004 objectives page for the authoritative topic list; our explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Vetted independent · Free official publication (NIST)
NIST SP 800-61 — Computer Security Incident Handling GuideThe widely-referenced public guide behind the incident-response lifecycle this domain teaches — free to read and a good model for the phases in your runbook. (captured 2026-07-08)
Lab: write an incident-response runbook for a simulated alert
Turn the incident-response lifecycle from a list you can recite into a concrete, ordered runbook for a specific simulated alert. You will decide what to do first, what evidence to preserve, when to contain, and who to notify — the sequencing and judgment the exam actually tests. It is a paper exercise; nothing is attacked and nothing is touched but your own document.
Free tools
Any text editor or word processor — free (built-in Notepad/TextEdit, or free LibreOffice Writer / Google Docs); paper works fine too
Optional: a free flowchart tool (for example diagrams.net in a browser) if you prefer to sketch the decision flow visually
Steps
Read the simulated alert (authored by RoleMath for this exercise — it is not from any exam): 'At 02:14, the SIEM raises a high-severity alert. An internal workstation (owned by an employee in accounting) has, in the last twenty minutes, made repeated outbound connections to an external address flagged by threat intelligence, and an antivirus agent on that workstation logged, then failed to quarantine, a suspicious executable. The user is asleep; it is the middle of the night.'
Set up your runbook document with a header naming the scenario and the six lifecycle phases as sections: Preparation (assumptions), Detection & Analysis, Containment, Eradication, Recovery, and Lessons Learned.
Under Detection & Analysis, list the first questions you would answer to confirm this is a real incident and understand its scope: What is this host and who owns it? Is the flagged address genuinely malicious or a false positive? What else has this host contacted? Did the executable run? Order them — what do you check first, and why?
Decide your containment step and its timing. Would you isolate the workstation from the network immediately, or observe briefly first? Write your decision and one sentence of reasoning that acknowledges the trade-off (fast containment stops spread but may alert the attacker and lose volatile evidence).
Before containment wipes anything, note what evidence you would preserve and in what order — volatile first (memory, active network connections) before non-volatile (disk) — and state that you would document a chain of custody. This is the 'don't destroy evidence while helping' discipline.
Under Eradication, write what removing the root cause would involve (not just deleting the file, but determining how it arrived and whether it spread or created persistence) and how you would confirm the cause is actually gone.
Under Recovery, describe how you would return the workstation to service only after verifying it is clean, and what you would monitor afterward to make sure the threat does not return.
Write the communication and escalation plan that runs in parallel: who gets called at 02:14 (and who does not need waking), who authorizes disconnecting an executive's or a finance user's machine, and any reporting obligation if customer or financial data was exposed.
Finish with Lessons Learned: list two or three questions the after-action review should ask (How did the executable get past the filter? Why did quarantine fail? Should this host have been able to reach that address at all?) so the incident improves your preparation next time.
Re-read your runbook and pressure-test the ordering: could someone who is not you follow it at 2 a.m. under stress? If any step assumes knowledge you did not write down, add it. Clarity under pressure is the entire value of a runbook.
What you should see
A one-to-two-page runbook that walks the full lifecycle for this specific alert in a clear order, makes an explicit containment-timing decision with a stated trade-off, preserves evidence before destroying it, and names who to call and who authorizes disruptive actions. If a stressed colleague could execute it at 2 a.m. without needing to phone you, it is doing its job — and you have internalized the sequencing this domain tests.
This lab practices the incident-response lifecycle, evidence-handling, containment-decision, and coordination skills that Domain 3 (Incident Response and Management) of the official CS0-004 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: This is entirely a paper exercise on a fictional scenario — nothing is scanned, attacked, or touched but your own document. If you adapt the template to your real workplace, treat the resulting runbook as sensitive: a document describing how an organization would respond to a breach, and where its gaps are, is itself confidential information. Never test real incident-response actions against systems you do not own.
Check yourself
3RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 4 of 4 · domain 4 · 16% of the exam
Reporting and Communication
Last in our suggested order at 16% — the lightest domain, but do not mistake light for optional. It is the step that turns everything the first three domains produce into decisions other people can act on, and it makes the most sense once you have findings worth reporting.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. CompTIA CySA+ (CS0-004) objectives
This is the domain that recognizes an uncomfortable truth: the best analysis in the world is worthless if nobody acts on it, and people act on what they understand. Reporting and Communication covers how analysts translate technical findings into information that different audiences — remediation teams, managers, executives, sometimes auditors or regulators — can actually use. At 16% it is the lightest domain on CS0-004, but it is deliberately included in the baseline because CompTIA treats communication as a core analyst competency, not a soft skill you pick up later. For career changers from writing, business, project-management, or customer-facing backgrounds, this is often the friendliest terrain on the exam.
The spine of the domain is vulnerability and incident reporting: producing the written and verbal outputs that move work forward. A vulnerability report is not just a dump of scanner output; it is a prioritized, contextualized account of what was found, why it matters, and what should be done about it. An incident report captures what happened, what was affected, how it was handled, and what changes should follow. The exam expects you to know what belongs in these reports and, crucially, how to pitch them for the reader — because the same finding must be explained very differently to the engineer who will fix it than to the executive who will fund the fix.
Audience awareness is the heart of the domain, and it is a genuine analytical skill rather than a matter of politeness. A technical audience needs specifics — affected systems, versions, evidence, exact remediation steps. An executive audience needs the business translation — what is the risk to the organization, how bad, how likely, what will it cost to address versus to ignore, and what decision is being asked of them. The classic vehicle for the second audience is the executive summary: a short, jargon-light, decision-oriented framing that sits at the top of a longer technical report. Being able to write both layers, and to move fluidly between them, is exactly what this domain certifies — and what makes an analyst valuable far beyond their technical depth.
The domain also covers communicating throughout an incident, not only after it. Timely, accurate updates to stakeholders during a live incident; clear escalation when a situation exceeds your authority; and honest status reporting that neither downplays a serious problem nor cries wolf. It touches on the obligations that surround reporting too — internal notification requirements and, where they apply, legal or regulatory reporting duties — because part of an analyst's job is knowing when a finding must be reported to someone outside the immediate team, and doing it correctly and on time.
Finally, the domain closes the loop back to the whole program. Metrics and key performance indicators turn security activity into something leadership can track — how quickly incidents are detected and contained, how vulnerability backlogs are trending, whether the program is improving. Good reporting is what makes a security program legible to the people who fund it, and legibility is what keeps it funded. The connecting thread across the domain is that a finding nobody understood, a report nobody could act on, and a metric nobody tracked all fail in the same quiet way an ignored alert does.
Study this domain by writing, because it rewards practice more than memorization. Take any finding — ideally one from your own vulnerability-management lab earlier on this track — and write it up twice: once as a technical report for the person who will fix it, and once as a two-paragraph executive summary for the person who will decide whether to. The lab below walks you through exactly this. Learning to hold both audiences in mind is the skill, and it transfers to almost every job you will ever have. Read the official CS0-004 objectives page for the authoritative topic list; our explanation paraphrases the domain's scope in our own words rather than reproducing CompTIA's.
Lab: write an executive summary of a security finding
Practice the domain's central skill: take one technical security finding and communicate it to two very different audiences — a precise technical write-up for the team that will fix it, and a short, jargon-light executive summary for the person who will decide whether to. Learning to move between those layers is what this domain certifies.
Free tools
Any text editor or word processor — free (built-in Notepad/TextEdit, or free LibreOffice Writer / Google Docs)
Optional but ideal: a real finding from the Vulnerability Management lab earlier on this track (a scan result from your own machine), so you are reporting on something you actually observed
Steps
Choose one finding to report on. Best case: reuse an open-port or outdated-service finding from your own machine in the Vulnerability Management lab. If you skipped that lab, use this RoleMath-authored example: 'A public-facing web server is running a version of its software with a known, actively-exploited vulnerability that could let an attacker run commands on it; a patch is available.'
First, write the TECHNICAL report — for the engineer who will fix it. Include: the affected system, the specific finding and its severity (a CVSS rating if you have one), the evidence (how it was discovered), the concrete remediation steps, and how the fix will be verified. Be precise and specific; assume the reader knows the technology.
Now write the EXECUTIVE SUMMARY of the same finding — no more than two short paragraphs, for a manager or executive with no time and little technical background. It must answer four questions plainly: What is the risk to us? How bad and how likely is it? What does it cost to fix versus to ignore? What decision or resource do you need from the reader?
In the executive summary, translate every piece of jargon. 'Remote code execution' becomes 'an attacker could take control of the server'. 'CVSS 9.8' becomes 'critical severity'. If a term cannot be removed, define it in the same sentence. The test: could a smart person with no security background read it once and know what to do?
Lead the executive summary with the bottom line, not the background. Executives read top-down and may stop after two sentences — put the risk and the ask first, then the supporting detail. This inverted structure is the single most common gap in analyst writing.
State the ask explicitly. A report that describes a problem but never says what it needs — approval to patch during business hours, budget, a decision to accept the risk — forces the reader to guess, and guessing readers do nothing. Name the decision.
Read both versions back to back and check the through-line: they describe the SAME finding at different altitudes, and nothing in the executive summary contradicts or overstates the technical report. Overstating to get attention destroys the trust that makes future reports effective.
Pressure-test the executive summary on length and tone: if it is longer than half a page, cut it; if it uses a term your non-technical friend would not know, replace it; if it sounds alarmist rather than measured, calm it. Calm, specific, and short beats dramatic every time.
Optional: write one sentence of the 'metric' framing — how you would express this finding as part of a trend leadership could track (for example, 'this is the third critical internet-facing finding this quarter'). That is the program-level reporting this domain closes with.
What you should see
Two documents describing one finding at two altitudes: a precise, specific technical report an engineer could act on directly, and a two-paragraph executive summary that leads with the risk and the ask, contains no untranslated jargon, and could be understood by a non-technical decision-maker in a single read. The gap between how those two documents sound — same facts, different altitude — is exactly the skill this domain is testing.
This lab practices the vulnerability/incident reporting, audience-appropriate communication, and executive-summary skills that Domain 4 (Reporting and Communication) of the official CS0-004 objectives covers — see the official objectives page for the exam's own wording.
Stay safe & legal: This is a writing exercise on your own findings or a fictional example — it touches nothing but your own document. If you report on a real finding from a system you own, keep the write-up private: a document describing an exploitable weakness and how to reach it is sensitive information. Never report on, or probe, systems you do not own to generate material for this lab.
Check yourself
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Skills you’ll build
Studying CompTIA CySA+builds transferable skills that carry across employers and platforms, not just toward this one exam. Each has a free, source-cited RoleMath primer — what it is, a step-by-step free learning path, clearly labeled free resources, and a safe hands-on exercise:
Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.
Current exam version: CS0-004 (the current CySA+ exam, launched 2026-06-23). The previous CS0-003 version is retiring 2026-12-22 — study against CS0-004 and confirm which version you are registered for. Official CompTIA CySA+ (V4) certification page
Recommended experience (no formal prerequisite): No prerequisite is stated on the official page; CompTIA recommends about 4 years of hands-on experience in a security-analyst role (for example SOC analyst or vulnerability analyst), typically after foundational study such as Security+ and Network+. Recommended, not required. Official CompTIA CySA+ (V4) certification page
A free, source-cited study companion built on CompTIA's published CS0-004 exam objectives — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by CompTIA.