Vulnerability Remediation Tracker

Tracks individual findings from detection to verified closure with SLA countdown and overdue flagging.

Available soon

Format: Excel
Size: 124 KB
Length: 9 sheets
Version: 1.5
Updated: 27 Sep 2026

Follow this documentFree account. We can email you when it changes.

Preview

The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.

Instructions

How to use this workbook

Step	What to do
1	Set the As-at date on the Summary sheet. It ships set to 2026-09-27, the date the EXAMPLE rows are as at. Set it to today's date, or replace it with =TODAY() so it always shows today; type a fixed date to freeze a month-end report. Every countdown and status uses this date.
2	After each scan, add one row per new finding on each system: every Priority 1 to 3 finding must be recorded (VM-11); Priority 4 findings may be recorded here or left to the normal patch cycle. Give each a unique Finding ID and use the Asset ID from the Scan Coverage & Asset Scope Register.
3	Enter Detected date as the date the scanner first found the vulnerability on that system, not the date you raised a ticket (VM-08). Enter Vendor fix released as the date the vendor first published a fix, or an advisory that names the fix, for the version on that system; leave it empty when the vendor has published no fix. Clock start is calculated as the earlier of the two dates, and the deadline counts calendar days from it.
4	Fill Internet-facing, Asset criticality, Scanner severity, Exploited and, for an internet-facing system with a High or Critical severity, Public exploit code (Yes, No or Not known; Not known is treated as Yes until someone checks). The Suggested priority column applies the Standard's table (section 5.2) and the Vulnerability Risk Rating & SLA Model's criticality uplift: a finding on a Critical system that is not exploited and not Low severity is raised one level, no higher than Priority 2 (RM-05). Type the priority you agree at triage into Priority; if it differs from the suggestion, record why in Priority change reason. Only the standard owner may lower a priority, never to avoid a missed deadline (VM-10).
5	The Deadline is calculated: Priority 1 — 7 days, Priority 2 — 14 days, Priority 3 — 30 days, Priority 4 — 90 days after the clock start. A deadline that is already past on the day you enter a finding shows Overdue at once; escalate it that day (VM-19). For Priority 1, apply a compensating control within 72 hours of detection if the fix cannot be made, and record the date in Mitigation applied date (VM-09). When an open finding is re-rated to a more urgent priority, its new deadline is the earlier of its existing deadline and the date the change became known plus the new priority's days, and for Priority 1 the 72 hours run from that date (RM-12 of the Vulnerability Risk Rating & SLA Model).
6	To re-rate an open finding to a more urgent priority, type the new priority into Priority, enter the date the change became known (for example, the day it was added to the Known Exploited Vulnerabilities catalogue) in Re-rated on, enter the priority it had until then in Priority before re-rating, and say why in Priority change reason. The Deadline is then the earlier of the clock start plus the earlier priority's days, which was the existing deadline, and Re-rated on plus the new priority's days; for a finding raised to Priority 1, Mitigation due counts 72 hours from Re-rated on. The tracker asks for the earlier priority, not only the date, because the existing deadline depends on it and the deadline must never move later (RM-12). Leave both columns empty for a lowering (VM-10, RM-08) and for a return to the original priority when a compensating control stops working (RM-09): those count from the clock start. If a finding is re-rated a second time, enter the latest date and the priority it had just before; the deadline may then come a few days earlier than RM-12 requires, never later.
7	Name one Owner per finding, a person in your organisation. Put the ticket number from your ticketing system in Ticket reference if you use one.
8	At the weekly triage, review every row whose Deadline status is Due soon or Overdue, and act on the Escalation column: overdue findings go to the asset owner's manager, and to the approver once more than 14 days past the deadline (VM-19). Priority 2 findings still open on day 10 go to the asset owner's manager.
9	If a finding cannot be fixed on time, request an exception before the deadline passes (VM-16); a request made afterwards is not an exception, and the finding stays overdue. Once approved, enter its Exception ID and expiry date. The expiry may be no more than 90 days after approval (VM-17); Priority 1 exceptions need the approver, or the more senior approver your exception standard names, and where that standard sets a shorter maximum duration the shorter one applies (VM-17, VM-18). When the exception expires, the finding counts as overdue again.
10	Close a finding only when a later scan confirms it is gone, or other objective evidence is attached (VM-13). Describe the evidence in Closure evidence, enter the Verified closed date, then set Status to Closed. A false positive needs recorded evidence approved by the standard owner (VM-14).
11	Clear every Record check that does not say OK. Delete the EXAMPLE rows before the tracker is approved. Do not type over the white calculated columns.

