Reporting To Stakeholders

Prerequisites

• Target system, dependencies and environment configured.

Usage

Purpose

A vulnerability programme that can't communicate its state to the people who fund and act on it stalls. But most vuln reporting fails in one of two ways: vanity metrics that look impressive but drive no decision ("we found 40,000 vulnerabilities!"), or raw technical detail that means nothing to a business audience. This skill covers reporting that fits the audience and drives action — for engineers, management, and leadership alike.

When to use it

Regular programme reporting, board/leadership updates, and communicating with the teams doing remediation. Good reporting is what secures continued investment and drives the behaviour (patching, prioritisation) the programme needs.

Procedure

1. Match the report to the audience — the core principle. Different audiences need different things:
   • Remediation teams — specific, actionable findings: what to fix, on which assets, by when, grouped by root cause. Technical and concrete.
   • Security/IT management — programme health: are we keeping pace, where are the bottlenecks, SLA compliance, trends. Operational.
   • Leadership/board — risk in business terms: are we more or less exposed than last quarter, how do we compare to peers, is the investment working. Strategic, non-technical.
2. Report metrics that drive decisions, not vanity numbers. "Total vulnerabilities found" impresses nobody and changes nothing. Useful metrics answer "are we getting better and where's the problem": mean time to remediate (by risk tier), SLA compliance rate, percentage of critical/exploited vulns open past SLA, remediation rate vs new-finding rate, and coverage (what fraction of assets are actually scanned).
3. Frame risk in the audience's language. For leadership, translate technical severity into business impact and trend ("exposure to actively-exploited vulnerabilities down 30% this quarter"), not CVE counts. For engineers, keep it concrete and actionable.
4. Show trend, not just a snapshot. A single number ("500 open findings") is meaningless without direction; is it up or down, and why? Trends over time show whether the programme is winning.
5. Make it drive action. Every report should lead somewhere — a bottleneck to unblock, a team that needs support, a risk decision for leadership, a resourcing case. A report that changes nothing is overhead.
6. Be honest about gaps. Report coverage limitations and unremediated risk accurately; a rosy report that hides blind spots misleads decision-makers and fails after an incident.

Cheatsheet

match report to audience
  remediation teams -> actionable: what/where/by-when, grouped by root cause
  security mgmt      -> programme health: MTTR, SLA compliance, bottlenecks, trends
  leadership/board   -> business risk: exposure trend, peer comparison, ROI

metrics that DRIVE decisions (not vanity)
  DON'T lead with: "total vulnerabilities found" (impresses nobody, drives nothing)
  DO report:
    mean time to remediate (by risk tier)
    SLA compliance % ; critical/exploited open past SLA
    remediation rate vs new-finding rate (are we keeping up?)
    scan coverage % (what fraction of assets are actually assessed)
  always: TREND over time, not just a snapshot

every report -> an action / decision. honest about gaps.

Reading your reporting

• Vanity metrics leading the report ("40,000 findings!") = impressive-looking, decision-useless; it doesn't tell anyone whether things are improving or what to do. Replace with MTTR, SLA compliance, and trend.
• The same technical report sent to engineers and the board = one audience is overwhelmed, the other underinformed. Tailor per audience.
• Snapshots with no trend = "500 open" says nothing without direction; leadership can't tell if the programme is working. Show the trajectory.
• A report that leads to no action = overhead. If nobody does anything differently, it's not driving the programme.
• Rosy numbers hiding coverage gaps = misleads decision-makers and collapses after an incident exposes the blind spot. Report gaps honestly.
• Audience-fit, action-driving, trend-showing, honest reporting = the kind that secures investment and changes behaviour.

The fix / best practice

• Tailor to the audience — actionable for engineers, operational for management, business-framed for leadership.
• Lead with decision-driving metrics (MTTR by tier, SLA compliance, remediation-vs-discovery rate, coverage), not raw counts.
• Translate risk into the audience's terms — business impact and exposure trend for leadership, concrete fixes for engineers.
• Always show trend so the direction (improving/degrading) is clear.
• End every report in an action or decision — a bottleneck, a resourcing case, a risk decision.
• Be honest about coverage and residual risk so decisions rest on reality.

Pitfalls

• Vanity metrics. "Vulnerabilities found" and similar big numbers look like progress but drive nothing. Report timeliness, compliance, and trend instead.
• One report for everyone. Engineers and the board need opposite things; a single format serves neither well.
• Snapshots without trend. A number with no direction can't tell anyone whether the programme is working.
• Reports that drive no action. If nothing changes as a result, it's pure overhead. Aim each report at a decision.
• Hiding gaps behind good-looking numbers. It misleads and backfires after an incident; report coverage and residual risk honestly.

References

• NIST SP 800-40 and SP 800-55 (security measurement and metrics)
• The risk-acceptance-and-sla, cvss-in-context, and GRC security-metrics skills
• Industry guidance on risk-based vulnerability-management metrics (MTTR, SLA compliance, coverage)

Inputs

• Relevant source code, logs, network traces, or system specifications.

Outputs

• Analysis findings, security audit report, or generated code artifacts.