# Vulnerability Remediation Tracker: [Organization name] [Period]

> Working register for every vulnerability finding from discovery to
> verified closure: priority inputs (CVSS v4.0, EPSS, CISA KEV), the
> remediation due date from the service level, owner, status, exceptions
> and the metrics that show whether remediation keeps pace. It supports
> ISO/IEC 27001:2022 + Amd 1:2024 Annex A control A.8.8 (technical
> vulnerability management) with guidance from ISO/IEC 27002:2022, and
> records the operation of the vulnerability management policy
> (`security/vulnerability-management-policy`). Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- The policy (`security/vulnerability-management-policy`) sets the rules:
  scanning cadence, prioritisation model and service levels. This
  tracker is the record that proves the rules run. Keep the two
  consistent: copy the policy's service level matrix into section 2.
- Most organizations keep the live tracker in a ticketing tool or a
  vulnerability management platform. Use this template to define the
  fields, to hold the monthly snapshot an auditor can read, and as the
  tracker itself where no tool exists.
- Fill section 2 (service levels) and section 3 (fields) first.
- Main pitfall: closing findings on the owner's word. A finding closes
  only when a rescan or test shows it is gone.
- Related templates: `ops/patch-management-policy`,
  `security/security-exception-request`, `isms/isms-risk-acceptance-record`,
  `compliance/asset-inventory`, `security/pentest-report`,
  `isms/control-evidence-matrix`.
-->

## Document control

<!-- Guidance: Record the period the snapshot covers and the data source, so an auditor can match it with the tool. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-072 |
| Version | [1.0] |
| Status | [Draft / In review / Approved] |
| Owner | [@vuln-owner] ([Vulnerability management lead or ISMS manager]) |
| Approvers / reviewers | [CISO or ISMS manager], [Head of IT Operations] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential] (open vulnerabilities are sensitive) |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024, Annex A A.8.8; ISO/IEC 27002:2022 |
| Next scheduled review | YYYY-MM-DD (snapshot monthly; fields and service levels annually) |
| Period covered | [YYYY-MM-DD to YYYY-MM-DD] |
| Data source | [Vulnerability scanner, penetration test reports, bug bounty, supplier advisories] |
| Governing policy | Vulnerability management policy (`security/vulnerability-management-policy`) |

### Approvals

| Role | Name | Signature or record | Date |
|---|---|---|---|
| Owner | [Name] | [Reference] | YYYY-MM-DD |
| CISO or ISMS manager | [Name] | [Reference] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@author] | Fields, service levels and metrics defined; first monthly snapshot |

## Contents