Legend

Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.

EXAMPLE

Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval.

Tailoring — small organisation: you may record only Priority 1 to 3 findings. If volumes are low you may review the list every two weeks instead of weekly, on two conditions: the Standard says every two weeks (change VM-12 first), and new Priority 1 and 2 findings get an owner as soon as they are found, between meetings. Keep the deadlines and the closure rule unchanged.

Tailoring — regulated financial entity: add a column for the critical or important function the asset supports, and keep month-end copies of this tracker (freeze the As-at date first) as records for supervisors and auditors.

Tailoring — IT run by a service provider: share this tracker, or the same columns, with the provider; require the rescan result as closure evidence rather than a 'done' message. Keep the Owner as the person in your organisation who holds the provider to account.

If your ticketing system already holds these fields, you can use this workbook as a monthly export template instead: keep the same column headers so the Metrics Workbook can read it.

Deadline days are read from the Lists sheet (DeadlineDays). If your approved Standard sets different deadlines, change them there. The Due soon warning windows (DueSoonDays) can be adjusted in the same place.

Example rows are as at 2026-09-27, the As-at date the tracker ships with, so their statuses change when you move the As-at date. The example vulnerability references are examples for illustration, and the dates in the example rows are not those of any real vulnerability.

Tracker

One row per finding per system. Yellow columns are inputs; white columns calculate. Status colours always carry a text label.

Example	Finding ID	Asset ID	Asset name	Internet-facing	Asset criticality	Vulnerability reference	Title	Scanner severity	Exploited	Public exploit code	Suggested priority	Priority	Priority change reason	Re-rated on	Priority before re-rating	Detected date	Vendor fix released	Clock start	Deadline	Mitigation due (Priority 1)	Mitigation applied date	Owner	Ticket reference	Status	Exception ID	Exception expiry	Closure evidence	Verified closed date	Days open	Days to deadline	Days past deadline	Deadline status	Escalation	Record check	Notes
EXAMPLE	VF-0001	AST-003	Remote access gateway	Yes	Critical	CVE-2023-4966	Session information leak in remote access gateway	Critical	Yes	Yes	1	1				22 Sep 2026		22 Sep 2026	29 Sep 2026	25 Sep 2026	23 Sep 2026	Network Manager	CHG-2291	In progress					5	2		Due soon		OK	Mitigated by blocking the management portal from the internet; vendor fix scheduled
EXAMPLE	VF-0002	AST-001	Customer web portal	Yes	Critical	CVE-2021-44228	Remote code execution in Java logging library	Critical	Yes	Yes	1	1				10 Aug 2026	10 Aug 2026	10 Aug 2026	17 Aug 2026	13 Aug 2026	11 Aug 2026	Digital Services Manager	INC-1840	Closed — verified fixed			Rescan on 2026-08-15 no longer detects the finding; scan report filed with the ticket	15 Aug 2026	5			Closed on time		OK
EXAMPLE	VF-0003	AST-005	Finance file server	No	High	CVE-2024-38063	Remote code execution in operating system network stack	Critical	No	No	3	3				12 Aug 2026	11 Aug 2026	11 Aug 2026	10 Sep 2026			IT Operations Manager	CHG-2204	Open					47	-17	17	Overdue	Approver	OK	Vendor update published the day before the scan, so the clock started then. Update failed twice; server reboot window not yet agreed
EXAMPLE	VF-0004	AST-007	Payroll application server	No	High	No CVE — unsupported operating system	Operating system no longer receives security updates	High	No	No	3	3				1 Jul 2026		1 Jul 2026	31 Jul 2026			Finance Systems Lead	PRJ-0112	Open	EX-2026-004	6 Oct 2026			88	-58		Exception		OK	Replacement system project due March 2027
EXAMPLE	VF-0005	AST-002	Public website	Yes	Standard	Scanner check — weak TLS	Outdated encryption protocol (TLS 1.0) accepted	Medium	No	No	3	4	Lowered by standard owner on 2026-09-03: TLS 1.0 disabled on the internet-facing listener; remains on the internal health-check port only			1 Sep 2026		1 Sep 2026	30 Nov 2026			Digital Services Manager	CHG-2250	Awaiting verification					26	64		On track		OK
EXAMPLE	VF-0006	AST-004	Domain controller	No	Critical	CVE-2020-1472	Elevation of privilege in domain controller sign-in service	Critical	Yes	Yes	1	1	Raised from Priority 2 on 2026-09-21, the day it was added to the Known Exploited Vulnerabilities catalogue (RM-11, RM-12)	21 Sep 2026	2	16 Sep 2026	15 Sep 2026	15 Sep 2026	28 Sep 2026	24 Sep 2026	22 Sep 2026	IT Operations Manager	CHG-2307	In progress					12	1		Due soon		OK	Re-rated on 2026-09-21: the deadline moved to the earlier of 2026-09-29 and 2026-09-28. Mitigated by blocking the service from user networks; update scheduled for the next maintenance window

