CySA+ Reporting and Communication: 72 practice questions

12 of the 72 Reporting and Communication questions in the Certsqill CySA+ bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for CySA+? Take the free 5-min readiness check →

1. Present business risk exposure using risk-tiered groups: Which presentation approach BEST serves a board-level

1. Present business risk exposure using risk-tiered groups, estimated breach likelihood, and potential financial/regulatory impact — focus the discussion on the 12 Critical and 89 High findings ✓

   Correct. Board members require business-context framing: financial exposure, regulatory risk, and strategic impact. They do not need technical CVE details. Focusing on Critical and High findings with business impact language (potential cost of breach, compliance fines, reputational damage) provides actionable governance-level information.
2. Present the full list of 847 vulnerabilities with CVSS scores and CVE IDs to demonstrate the scope of the problem

   Incorrect. Presenting raw technical data to a board audience is ineffective and counterproductive. Boards make strategic decisions; they need business risk translation, not vulnerability databases. This approach typically results in information overload and loss of audience engagement.
3. Only present the 12 Critical vulnerabilities to maintain focus and avoid alarming the board with lower-priority items

   Incorrect. Omitting the 89 High vulnerabilities gives an incomplete risk picture. While selectivity is appropriate, a board needs to understand the full risk posture. The 89 High vulnerabilities represent significant risk and should be included in the presentation.
4. Delegate the presentation to the IT operations team, as board members are not equipped to understand security vulnerabilities

   Incorrect. Security analysts are responsible for translating technical findings into business language for leadership. Delegation does not fulfill the analyst's communication responsibility. The board does not need to understand technical details — the analyst's job is to translate them into terms the board can act on.

Board presentations require business-risk framing: financial exposure, regulatory impact, and strategic risk — not raw CVE lists.

2. Mean time to remediate by severity: Which set of KPIs is BEST?

1. Mean time to remediate (MTTR) by severity, percentage of Critical/High findings remediated within SLA, and reduction in attack surface over time ✓

   Correct. These three KPIs measure outcomes (risk reduction) and operational effectiveness (remediation speed and SLA compliance). They are outcome-focused metrics executives can interpret as indicators of program maturity and risk posture improvement.
2. Number of scans run per week, number of CVEs identified, and number of vulnerability reports produced

   Incorrect. These are activity metrics (inputs), not effectiveness metrics (outcomes). Scanning frequently and finding many CVEs does not indicate the organization is remediating them or reducing risk. Executive leadership needs to understand risk outcomes, not scan volumes.
3. Number of analysts on the vulnerability management team, budget spent on scanning tools, and number of systems in scope

   Incorrect. These are resource/input metrics, not performance metrics. They describe program scale, not program effectiveness. A large team with high budget that remediates nothing is not effective.
4. CVSS score distribution, number of zero-day vulnerabilities identified, and number of vendor advisories reviewed

   Incorrect. CVSS distribution describes the vulnerability landscape, not remediation effectiveness. Zero-days identified and advisories reviewed are valuable operational activities but do not measure program outcomes (remediation rate, risk reduction).

Effective vulnerability management KPIs measure outcomes: remediation speed (MTTR), SLA compliance rates, and measurable attack surface reduction — not scan activity volumes.

3. The email security policy has not been reviewed in 3 years: → Email security policy has not been reviewed in 3

1. The email security policy has not been reviewed in 3 years, allowing email security controls to become outdated ✓

   Correct. The 5 Whys methodology traces the causal chain to its origin. The final 'Why' identifies the systemic/process root cause: an unreviewed security policy allowed technical controls (DMARC, DKIM, domain reputation filtering) to fall out of date. This is the root cause because fixing it prevents the downstream failures.
2. The employee clicked a phishing link, which initiated the credential theft chain

   Incorrect. The employee clicking is a symptom (the proximate cause), not the root cause. Root cause analysis is designed to look past proximate causes to systemic failures. Blaming the employee click does not produce actionable organizational improvements.
3. The phishing email bypassed spam filters, allowing it to reach the user's inbox

   Incorrect. Spam filter bypass is also a symptom — it answers 'what happened' at one level of analysis. The 5 Whys technique requires continuing the analysis until a systemic/process root cause is identified, not stopping at a technical symptom.
4. The organization lacks security awareness training, which would have prevented the employee from clicking

   Incorrect. Security awareness training is a valid compensating control but is not identified as a factor in the 5 Whys chain provided. Introducing it as 'root cause' would be outside the documented analysis. Even with perfect training, the lack of technical controls (DMARC, domain filtering) is the identified systemic gap.

