Vulnerability reports
Builds the periodic report from the scanners themselves, so every open finding carries an owner, a deadline and a visible status.
Tools
Qualys, Tenable.io, Rapid7 InsightVM, Vanta, Jira Service Management
Outcomes
Report totals reconcile with the scanners • Every open finding shows a named owner • Overdue items called out by name • Accepted risks carry an expiry date
Documentation
Instruction-ready detail below
The periodic vulnerability report is usually rebuilt from scratch each cycle, which means the numbers move for reasons nobody can explain and the same finding appears under two different names. This workflow builds it from the scanners directly. It matches each open finding to an asset, an owning team and a named contact, carries the deadline and age across from the tracking system, and collapses duplicates from different tools into one line that lists its sources, so the totals reconcile with the scanners rather than with a spreadsheet. Findings past their deadline, findings carrying an approved exception, and findings that have come back on the same host for the fourth time are separated into their own sections instead of being averaged into one percentage. Every line shows one owner, so the review meeting spends its time on the unowned and the overdue rather than on the total. The finished report is written to the compliance record, and exceptions are checked for expiry, which is what stops an accepted risk living forever. A human still decides the priority order, which findings to raise as accepted risk, and how the report describes a coverage gap.