Summary

Remediation summary

Every figure below is calculated from the Tracker as at the date shown. Deadlines come from the Vulnerability & Exposure Management Standard.

As-at date

27 Sep 2026

EXAMPLE: the date the example rows are as at. Use today's date, or type =TODAY().

Open findings

Priority	Open	Overdue	Due soon	Under exception	Oldest overdue (days past deadline)
Priority 1 — Emergency	2	0	2	0	0
Priority 2 — High	0	0	0	0	0
Priority 3 — Medium	2	1	0	1	17
Priority 4 — Low	1	0	0	0	0
All priorities	5	1	2	1	17

Verified-fixed findings (all time on this tracker), and findings closed because the system was retired

Priority	Closed on time	Closed within deadline	Average days from clock start to verified fix
Priority 1 — Emergency	1	100%	5.0
Priority 2 — High	0
Priority 3 — Medium	0
Priority 4 — Low	0
All priorities	1	100%	5.0

Needs attention

Measure	Result	Target	Status	What it means
Overdue with no approved exception	1	0	Action needed	Escalate under VM-19.
Overdue by more than 14 days (escalate to the approver)	1	0	Action needed	VM-19.
Exceptions expiring in the next 14 days	1	—		Fix, or seek renewal through a new review (VM-17).
Priority 1 open without a recorded mitigation	0	0	Meets target	Mitigate within 72 hours (VM-09).
Rows with a record check to resolve	0	0	Meets target	Any row whose Record check does not say OK.

Lists

YesNo	YesNoUnknown	Criticality	Severity	Status	Priority	PriorityName	DeadlineDays	DueSoonDays
Yes	Yes	Critical	Critical	Open	1	Priority 1 — Emergency	7	2
No	No	High	High	In progress	2	Priority 2 — High	14	4
	Not known	Standard	Medium	Awaiting verification	3	Priority 3 — Medium	30	7
			Low	Closed — verified fixed	4	Priority 4 — Low	90	14

Closed — false positive

Closed — system retired

Definitions

Definitions