The 5 Whys traces the causal chain to the systemic root: a 3-year-old unreviewed email security policy that allowed technical controls to become outdated.

4. High severity: Which finding requires MOST immediate attention?

1. High severity — 71% is the lowest compliance rate and means 29% of High findings are exceeding the 30-day SLA, representing a significant and persistent vulnerability exposure ✓

   Correct. The High severity tier has the lowest SLA compliance rate (71%). With a 30-day SLA, 29% of High findings are taking more than 30 days to remediate. Given the volume of High findings (typically 5-10x the count of Critical), this represents a large number of unpatched vulnerabilities. The combination of poor compliance rate and high finding volume makes this the priority process improvement target.
2. Critical severity — any miss on Critical findings is unacceptable, making the 87% rate the top priority

   Incorrect. While an 87% on-time rate for Critical findings means 13% are being missed (serious), the 71% rate for High severity represents a worse overall process failure by percentage and likely affects far more vulnerabilities by count. Both need attention, but the High tier's worse compliance rate is the priority for process improvement.
3. Medium severity — the 94% rate is close to 100% but still means 6% of Medium findings exceed SLA

   Incorrect. A 94% compliance rate for Medium findings (90-day SLA) is performing well. A 6% miss rate at medium severity with a 90-day SLA is significantly less concerning than a 29% miss rate at high severity with a 30-day SLA.
4. All three tiers need equal attention since none has 100% SLA compliance

   Incorrect. Risk-based prioritization applies to process improvement as well as vulnerability remediation. Equal treatment of all compliance gaps ignores the materially different risk levels between a 71% High compliance rate and a 94% Medium compliance rate.

The High severity tier's 71% compliance rate — the lowest — means 29% of High vulnerabilities exceed their 30-day SLA, representing the largest process gap requiring improvement.

5. Decline to comment and immediately escalate: What is the MOST appropriate response by the analyst?

1. Decline to comment and immediately escalate to the communications/PR team and legal counsel, informing them that media inquiry has been received ✓

   Correct. Security analysts are not authorized spokespersons for media relations, especially during an active breach with legal and regulatory implications. The correct response: (1) do not confirm, deny, or speculate, (2) immediately escalate to PR/communications and legal, (3) document the inquiry (contact information, questions asked, time). Media inquiries during breaches can trigger regulatory notification clocks and must be handled by authorized personnel.
2. Provide the journalist with a preliminary statement confirming the investigation is ongoing to demonstrate transparency

   Incorrect. Unauthorized confirmation of a breach can: (1) trigger premature regulatory notification clocks (GDPR 72-hour requirement), (2) impact ongoing investigation (alert threat actor, compromise evidence), (3) expose the organization to legal liability, (4) contradict the official communications strategy. Only designated spokespersons may make public statements.
3. Deny any knowledge of a security incident to protect the investigation

   Incorrect. Knowingly providing false statements to the media creates additional legal liability and ethical issues. The correct response is to decline comment and refer to official channels — not to affirmatively deny knowledge.
4. Share technical details of the incident to demonstrate the organization is taking security seriously

   Incorrect. Sharing technical details: (1) may compromise active investigations by revealing detection methods, (2) could help the threat actor understand what is and isn't known, (3) may create regulatory/legal complications, (4) violates information classification requirements. Technical incident details are need-to-know.

Analysts are not authorized media spokespersons. The correct response is to decline comment and immediately escalate to PR/communications and legal.

6. Implement a verification scan as a mandatory closure: Which process improvement BEST addresses this recurring

1. Implement a verification scan as a mandatory closure requirement — remediation tickets cannot be closed as 'resolved' until a follow-up vulnerability scan confirms the vulnerability is no longer present on the affected system ✓

   Correct. Requiring scan verification before ticket closure creates an objective, automated quality gate that prevents premature closure. This is the industry-standard approach: open ticket → remediation action → verification scan → confirmed absence of vulnerability → ticket closed. It removes reliance on self-attestation.
2. Send weekly email reminders to IT teams to accurately report remediation status

   Incorrect. Email reminders address awareness, not accountability. If teams are closing tickets inaccurately, reminders reinforce the same problematic behavior without structural enforcement. A process control (verification scan requirement) is needed, not a communication prompt.
