CySA+ common mistakes
CySA+ · Understand the traps and how to avoid them.
Prioritizing remediation from the CVSS base score alone, such as patching a low-value lab host first while ignoring an internet-facing business-critical asset with a known exploited vulnerability.
Candidates memorize CVSS as a severity number and forget that risk depends on exposure, asset criticality, exploit likelihood, and compensating controls.
What to do instead
Practice ranking findings by contextual risk: known exploited status, exploit prediction, internet exposure, data sensitivity, business function, and existing controls. Be able to justify the priority in one sentence.
Treating every vulnerability scanner finding as confirmed exploitable and recommending emergency patching without validation.
Scanner output is often confused with proof of exploitability, and exam scenarios test whether the candidate distinguishes discovery from validation.
What to do instead
Separate discovery from validation. Know when to use authenticated scans, manual verification, exploit intelligence, or penetration testing, and when risk acceptance or mitigation is appropriate.
Selecting a log or telemetry source that cannot answer the question, such as using NetFlow to identify a malicious process name on an endpoint or antivirus logs to reconstruct lateral movement.
Candidates memorize tool categories but not the specific evidence each source contains.
What to do instead
For each scenario, ask what artifact would prove the claim: EDR process lineage, SIEM correlation, DNS logs, proxy logs, flow records, authentication logs, or file integrity monitoring. Match the evidence to the question.
Escalating every high-severity SIEM alert as a confirmed incident without triage, or closing an alert as a false positive after checking only one indicator.
Alert severity is mistaken for incident confirmation, and single-indicator reasoning replaces corroboration and scoping.
What to do instead
Triage by corroborating multiple indicators, checking asset criticality, determining scope, and applying policy. Distinguish false positive, benign true positive, and confirmed incident before escalation.
Jumping directly to eradication or recovery after detecting malware, such as deleting files or rebuilding a host before containment and scoping are complete.
Action bias and memorized cleanup steps cause candidates to skip phase order and lose evidence or miss additional compromised systems.
What to do instead
Follow the incident response lifecycle: contain first when needed, preserve evidence, scope the incident, eradicate the root cause, validate, recover, and conduct post-incident review. Know that the immediate first action depends on safety and policy.
Powering off a compromised machine or imaging the disk before collecting volatile memory and network state.
Normal IT troubleshooting habits conflict with forensic order of volatility, and candidates confuse containment with shutdown.
What to do instead
Apply order of volatility: capture memory, running processes, network connections, and other volatile data first when policy allows. Isolate the network without powering off, and document hashes and chain of custody.
Confusing containment with eradication, such as disabling a compromised account and declaring the incident resolved while attacker persistence remains.
The terms overlap in practice, and pressure to close an incident encourages premature resolution.
What to do instead
Define phase outputs explicitly: containment limits spread, eradication removes the actor and artifacts, recovery restores operations, and post-incident activity captures lessons learned. Verify persistence is removed before recovery.
Writing the same technical narrative for executives and analysts, burying business impact and required decisions under packet captures and command-line output.
Candidates answer what happened technically but not why it matters or what decision makers must do.
What to do instead
Tailor the report to the audience: executive summary with business impact, risk, and decisions needed; technical appendix with evidence, timeline, root cause, affected assets, and recommendations.
Omitting escalation and notification obligations when an incident involves personal data, regulated information, or third-party systems.
Candidates focus on technical response and forget legal, privacy, regulatory, management, and communication requirements.
What to do instead
Know the incident severity matrix, escalation paths, and legal or regulatory triggers. In scenarios, state who must be notified, who owns communications, and whether breach notification timelines apply.
Reporting vulnerability metrics inaccurately, such as equating the number of findings with risk or citing MTTR without defining start and stop points, then recommending 'patch everything' instead of measurable risk reduction.
Candidates misuse common security metrics and do not connect remediation reporting to business objectives.
What to do instead
Define each metric precisely, use trends and baselines, report remediation rates, exposure reduction, SLA compliance, and accepted risk. Tie recommendations to measurable risk reduction and business priorities.