Explain vulnerability management reporting and communication
Compliance and action plans, inhibitors to remediation, metrics and KPIs, stakeholder identification, and reporting that drives decisions.
- Reading time
- 20 min read
- Flashcards
- 16 cards
- Practice questions
- 8 questions · 2 PBQs
A finding nobody acts on is worth exactly as much as a finding nobody made. This domain is 16% of the exam and it is where most technical candidates are weakest, because the material is about people rather than systems — but the questions have right answers, and they follow a pattern.
The pattern: the audience determines the content. Almost every question in 4.1 and 4.2 is testing whether you write for the person receiving the report.
Who is receiving this
| Stakeholder | What they need | What they do not need |
|---|---|---|
| Executives / board | Business risk, cost, trend, what decision is needed | CVE numbers, tool output |
| System owners | Their systems, specific fix, deadline, how to verify | The whole organisation's report |
| Developers | The vulnerable code, how to reproduce, the secure pattern | Network-layer findings |
| Compliance / audit | Evidence of control operation, exceptions, cadence | Technical exploitation detail |
| The security team | Everything | — |
Check yourself
A CISO must brief the board on vulnerability management. What should the report emphasise?
What a vulnerability report contains
- Affected hosts — specifically which, not a count
- The vulnerability — what it is, in language the recipient uses
- Risk score, with context — severity plus exposure and asset criticality, because a bare CVSS number invites the wrong priority
- Remediation — the specific action, not "apply patches"
- Priority and deadline — when, and why that date
- Recurrence — whether this has been reported before, which turns a finding into a pattern worth escalating
Recurrence
The same vulnerability reappearing after being remediated. It signals a process failure — image not updated, configuration drift, change management gap — and reporting the recurrence rather than just the finding is what surfaces the underlying cause.
Metrics that mean something
Useful
- Mean time to remediate, by severity
- Percentage remediated within SLA
- Trend in open critical findings over time
- Recurrence rate
- Coverage — what percentage of assets are actually scanned
Misleading on its own
- Total number of vulnerabilities
- Number of scans run
- Findings closed this month
- A single point-in-time count with no trend
The tellA metric is useful when a change in it should change someone's behaviour. Total vulnerability count rises when you improve coverage, so it punishes exactly the thing you want.
Service level objective
An agreed target for remediation time by severity — critical within 7 days, high within 30, and so on. SLOs turn priority into an obligation with a date, and 'percentage remediated within SLO' is the single most useful vulnerability metric because it measures the programme rather than the environment.
Top-10 lists and critical/zero-day tracking are the other reporting staples: the former shows where effort would have the most effect, the latter shows what needs attention right now.
Compliance reporting
Regulatory reporting has its own shape: it demonstrates that a required control operated, over a period, with evidence. PCI DSS wants proof of quarterly scanning and post-change scanning. What it needs is evidence, not assurance — scan dates, scope, results, and the remediation record.
Exceptions belong in compliance reporting explicitly. A documented, time-bounded, owned exception is a managed deviation. An undocumented one is a finding waiting to be discovered by an auditor.
Action plans
A report should end in an action plan, and the exam expects the range of possible actions — not just patching:
- Patching where it is available and safe
- Configuration management — hardening, disabling unused features, correcting drift
- Compensating controls — isolation and monitoring where remediation is impossible
- Awareness, training and education where the weakness is behavioural
- Changing business requirements — sometimes the right fix is to stop doing the thing that creates the exposure
Check yourself
A vulnerability report shows the same misconfiguration recurring on newly built servers each quarter. What should the action plan address?
Inhibitors, in a report
The inhibitors from 2.3 reappear here as something you have to communicate: MOUs and SLAs, governance and change control, business process interruption, degrading functionality, legacy systems, proprietary systems.
The reporting discipline is to state the inhibitor plainly, name what it prevents, describe the compensating control, and identify who owns the residual risk. "Not remediated" invites the reader to assume negligence. "Not remediated because the vendor no longer exists; isolated and monitored; residual risk accepted by the operations director, review due March" is a decision, visibly made by someone.