CS0-004 reporting and communication

Reporting and Communication is the smallest CS0-004 domain at 16%, and it covers two objectives: reporting on vulnerability management, and reporting on security operations and incident response. The domain tests whether an analyst can turn findings into something a reader can act on: the right content, for the right audience, at the right time, with metrics that show whether the work is improving anything. Because it is short and non-technical in feel, it is the domain most often under-prepared.

4.1 Vulnerability management reporting and communication

CompTIA’s summary names reports, dashboards and escalation. The skill is matching the artefact to the reader.

A useful vulnerability report states scope (what was scanned and when), method (credentialed or not), findings ranked by risk rather than raw CVSS alone, the recommended action and an owner. It also records exceptions such as accepted risk or compensating controls, with an approver and an expiry date. See the CVSS prioritisation guide for how severity feeds ranking.

Escalation is triggered by criteria agreed in advance: an actively exploited vulnerability on an internet-facing asset, an SLA breached on a critical item, or a finding on systems holding regulated data. Escalation goes to the person who can authorise the action or accept the risk, not simply to a more senior analyst.

4.2 Security operations and incident response reporting

CompTIA’s summary lists incident documentation, post-incident reviews and metrics such as detection time, response time and remediation effectiveness.

Incident documentation is written as events happen: timeline with timestamps, actions taken and by whom, systems and data affected, evidence collected, decisions and approvals. It serves the investigation, legal and regulatory needs and the later review. Notes made from memory afterwards are weaker evidence.

Post-incident reviews (lessons learned) take place after recovery and ask what happened, how it was detected, what worked, what slowed the response and what changes. A blameless focus on process and controls produces better fixes than looking for a person to blame. Outputs are tracked actions with owners, such as new detection rules, playbook edits or a patched root cause.

Metrics turn operations into numbers:

Abbreviations vary: MTTR is used for respond, recover, resolve and remediate depending on the organisation, so read what the scenario defines. A falling average does not alone prove success; the median, the worst cases and the severity mix matter too.

Stakeholder communication

Communication during an incident is controlled: a defined spokesperson, a need-to-know distribution list, and out-of-band channels when the corporate network may be compromised. Legal and compliance staff decide on notifications to regulators and customers. Technical detail goes to responders; plain-language impact and next update times go to leadership. The incident response lifecycle guide places these steps in the process.

Worked mini-scenario

Last quarter a team reports 400 open vulnerabilities, 30 of them critical. Leadership asks whether risk is rising. A raw count does not answer that. A better report shows critical findings on internet-facing assets, how long each has been open against a 15-day target, how many were fixed, and the trend over four quarters. The mean time to remediate criticals dropped from 38 to 21 days, but two items older than 90 days are escalated with a request for a risk acceptance decision. The report separates what was done, what remains and what decision is needed.

Easy to confuse

Exam pitfall

Picking the answer with the most technical detail. When the audience is executives, the correct choice is usually the concise, business-impact version, and when the audience is the system owner it is the detailed one. Read who the reader is before choosing.

Example questions