3. Increase the frequency of vulnerability scans from weekly to daily to detect re-opened vulnerabilities faster

   Incorrect. More frequent scanning detects the problem faster but doesn't prevent it. If tickets continue to be prematurely closed, daily scans will simply document the failure more frequently without reducing it. The root cause (premature closure without verification) must be addressed.
4. Remove the IT teams' ability to close vulnerability tickets and transfer all closure decisions to the security team

   Incorrect. Removing IT teams from the closure process creates operational bottlenecks and adversarial relationships. The security team cannot verify every remediation action firsthand. The solution is a scalable automated verification process, not centralized manual control.

A mandatory verification scan as a ticket closure prerequisite creates an objective process control that prevents premature closure without evidence of actual remediation.

7. Root cause analysis findings and specific recommendations: Which element is MOST important to include to suppo

1. Root cause analysis findings and specific recommendations to prevent recurrence ✓

   Correct. The primary strategic value of an incident report beyond documentation is its actionable content for improvement. Root cause analysis identifies the systemic failure that enabled the incident; recommendations provide the roadmap for prevention. Without these, the report is historical documentation rather than an improvement tool.
2. A detailed technical timeline of every command executed by the attacker

   Incorrect. Technical timelines are valuable for the technical appendix but are not the most important element for 'future prevention and response improvements.' The root cause analysis and recommendations are what drive organizational improvement — technical timelines provide supporting evidence.
3. The names and contact information of all analysts who participated in the response

   Incorrect. Personnel involvement is documented for accountability and knowledge management purposes, but it does not contribute to prevention or response improvements. This is administrative information, not strategic improvement content.
4. Cost estimates for the hardware and software used during incident response

   Incorrect. Cost tracking is valuable for budget justification and insurance purposes but does not directly support future prevention. The question asks specifically about supporting prevention and response improvements.

Root cause analysis and prevention recommendations are the most strategically valuable components of an incident report — they turn historical documentation into an improvement roadmap.

8. Reduction in mean time to detect and mean time to respond: Which metric BEST captures overall security posture

1. Reduction in mean time to detect (MTTD) and mean time to respond (MTTR) to security incidents, combined with a reduction in the percentage of Critical/High vulnerabilities exceeding remediation SLA ✓

   Correct. MTTD and MTTR directly measure detection and response capability improvement. SLA compliance for Critical/High vulnerabilities measures vulnerability management program maturity. Together, these outcome metrics capture both proactive (vulnerability management) and reactive (incident response) dimensions of security posture improvement.
2. Increase in the total number of security alerts generated by the SIEM over 12 months

   Incorrect. More alerts indicate increased detection capability or increased noise, not improved security posture. An increase in alerts could mean the environment is getting worse (more attacks), or the detection is getting better (same attacks now visible), or there's more false positives. Context is required to interpret alert volume trends.
3. Increase in the total security budget allocated over the 12-month period

   Incorrect. Budget increase is an input metric. Security posture improvement is an outcome. Organizations can spend more money without improving their security posture. Outcomes like MTTD, MTTR, and vulnerability SLA compliance measure the result, not the investment.
4. Number of security certifications obtained by security team members during the year

   Incorrect. Staff certifications indicate skills development (an input metric) but do not directly measure security posture outcomes. A team with multiple certifications that still has poor MTTR has not demonstrably improved security posture.

MTTD and MTTR improvement (response capability) combined with vulnerability SLA compliance trends (proactive risk reduction) are the most comprehensive outcome metrics for security posture improvement.

9. Implement a validation scan workflow: Which approach BEST achieves this?

1. Implement a validation scan workflow: when IT marks a ticket as patched, an automated re-scan targets only that specific system and imports results into the ticket as closure evidence — creating objective proof without manual intervention ✓

   Correct. An automated targeted re-scan tied directly to ticket closure creates objective, non-accusatory evidence. The scan results speak for themselves — if the vulnerability is gone, the ticket closes automatically; if not, the ticket stays open with evidence. This removes the human conflict element while maintaining accountability through data.
2. Escalate the issue to the CISO and request disciplinary action against IT team members who falsely close tickets

   Incorrect. Escalation before establishing objective evidence and collaborative process is premature and creates organizational conflict. The question asks for a solution that provides objective evidence without conflict. Disciplinary action does not solve the process problem and damages working relationships.
3. Require IT team members to submit signed attestations confirming vulnerability remediation

   Incorrect. Signed attestations shift the burden to individuals but do not provide objective evidence of actual remediation. If the attestations are false, the organization now has a compliance and HR issue rather than a technical solution. Automated scan verification provides objective evidence that attestations cannot.
