Vulnerability Remediation Tracker Template (ISO/IEC 27001 A.8.8)

Remediation service levels from CVSS v4.0, EPSS and CISA KEV, tracker fields, finding register, lifecycle, exceptions, on-time metrics

ISMS 与 ISO/IEC 27001标准ISO/IEC 27001:2022 A.8.8 (cited only); ISO/IEC 27002:2022; FIRST CVSS v4.0, EPSS; CISA KEVvulnerability remediation tracker更新于 2026年11月1日

在编辑器中打开下载 .md

使用方法: Use it to record every vulnerability finding from detection to verified closure under A.8.8 and the vulnerability management policy. Fill the service level matrix and the tracker fields first. The main pitfall is closing findings without a rescan or retest.

预览

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.

Document control

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

Purpose and use
Service levels
Tracker fields
Tracker register
Finding lifecycle
Exceptions
Metrics
Size tiers
Records and evidence
References
Standard and licence note

1. Purpose and use

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

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

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

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

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

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

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

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

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

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.