Term	Meaning in this workbook
Finding	One vulnerability on one system, as reported by a scan or other test. The same vulnerability on three servers is three findings.
Finding ID	Your unique reference for the finding, such as VF-0001.
Asset ID	The system's ID in the Scan Coverage & Asset Scope Register, which links each finding to the register.
Internet-facing	Reachable from the internet, directly or through a published service, without first connecting to the organisation's private network; or reachable from any network the organisation does not fully control, such as partner links, guest Wi-Fi or third-party connections.
Asset criticality	Critical: failure or compromise would stop a core business service or expose highly sensitive data. High: significant disruption or data exposure. Standard: all other systems.
Vulnerability reference	The published identifier of the vulnerability, usually a CVE ID (Common Vulnerabilities and Exposures, for example CVE-2021-44228), or the scanner's own check reference where no CVE exists.
Scanner severity	The technical severity the scanner or vendor gives: Critical, High, Medium or Low, usually based on CVSS (Common Vulnerability Scoring System).
Exploited	Yes when there is reliable evidence of the vulnerability being used in real attacks, such as an entry in a known-exploited vulnerabilities catalogue or credible threat information.
Public exploit code	Working exploit code, or a proof of concept that attacks the vulnerability, that has been published where anyone can obtain it, such as a public code repository, an exploit database or an attack framework, and that works against the version running on the system. Yes or Not known on an internet-facing system makes the suggested priority 1 when the severity is High or Critical (Vulnerability Risk Rating & SLA Model rule RM-14). Not needed for an internal system, or for a Medium or Low finding.
Suggested priority	The priority the Standard's table (section 5.2) gives from Exploited, Internet-facing, Asset criticality and Scanner severity, with the criticality uplift of the Vulnerability Risk Rating & SLA Model (RM-05): a finding on a Critical system that is not exploited and not Low severity is raised one level, no higher than Priority 2.
Priority	The priority agreed at triage, 1 (most urgent) to 4. Priority 1 — Emergency: exploited vulnerability on an internet-facing or Critical system; public exploit code for a High or Critical vulnerability on an internet-facing system — mitigate within 72 hours; fix within 7 days. Priority 2 — High: exploited vulnerability on an internal system; Critical or High severity on an internet-facing system — 14 days. Priority 3 — Medium: critical or High severity on an internal system; Medium severity on an internet-facing system — 30 days. Priority 4 — Low: medium severity on internal systems; Low severity anywhere — 90 days.
Priority change reason	Why the agreed priority differs from the suggested one, or why the finding was re-rated. Only the standard owner may lower a priority (VM-10).
Re-rated on	For an open finding re-rated to a more urgent priority, the date the change became known, such as the day it was added to the Known Exploited Vulnerabilities catalogue (RM-12 of the Vulnerability Risk Rating & SLA Model). Leave it empty otherwise, including for a lowering and for a return to the original priority under RM-09.
Priority before re-rating	The priority the finding had until Re-rated on, less urgent than its Priority now. The existing deadline was counted from the clock start with this priority's days, so the tracker needs it to keep the new deadline no later than that one (RM-12). After a second re-rating, enter the priority it had just before the latest one.
Detected date	The date the vulnerability was first detected on the system (VM-08).
Vendor fix released	The date the vendor first published a fix, or an advisory that names the fix, for the version running on the system. Leave it empty when there is no vendor fix.
Clock start	The earlier of Detected date and Vendor fix released; Detected date when there is no vendor fix. Deadlines count calendar days from it (VM-08).
Deadline	Clock start plus the days for the priority on the Lists sheet (DeadlineDays). For a finding re-rated to a more urgent priority, the earlier of Clock start plus the days for Priority before re-rating and Re-rated on plus the days for Priority (RM-12).
Mitigation due (Priority 1)	72 hours (3 days) after detection (not after the vendor release); for a finding re-rated to Priority 1, 72 hours after Re-rated on (RM-12). By then a Priority 1 finding must be fixed or have a compensating control applied (VM-09).
Compensating control	A measure that reduces the risk of a vulnerability that cannot yet be fixed, such as blocking network access to the affected service.
Owner	The person accountable for fixing the finding, normally the asset owner or someone they name.
Ticket reference	The number of the matching ticket or change record in your ticketing system, if you use one.
Status	Open: not started. In progress: work under way. Awaiting verification: fix applied, waiting for a rescan. Closed — verified fixed: a later scan or other objective evidence confirms it is gone. Closed — false positive: evidence shows the finding was never present, approved by the standard owner. Closed — system retired: the system has been decommissioned, with the record as evidence. It is not a verified fix, so the summary counts it apart.
Exception	An approved, time-limited decision not to fix a vulnerability by its deadline, with a named risk owner and compensating controls, recorded under the Security Exception & Waiver Standard.
Exception ID	The reference of the approved exception in your exception register.
Exception expiry	The date the exception ends, no more than 90 days after approval (VM-17). After it, the finding counts as overdue again unless renewed.
Risk owner	The person who decides whether to accept the risk of a vulnerability that cannot be fixed on time, as defined in the risk management methodology.
Closure evidence	What proves the finding is gone: the later scan that no longer detects it, or other objective evidence such as a configuration export. A ticket marked complete is not enough (VM-13).
Verified closed date	The date the closure evidence was obtained. The finding counts as closed from this date.
False positive	A reported finding that is not actually present on the system.
Days open	Calendar days from Clock start to Verified closed date, or to the As-at date while open.
Days to deadline	Calendar days left until the deadline for an open finding. Negative means overdue.
Days past deadline	Calendar days an overdue finding is past its deadline.
Deadline status	On track; Due soon (within the warning window for its priority on the Lists sheet); Overdue (past the deadline with no current exception); Exception (a current exception is recorded); Closed on time; Closed late.
Escalation	Who must be told: Asset owner's manager for an overdue finding, and for a Priority 2 finding still open on day 10 (counted from the clock start, or from Re-rated on for a finding re-rated to Priority 2); Approver once overdue by more than 14 days (VM-19).
Triage	The weekly meeting that reviews new and overdue findings, following the Vulnerability Triage & Remediation Operating Procedure (VM-12).
Record check	A calculated prompt showing the first missing or inconsistent item on the row. OK means nothing is outstanding.
As-at date	The date every countdown and status is measured against. Set on the Summary sheet; it ships set to the EXAMPLE's date, 2026-09-27. Set it to today's date, or type =TODAY() to follow the calendar.
EXAMPLE row	A worked example showing how a completed row looks. Delete before approval.
VM-08, VM-09 …	Requirement numbers in the Vulnerability & Exposure Management Standard.

