Vulnerability Remediation Tracker
Tracks individual findings from detection to verified closure with SLA countdown and overdue flagging.
Available soon
- Format
- Excel
- Size
- 101 KB
- Length
- 9 sheets
- Version
- 1.1
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. A two-weekly review now carries the Standard's two conditions. The Suggested priority now applies the model's criticality uplift (RM-05). Priority 1 exceptions go to the approver VM-18 names. The As-at date ships as a fixed date instead of TODAY(), so the file does not change from day to day; set it to today's date or type =TODAY().
- 1.0
Published.
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). 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) 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 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, 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. |
| 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. 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 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 | 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 | 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 | 46 | -16 | 16 | 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 | 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 | 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 | 26 | 64 | 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 | 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 | 1 | 0 | 1 | 0 | 0 |
| Priority 2 — High | 0 | 0 | 0 | 0 | 0 |
| Priority 3 — Medium | 2 | 1 | 0 | 1 | 16 |
| Priority 4 — Low | 1 | 0 | 0 | 0 | 0 |
| All priorities | 4 | 1 | 1 | 1 | 16 |
Closed findings (all time on this tracker)
| Priority | Closed on time | Closed late | Closed within deadline | Average days to verified closure |
|---|---|---|---|---|
| Priority 1 — Emergency | 1 | 0 | 100% | 5.0 |
| Priority 2 — High | 0 | 0 | ||
| Priority 3 — Medium | 0 | 0 | ||
| Priority 4 — Low | 0 | 0 | ||
| All priorities | 1 | 0 | 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; 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. |
| 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 — 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 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 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