Vulnerability reporting people will act on

Why this matters

Domain 4 is 16% of the exam and it is the domain candidates prepare least, because it is the least technical. That makes it cheap marks — the material is finite and the questions are about judgement rather than recall.

It also matters more than its weight suggests. A vulnerability programme's output is a report, and a report nobody acts on has produced nothing. You can run flawless scans, prioritise perfectly and remediate none of it, because the people who own the fix were sent a spreadsheet with four thousand rows and no indication which twelve mattered.

The lesson

Audience: engineer, manager, executive, auditor

The same findings, four different documents. Writing one report for everyone produces a document that serves nobody, which is the most common reporting failure there is.

The engineer who will fix it needs:

• Exactly which asset, identified unambiguously — hostname, address, and a stable identifier.
• Exactly what is wrong, with the evidence: the version found, the configuration, the response that proved it.
• Exactly what to do, specific enough to act on without research.
• How to verify the fix.
• Why it is urgent, in one line, so they can sequence it against their own work.

They do not need the CVSS vector explained, the executive summary, or the trend chart.

The manager who owns the team needs: how much is outstanding in their area, what is overdue against SLA, what is newly urgent, how they compare to the expectation, and what they need from someone else in order to finish. Their question is planning capacity, not fixing hosts.

The executive needs: are we getting better or worse, what is the material risk to the business, what decision is being asked of them, and what happens if they say no. In business language, in under a page, with no CVE identifiers at all. Expressing exposure as "the systems processing customer payments have twelve unpatched critical issues, three of which are being actively exploited elsewhere" lands where "1,842 criticals" does not.

The auditor needs: the process as written, evidence that it operated, coverage of the scope, the exceptions with their approvals and expiry, and the metrics over the period. Their question is whether the control is operating, which is lesson 26's distinction.

The common thread: write for what the reader will do with it. A reader who cannot act on a document stops opening it, and that is close to irreversible.

Trends over snapshots

A single number is nearly uninterpretable. "We have 1,842 open vulnerabilities" is bad only if you know what it was, and bad in a way that matters only if you know the direction.

Trends answer the questions people actually have:

• Is the backlog growing or shrinking? The most important number in the report, and it is a rate, not a count.
• Are we fixing faster? Median time to remediate, by severity.
• Is new exposure arriving faster than we close it? New findings against closed findings per period. If arrival exceeds closure, the backlog grows regardless of effort, and that is a resourcing conversation rather than a performance one.
• Is the ageing profile improving? How old is the oldest open critical, and what fraction sit beyond SLA.

Presenting them honestly requires care:

• Annotate the discontinuities. A count that jumps 30% because scan coverage expanded is good news that looks like bad news. Unannotated, it either provokes a panic or teaches people to ignore the chart. Say what changed.
• Keep the denominator visible. Findings per asset, with the asset count shown, survives an estate that grew.
• Beware improvements that come from measuring less. A coverage drop reduces every count in the report. Pair the findings trend with a coverage trend, or the report can improve while the estate does not.
• Show the period consistently. Changing the window between reports is how a trend gets manufactured accidentally.

SLA compliance and exception reporting

The part of the report that creates accountability, and therefore the part that needs to be fair.

What to report:

• Compliance rate by severity and by owner — what fraction was remediated inside the window.
• Currently overdue, with age.
• The exceptions: what is formally accepted, by whom, until when, with what compensating control. Lesson 23's deferral record, aggregated.
• Exceptions expiring soon, so they are reviewed rather than forgotten.
• The aggregate accepted position, which is the one people miss. Twenty individually reasonable acceptances can add up to an unreasonable whole, and only the aggregate shows it.

What makes this land rather than provoke a fight:

• Report to the owner before reporting on them. A team seeing its numbers for the first time in an executive deck becomes an adversary, permanently.
• Distinguish "not done" from "not done by this team" — blocked on a vendor patch, blocked on a change freeze, blocked on another team. A compliance number that blames a team for something outside its control destroys the credibility of every other number.
• Make exceptions easy and visible. If the formal route is painful, the pressure goes into not recording findings at all, which is much worse than a large exception list.
• Show the numerator and denominator. "62% compliant" means different things at 8 findings and 8,000.

Dashboards that do not mislead

Dashboards are read far more than reports and are much easier to get wrong, because a chart carries an authority its underlying data may not deserve.

Common ways they mislead, each of which is a habit to break:

• A count with no denominator. "412 criticals" against what estate?
• A green overall status derived from an average that hides a severe concentration in one critical system.
• Coverage implied but not shown. A dashboard drawn from scan results reports the scanned estate, and the unscanned part appears as no findings — visually indistinguishable from no problems. This is the most consequential dashboard lie because it is entirely silent.
• A stale timestamp, or none. A dashboard whose data is nine days old looks exactly like a live one; every dashboard needs its as-of date on its face.
• A truncated y-axis turning a 3% change into a cliff.
• Averages hiding the tail. Mean time to remediate is dragged down by hundreds of trivial fixes while criticals sit for months. Report the median and the 90th percentile, or report by severity.
• Precision implying accuracy. "1,842" suggests a certainty that a scanner with false positives and an incomplete inventory does not support.

The test to apply before publishing: what would this dashboard look like if our tooling had silently stopped working? If the answer is "better", the dashboard needs a coverage and freshness indicator beside every number — which is the same reasoning as the failed-authentication trap in lesson 20, drawn at the scale of a whole programme.

Recurring findings as a process story

The reframing that turns a vulnerability report from a status list into something that can change a decision.

A finding that is remediated and returns is not a vulnerability problem. It is a process problem — the golden image, the template, the base container, the desired state — as lesson 24 set out. Reporting it as another instance of the same CVE hides that entirely.

So report recurrence as its own category:

• How many findings closed this period had been closed before.
• Which sources they recur from, since that names the fix.
• The cost. "This critical has been remediated on 40 hosts four times in nine months" is roughly 160 units of work that one image update would have ended.

Why this section is worth the space: it is the only part of a vulnerability report that offers a manager something to decide rather than something to approve. Counts and compliance rates ask for acknowledgement. "Your build image is generating this backlog" asks for a change and names what it buys.

That is the general principle of this domain and the reason it is 16% of the exam. A report that describes the state of the world is a status update. A report that names a specific, changeable cause is an argument — and only the second one moves anything.

Topics this lesson owns

• [x] Audience: engineer, manager, executive, auditor
• [x] Trends over snapshots
• [x] SLA compliance and exception reporting
• [x] Dashboards that do not mislead
• [x] Recurring findings as a process story