Framework References

Framework references

These references indicate relevance only and do not reproduce the text of any standard.

Framework	Reference	Supported by
ISO/IEC 27001:2022	Annex A 8.8 — Management of technical vulnerabilities	The tracker as a whole
ISO/IEC 27001:2022	Clause 7.5.3 — Control of documented information	Records kept with closure evidence
NIST CSF 2.0	ID.RA-01 — “Vulnerabilities in assets are identified, validated, and recorded”	Finding, asset and detection columns
NIST CSF 2.0	ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated”	Priority, deadline and exception columns
NIS2 — Directive (EU) 2022/2555	Article 21(2)(e) — “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure”	The tracker as a whole
DORA — Regulation (EU) 2022/2554	Article 9 — protection and prevention, including documented policies for patches and updates (Article 9(4)(f))	Priorities, deadlines, closure
DORA — Delegated Regulation (EU) 2024/1774	Article 10 — vulnerability and patch management, including automated vulnerability scanning at least weekly for ICT assets supporting critical or important functions	Recording findings and monitoring their resolution
PCI DSS v4.0.1	Requirement 6.3.3 — installing patches for critical (or high-security, as the risk ranking defines it) vulnerabilities within one month of release; check the wording of your version with your assessor	Deadlines
PCI DSS v4.0.1	Requirement 11.3.1 — internal vulnerability scans at least every three months, with rescans to confirm fixes	Rescan as closure evidence

Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); PCI DSS v4.0.1