1. [Purpose and use](#1-purpose-and-use)
2. [Service levels](#2-service-levels)
3. [Tracker fields](#3-tracker-fields)
4. [Tracker register](#4-tracker-register)
5. [Finding lifecycle](#5-finding-lifecycle)
6. [Exceptions](#6-exceptions)
7. [Metrics](#7-metrics)
8. [Size tiers](#8-size-tiers)
9. [Records and evidence](#9-records-and-evidence)
10. [References](#10-references)
11. [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and use

<!-- Guidance: State which sources feed the tracker and who updates it. An auditor checks that every source in the policy (scans, tests, advisories) appears here. -->

The tracker holds every vulnerability finding in scope of the ISMS
(DOC-ISMS-002) that needs action: scanner results for infrastructure,
cloud and containers, application security test results, penetration
test findings (`security/pentest-report`), supplier security advisories,
and reports from researchers. Findings are grouped by asset as recorded
in the asset inventory (DOC-ISMS-012), so each one has an owner.

Asset owners update status on their findings. The vulnerability
management lead checks priority, due dates and closures, and publishes a
monthly snapshot of this tracker with the metrics in section 7.

## 2. Service levels

<!-- Guidance: Copy the matrix from your policy. If you have no policy yet, use the simplified matrix below and replace it when the policy is approved. Pitfall: a due date counted from ticket creation instead of detection. -->

If the vulnerability management policy is in use, copy its matrix here
(decision by asset tier, measured from detection). Otherwise use this
simplified matrix, in calendar days from detection *(Example)*:

| Priority | Rule (first match wins) | Mitigate within | Remediate within |
|---|---|---|---|
| Critical | Listed in the CISA KEV catalog, or CVSS v4.0 score 9.0 or above on an internet-facing asset | 48 hours | 7 days |
| High | CVSS v4.0 score 7.0 to 8.9, or 9.0 or above on an internal asset, or EPSS probability at or above [0.10] | n/a | 30 days |
| Medium | CVSS v4.0 score 4.0 to 6.9 | n/a | 90 days |
| Low | CVSS v4.0 score 0.1 to 3.9 | n/a | 180 days |

Inputs:

- **CVSS v4.0** (FIRST): record the score, the vector string and the
  label for the metric groups used (CVSS-B, CVSS-BT, CVSS-BE or
  CVSS-BTE). Where only a CVSS v3.x score exists, record it with its
  version.
- **EPSS** (FIRST): the probability that the vulnerability is exploited
  in the wild in the next 30 days. Record the score and the date of the
  score, because EPSS changes daily.
- **CISA KEV**: a listing means exploitation in the wild has been seen.
  A finding added to KEV after detection is re-prioritised, and its due
  date recalculated from the date of the KEV listing.

A shorter time set by a contract or regulation for a system overrides
this matrix for that system.

## 3. Tracker fields

<!-- Guidance: Keep the fields the same in the tool and in this snapshot so the export maps one to one. Pitfall: no field for verification evidence, so closures cannot be checked. -->

| Field | Content |
|---|---|
| Finding ID | VRT-NNN, unique and never reused |
| Asset | Asset ID from the asset inventory, and environment |
| Vulnerability | CVE or tool reference, short description |
| Source | Scanner, penetration test, advisory, researcher |
| Detected | Date first detected (YYYY-MM-DD) |
| CVSS v4.0 | Score and label, vector in the tool |
| EPSS | Probability and score date |
| KEV | Yes or No, with date listed |
| Exposure | Internet-facing or internal |
| Priority | Critical, High, Medium or Low (section 2) |
| Due date | Detected date plus the service level |
| Owner | Asset owner or team |
| Status | New, Triaged, In remediation, Mitigated, Exception, Verified closed |
| Action | Patch, configuration change, upgrade, compensating control |
| Verification | Rescan or retest reference and date |
| Exception ID | Reference to section 6, if any |

## 4. Tracker register

<!-- Guidance: One row per finding per asset. Recompute due dates from the detected date. An auditor samples rows and checks the due date, the verification evidence and any exception. -->

| Finding ID | Asset | Vulnerability | Detected | CVSS v4.0 | EPSS | KEV | Priority | Due | Owner | Status | Verification |
|---|---|---|---|---|---|---|---|---|---|---|---|
| VRT-001 *(Example)* | AST-NET-004 edge VPN appliance | Remote code execution, CVE-[YYYY-NNNNN] | 2027-03-02 | 9.3 (CVSS-BT) | 0.94 | Yes | Critical | 2027-03-09 | IT operations | Verified closed | Rescan SCAN-0312, 2027-03-05 |
| VRT-002 *(Example)* | AST-APP-011 reporting service | Deserialisation in a Java library | 2027-03-04 | 8.7 (CVSS-B) | 0.21 | No | High | 2027-04-03 | Data engineering | In remediation | Pending |
| VRT-003 *(Example)* | AST-SRV-020 internal wiki | Stored cross-site scripting in a plug-in | 2027-02-15 | 5.1 (CVSS-B) | 0.01 | No | Medium | 2027-05-16 | IT operations | Triaged | Pending |
| VRT-004 *(Example)* | AST-SRV-033 build agent | Outdated TLS configuration | 2027-01-20 | 2.3 (CVSS-B) | 0.00 | No | Low | 2027-07-19 | Platform team | In remediation | Pending |
| VRT-005 *(Example)* | AST-APP-002 customer portal | Missing authorisation check found in penetration test PT-2027-01 | 2027-03-10 | 7.1 (CVSS-BE) | n/a (no CVE) | No | High | 2027-04-09 | Product engineering | In remediation | Retest planned |
| VRT-006 *(Example)* | AST-SRV-041 legacy file transfer appliance | Vendor end of support, no fix available | 2027-02-01 | 7.5 (CVSS-B) | 0.04 | No | High | 2027-03-03 | IT operations | Exception | EXC-VUL-001 |

## 5. Finding lifecycle

<!-- Guidance: Use the same status names in the tool. A finding never goes from New straight to Verified closed without a remediation or verification step. -->

```mermaid
stateDiagram-v2
  [*] --> New
  New --> Triaged: priority and owner set
  Triaged --> InRemediation: owner accepts
  InRemediation --> Mitigated: compensating control in place
  Mitigated --> InRemediation: fix becomes available
  InRemediation --> VerifiedClosed: rescan or retest passes
  Triaged --> Exception: cannot fix within service level
  Exception --> InRemediation: exception expires or fix available
  VerifiedClosed --> [*]
```

A finding that reappears within [90 days] *(Example, as set by the
policy)* of verified closure is reopened under its original ID, and its
due date runs from the original detection date. A later recurrence is a
new finding with a new ID.

## 6. Exceptions

<!-- Guidance: An exception is a risk decision, not a status. It needs a risk owner, compensating controls and an expiry. An auditor checks that the acceptance level matches the risk criteria. -->

When a finding cannot be remediated within its service level, the owner
raises a security exception request (`security/security-exception-request`,
DOC-ISMS-122) with the reason, compensating controls, the risk score on
the 5 x 5 scale of the risk methodology (DOC-ISMS-010) and an expiry.
The exception is approved at the authority the risk methodology
(DOC-ISMS-010 section 2.4) sets for the residual risk: the risk owner
for Low; the risk owner and department head for Medium (top management
if the risk category is Averse, DOC-ISMS-015 section 9 rule 1); top
management with a treatment decision for High, recorded in the risk
acceptance record (DOC-ISMS-019). Critical residual risk is not
approvable as an exception: treat it or stop the activity. Maximum
duration is 12 months for Low or Medium and 6 months for High; at expiry
the exception is reassessed, and a renewal is a new decision
(DOC-ISMS-122 section 7).

| Exception ID | Finding | Reason | Compensating controls | Residual score | Accepted by | Expiry |
|---|---|---|---|---|---|---|
| EXC-VUL-001 *(Example)* | VRT-006 | Replacement appliance ordered, delivery in 10 weeks | Service restricted to two partner addresses, monitoring use case MON-UC-007 | 3 x 3 = 9 (Medium) | Risk owner (Head of IT Operations) and [department head] | 2027-06-30 |

## 7. Metrics

<!-- Guidance: Report monthly to the ISMS manager and quarterly through the measurement programme (`isms/isms-measurement-programme`). Recompute totals before publishing. Pitfall: reporting the number of findings closed without the share closed on time. -->

| Metric | Definition | Target *(Example)* |
|---|---|---|
| On-time remediation | Findings closed within service level divided by findings closed in the period | 90% or more |
| Overdue findings | Open findings past their due date at period end, by priority | 0 Critical |
| KEV exposure | Open KEV-listed findings at period end | 0 |
| Mean time to remediate | Average days from detection to verified closure, by priority | Critical under 7 days |
| Scan coverage | Assets scanned in the period divided by assets in scope | 95% or more |
| Active exceptions | Exceptions open at period end, and any past expiry | 0 past expiry |

Worked quarter *(Example)*: Quillmere Analytics Ltd, Q1 2027.

| Item | Count |
|---|---|
| Open at start of quarter | 12 |
| Opened in quarter | 84 |
| Closed and verified in quarter | 71 |
| Open at end of quarter | 25 |
| Closed within service level | 64 |
| Overdue at end of quarter (all High or Medium) | 3 |
| Active exceptions | 1 |

Checks: 12 + 84 - 71 = 25 open at the end. On-time remediation 64 / 71 =
90.1%, just above the 90% target. No Critical or KEV-listed finding was
open at the end of the quarter.

## 8. Size tiers

<!-- Guidance: Show how the tracker scales. These are the library's working tiers, not official definitions. -->

| Topic | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites, IT and OT) |
|---|---|---|---|
| Tool | Cloud provider findings and a container scanner exported to the issue tracker; this template as the monthly snapshot | Vulnerability management platform linked to the service desk | Platform per domain (IT, cloud, OT) with a central data store and dashboards |
| Owners | Engineering teams; the part-time ISMS manager reviews monthly | IT operations and product teams; security team checks priority | Site IT and OT engineering per plant; the security office runs the programme |
| Service levels | Simplified matrix in section 2 | Policy matrix by decision and asset tier | Policy matrix plus OT-specific windows agreed with plant engineering |
| Reporting | Quarterly to management review | Monthly to the steering committee | Monthly per site, quarterly group summary to the CISO and board committee |

## 9. Records and evidence

<!-- Guidance: Link these records from the control evidence matrix (`isms/control-evidence-matrix`, DOC-ISMS-033). -->

| Record | Proves | Owner | Location | Retention *(Example)* |
|---|---|---|---|---|
| Monthly tracker snapshot with metrics | A.8.8 operates | Vulnerability management lead | [Document repository] | 3 years |
| Scan reports and coverage | Detection runs as the policy requires | Vulnerability management lead | [Scanner] | 1 year |
| Rescan and retest evidence | Closures are verified | Asset owners | [Scanner or ticketing tool] | 3 years |
| Exception records | Risk decisions for late findings | ISMS manager | Risk acceptance record (DOC-ISMS-019) | Life of exception plus 3 years |

## 10. References

<!-- Guidance: Check versions at each annual review. -->

| Reference | Edition | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | 2022, Amd 1 published 2024-02-23 | Annex A A.8.8 (cited by number), https://www.iso.org/standard/82875.html |
| ISO/IEC 27002:2022 | 2022 | Control guidance, https://www.iso.org/standard/75652.html |
| FIRST CVSS v4.0 | Published November 2023 | Severity score and vector, https://www.first.org/cvss/v4-0/ |
| FIRST EPSS | Scores updated daily; record the model version in the data feed | Probability of exploitation in the next 30 days, https://www.first.org/epss/ |
| CISA Known Exploited Vulnerabilities catalog | Continuously updated | Evidence of exploitation in the wild, https://www.cisa.gov/known-exploited-vulnerabilities-catalog |

Related templates: `security/vulnerability-management-policy`,
`ops/patch-management-policy`, `security/security-exception-request`,
`security/pentest-report`, `isms/isms-risk-acceptance-record`,
`isms/security-monitoring-procedure`, `isms/control-evidence-matrix`.

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 (including Amd 1:2024) Annex A
control A.8.8 and the guidance in ISO/IEC 27002:2022. Only the control
number is used; the fields, service levels, examples and guidance are
original wording, and no ISO/IEC text is reproduced. ISO and IEC
standards are copyrighted: obtain the official standards from ISO, IEC
or your national standards body. CVSS and EPSS are specifications of
FIRST, and the KEV catalog is published by CISA; they are cited by name
only. Check the current edition of every source before use.
Certification decisions belong to the accredited certification body.
Template licence: MIT.