Reporting

Overview

Effective vulnerability reporting bridges the gap between technical remediation work and strategic decision-making. Reports must be tailored to their audience, clearly communicating risk, progress, and compliance status without distorting the underlying data.

Types of Reports

Executive Summary

Designed for C-level management and board members. Concise (1 - 2 pages), focusing on:

• Overall risk posture (critical vs. total open vulnerabilities)
• Remediation progress and trends (month-over-month)
• SLA compliance rate
• Key risks requiring leadership attention
• No technical jargon; uses heatmaps and traffic-light indicators

Technical Report

Intended for security engineers and system administrators. Detailed and actionable:

• Full listing of open vulnerabilities with CVSS scores, affected hosts, and plugin IDs
• Step-by-step remediation guidance
• Verification results and patch status per host
• False positive annotations and exceptions

Compliance Report

Used for regulatory audits (ISO 27001, PCI DSS, SOC 2, NIST). Structured to map findings to specific control requirements:

• Control ID and description
• Evidence of remediation (scan results, patch logs, configuration snapshots)
• Residual risk acceptance (if any) signed by the risk owner
• Auditor-ready formatting with timestamps and version history

Audience Considerations

Metric Tracking

Mean Time to Remediate (MTTR)

Tracks the average time between vulnerability discovery and closure. Segregate by severity - critical vulnerabilities should target MTTR under 48 hours, while low severity may have a 30-day window.

Vulnerability Aging

Measures how long vulnerabilities remain open. Aging reports highlight overdue items that breach SLA thresholds. Use quartile analysis (P25, P50, P90) to identify chronic remediation bottlenecks.

Remediation Rate

Percentage of vulnerabilities closed within the SLA window. Remediation rate = (Closed on time ÷ Total closed) × 100. A rate below 90% typically triggers process improvement reviews.

Dashboard Tools

Common dashboard platforms include:

• Grafana - Custom dashboards pulling data from vulnerability scanners via API
• Power BI / Tableau - Advanced visualization and executive-facing reports
• Native scanner dashboards - Qualys VMDR, Tenable.sc, Nexpose
• SIEM integrations - Splunk, Elastic Security for correlated views combining scan data with patch logs

Dashboards should auto-refresh at least daily and support drill-down from risk summary to individual host.

Report Structure (Per Finding)

Each finding in a technical or compliance report should follow a consistent structure:

1. Finding - Title, CVE ID, plugin ID, CVSS score
2. Risk - Business impact, exploitability, affected assets
3. Evidence - Scanner output, log excerpts, patch verification data
4. Recommendation - Remediation steps, vendor advisory link, alternative mitigations

SLA Tracking

Define SLAs per severity and track compliance in every reporting cycle:

• Critical (CVSS 9.0 - 10.0): Remediate within 48 hours
• High (CVSS 7.0 - 8.9): Remediate within 7 calendar days
• Medium (CVSS 4.0 - 6.9): Remediate within 30 calendar days
• Low (CVSS 0.1 - 3.9): Remediate within 90 calendar days

SLA breach reports should include root cause analysis for each missed deadline.

Trend Analysis

Compare current reporting period metrics against historical baselines (30, 60, 90 days). Identify:

• Are new vulnerabilities being introduced faster than old ones are closed?
• Which teams or asset groups have improving or declining remediation performance?
• Are recurring vulnerability types (e.g., missing patches on Java, outdated TLS) persisting across quarters?

Trend charts (line graphs for MTTR, stacked bar for open vs. closed, heatmaps for aging) provide an at-a-glance progress overview during management reviews.