A scanner gives you findings. What auditors, boards, and your own future self need is the thing scanners do not produce: who owns each finding, when it is due, and what happened to the ones you decided not to fix. This tracker is built around the remediation clock rather than the scan.
Set the SLA windows before you import anything. Decide your remediation window per severity first: a common starting point is 7 days for critical, 30 for high, 90 for medium. Shorten them for internet-facing assets. If you import findings before agreeing the clock, every row arrives with no due date and the backlog becomes unmanageable.
Give every finding one named owner. Not a team, a person. A vulnerability assigned to "Infrastructure" is assigned to nobody. The owner is whoever can actually deploy the fix, which is often not the person who ran the scan.
Treat an accepted risk as an exception with an expiry. Findings you will not fix are legitimate: a compensating control, a system due for decommission, a vendor who has not shipped a patch. What is not legitimate is an open-ended acceptance. Every exception needs an approver, a reason, a compensating control, and a date it comes back for review.
Report ageing, not counts. "We have 400 open findings" tells nobody anything. "We have 6 criticals past SLA, oldest 34 days" is a decision-making number. Fill the ageing summary monthly and take that to the risk conversation instead of a raw scan report.
Here's a preview. Unlock the free download to get all 6 sections (5 more below).
Agree this first. Internet-facing assets usually get a shorter clock than internal ones. If you only keep one column, keep the tighter one.
| Severity | CVSS range | Internet-facing window | Internal window | Clock starts |
|---|---|---|---|---|
| Critical | 9.0-10.0 | 7 days | 14 days | Date the finding was first detected |
| High | 7.0-8.9 | 14 days | 30 days | Date the finding was first detected |
More free templates IT teams use alongside this one.
Patching breaks things, which is why teams delay it, which is why they get breached through something with a patch available for six months. This schedule is built around deployment rings, so a bad patch hits a pilot group of twenty people rather than the whole company.
Risk registers fail in one of two ways: everything scores medium, or the register is written once for an audit and never opened again. This one forces a treatment decision and a review date on every row, because a risk with neither is a note, not a managed risk.
Firewall rule bases grow and never shrink, because adding a rule solves a problem today and removing one might cause an outage tomorrow. This log makes removal safe by requiring evidence of use before a rule is retired.
Per-finding: the CVE or check, the affected asset, whether it is internet-facing, severity, first detection date, a due date derived from your SLA, one named owner, and status. Alongside it you need an exception register with expiry dates, and an ageing view showing what is past SLA.
A common starting point is 7 days for critical, 14-30 for high, 30-90 for medium, and next maintenance window for low, with tighter windows for internet-facing assets. These are conventions rather than requirements. Set yours against your own risk appetite and any framework you are audited against.
Record it as a formal exception with four things: the reason, a compensating control that actually reduces the risk, a named approver at the right level of authority, and an expiry date that brings it back for review. An acceptance with no expiry is how known risk quietly becomes permanent.
At detection. Starting it at assignment hides triage delay, so a critical finding can sit unreviewed for weeks and still show as within SLA. Detection-based clocks make queue latency visible, which is the behaviour you want to surface.
