# Reporting To Stakeholders > Use when reporting vulnerability-management status to different audiences — metrics that drive action and decisions, not vanity numbers that impress nobody and change nothing. - Skill: `jihedbfr-art/reporting-to-stakeholders` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add jihedbfr-art/reporting-to-stakeholders` - Raw SKILL.md: https://api.skillmd.com/api/skills/jihedbfr-art/reporting-to-stakeholders/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: jihedbfr-art (https://skillmd.com/u/jihedbfr-art) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jihedbfr-art/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.