4. Accept IT's explanation that scan timing causes false persistence reports and adjust re-scan frequency to once per month

   Incorrect. 'Scan timing issues' as a persistent explanation for unpatched vulnerabilities is not credible at scale. Accepting this explanation without implementing verification allows the pattern of incomplete remediation to continue, creating ongoing risk. Monthly re-scan reduces verification frequency without addressing root cause.

Automated targeted re-scans triggered by ticket closure provide objective, non-accusatory evidence of remediation — removing human conflict while maintaining accountability through data.

10. Percentage of critical vulnerabilities remediated within: Which content is MOST appropriate for this executive

1. Percentage of critical vulnerabilities remediated within SLA, business risk exposure trend over time, and top three systemic risk themes. ✓

   Executive reports must frame risk in business terms. SLA compliance rates, trend lines showing whether risk is improving or worsening, and thematic risk drivers give board members the strategic view they need without technical detail.
2. A list of all CVEs discovered during the month sorted by CVSS base score, including affected hostnames and IP addresses.

   Raw CVE lists with hostnames are technical operational data appropriate for security engineers and patch teams, not for board-level consumption. Boards need aggregated, business-contextualized metrics.
3. Detailed Nessus scan output showing plugin IDs, vulnerability names, and solution text for each finding.

   Nessus raw output is a technical artifact for vulnerability analysts. Presenting this to a board would be inappropriate and unhelpful — it lacks business context and strategic framing.
4. A complete asset inventory with OS versions and patch levels for every server in the environment.

   Asset inventory detail belongs in operational dashboards for IT teams. This level of granularity is not useful to board members making strategic risk decisions.

Executive reports should present aggregated business risk metrics — SLA compliance, trend data, and key risk themes — rather than raw technical scan data.

11. Fishbone diagram: Which RCA tool BEST helps visualize how these contributing factors collectively led to the i

1. Fishbone (Ishikawa) diagram ✓

   A fishbone diagram visually maps multiple contributing causes across categories (people, process, technology) to a central problem (the ransomware incident), making it ideal for showing how layered failures combined to produce the outcome.
2. 5 Whys analysis

   The 5 Whys technique traces a single causal chain by repeatedly asking 'why' until reaching a root cause. It is less effective when multiple independent contributing factors converge — it works best for linear, single-path causation.
3. RACI matrix

   A RACI matrix defines roles and responsibilities (Responsible, Accountable, Consulted, Informed). It is a governance tool, not a root cause analysis technique for visualizing causal relationships.
4. Attack timeline reconstruction

   An attack timeline shows the sequence of attacker actions chronologically. While useful for understanding how the attack progressed, it does not specifically visualize how contributing organizational failures collectively enabled the incident.

A fishbone (Ishikawa) diagram maps multiple contributing causes across categories to a central problem, making it the best tool when multiple independent factors collectively cause an incident.

12. The SOC is meeting its response speed target but is: Which interpretation of these metrics is MOST accurate?

1. The SOC is meeting its response speed target (MTTR below goal) but is significantly underperforming on detection (MTTD 3x above target), suggesting a gap in monitoring coverage or alert tuning. ✓

   MTTR of 4 hours is under the 8-hour target — response is fast. MTTD of 72 hours versus a 24-hour target means threats go undetected for three times the acceptable period, indicating detection coverage or alert fidelity problems.
2. Both metrics are acceptable because the SOC is resolving incidents in under 8 hours, which minimizes business impact.

   MTTR being on target does not compensate for MTTD being 3x over target. Threats dwelling undetected for 72 hours cause significant damage before response even begins. Both metrics must be evaluated independently.
3. The high MTTD indicates the SOC has too many analysts and should reduce headcount to improve efficiency.

   MTTD is driven by detection coverage (SIEM rules, alert volume, tool visibility), not analyst headcount. Reducing staff would worsen MTTR and does not address detection gaps.
4. MTTR of 4 hours is too fast and suggests analysts are closing tickets without completing proper investigation.

   Meeting or exceeding MTTR targets is desirable. While quality of closure should always be reviewed, a low MTTR is generally a positive metric unless closure rates show systematic false-positive dismissals.

MTTD of 72 hours (3x the target) reveals a detection gap despite good MTTR; the SOC is responding quickly once it detects threats but is missing them for too long.

Other CySA+ domains

• Security Operations — 181 questions →
• Vulnerability Management — 132 questions →
• Incident Response Management — 114 questions →
• All 499 CySA+ questions →