Vulnerability Remediation Tracker

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

Available soon

Format: Excel
Size: 100 KB
Length: 9 sheets
Version: 1.0
Updated: 27 Sep 2026

What's inside

Instructions
Tracker
Summary
Lists
Definitions
Framework References

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 shows today's date; type a fixed date over it 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). The deadline counts calendar days from it.
4	Fill Internet-facing, Asset criticality, Scanner severity and Exploited. The Suggested priority column applies the Standard's table (section 5.2). 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 detection. For Priority 1, apply a compensating control within 72 hours if the fix cannot be made, and record the date in Mitigation applied date (VM-09).
6	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.
7	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.
8	If a finding cannot be fixed on time, request an exception before the deadline passes (VM-16). 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 (VM-18). When the exception expires, the finding counts as overdue again.
9	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).
10	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 and review the list every two weeks if volumes are low. 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 use the template's revision date (2026-09-27) as their reference point, so their statuses change as the As-at date moves on. The example vulnerability references are real published identifiers used for illustration.

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	Suggested priority	Priority	Priority change reason	Detected date	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	1	1		22 Sep 2026	29 Sep 2026	25 Sep 2026	23 Sep 2026	Network Manager	CHG-2291	In progress					6	1		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	1	1		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	3	3		12 Aug 2026	11 Sep 2026			IT Operations Manager	CHG-2204	Open					47	-17	17	Overdue	Approver	OK	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	3	3		1 Jul 2026	31 Jul 2026			Finance Systems Lead	PRJ-0112	Open	EX-2026-004	6 Oct 2026			89	-59		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	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	30 Nov 2026			Digital Services Manager	CHG-2250	Awaiting verification					27	63		On track		OK

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

28 Sep 2026

Shows today. Type a fixed date to freeze a report.

Open findings

Priority	Open	Overdue	Due soon	Under exception	Oldest overdue (days past deadline)
Priority 1 — Emergency	1	0	1	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	4	1	1	1	17

Closed findings (all time on this tracker)

Priority	Closed on time	Closed within deadline	Average days to verified closure
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	Criticality	Severity	Status	Priority	PriorityName	DeadlineDays	DueSoonDays
Yes	Critical	Critical	Open	1	Priority 1 — Emergency	7	2
No	High	High	In progress	2	Priority 2 — High	14	4
	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.
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.
Suggested priority	The priority the Standard's table (section 5.2) gives from Exploited, Internet-facing, Asset criticality and Scanner severity. The full method is in the Vulnerability Risk Rating & SLA Model.
Priority	The priority agreed at triage, 1 (most urgent) to 4. Priority 1 — Emergency: exploited vulnerability on an internet-facing or Critical 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. Only the standard owner may lower a priority (VM-10).
Detected date	The date the vulnerability was first detected on the system. Deadlines count calendar days from this date (VM-08).
Deadline	Detected date plus the days for the priority on the Lists sheet (DeadlineDays).
Mitigation due (Priority 1)	72 hours (3 days) after detection. 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.
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 Detected date 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; 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 defaults to today.
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 vulnerabilities within one month of release	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