Vulnerability & Exposure Management Standard

1. Purpose

This standard sets the minimum requirements for finding, prioritising, fixing and evidencing technical vulnerabilities in [[Organisation Name]]'s systems. It turns the commitments in the [[Information Security Policy]] into measurable rules: what must be scanned, how often, how quickly each kind of finding must be fixed, and what records must be kept.

Its aim is that the vulnerabilities most likely to be used against the organisation are fixed first, within deadlines that the business has agreed and can meet.

2. Scope

This standard applies to:

• all systems owned, managed or operated by or for [[Organisation Name]], including servers, end-user devices, network and security devices, cloud services under our administrative control, business applications and websites;
• systems operated on our behalf by service providers, where the contract gives us, or requires the provider to provide, vulnerability information;
• all employees, contractors and service providers who administer or support these systems.

Not covered here: secure software development practices ([[Secure Development Standard]]) and penetration testing ([[Security Testing Standard]]). Vulnerabilities found by either are, once reported, managed under sections 5 to 7 of this standard.

3. Roles and responsibilities

4. Scanning requirements

4.1 Asset coverage

VM-01 Every system in scope must be recorded in the asset inventory with an owner, a criticality rating (Critical, High or Standard, see Appendix A) and whether it is reachable from the internet.

VM-02 At least 95% of in-scope systems must be successfully scanned in each scanning period. Systems that are not scanned must be listed with the reason and a date by which they will be.

VM-03 New systems must be added to the scanning scope before, or within 5 working days of, going into production.

4.2 Scan type

VM-04 Servers and end-user devices must be scanned with valid credentials (authenticated scanning) or by an installed agent, wherever the technology allows. Unauthenticated scans alone miss most missing patches and configuration weaknesses.

VM-05 At least 95% of authenticated scans must complete with successful login. Credential failures must be investigated and corrected within 5 working days.

VM-06 Internet-facing systems must also be scanned from outside the organisation's network, to show what an external attacker can reach.

4.3 Minimum scanning frequency

VM-07 Scanning tools must receive vulnerability definition updates at least daily, and their configuration must be reviewed at least every 6 months using the [[Vulnerability Scanner Configuration Review Checklist]].

5. Prioritisation and remediation deadlines

5.1 How priority is set

Each finding is given a priority from 1 (most urgent) to 4, based on three questions rather than on the scanner's severity label alone:

• Is it being exploited? — the vulnerability is listed in a known-exploited catalogue such as CISA's Known Exploited Vulnerabilities list, or credible threat information shows active attacks.
• Can an attacker reach it? — the affected system is reachable from the internet, or from networks the organisation does not fully control.
• How severe is it technically? — the vendor or CVSS severity rating (Critical, High, Medium, Low).

The full scoring model, including how asset criticality and compensating controls adjust priority, is set out in the [[Vulnerability Risk Rating & SLA Model]]. The table below is the approved minimum.

5.2 Remediation deadlines

Where a finding fits more than one row, the higher priority applies. The [[Vulnerability Risk Rating & SLA Model]] applies these rows as a decision table, including how asset criticality can raise a priority.

VM-08 Deadlines are counted in calendar days from the date the vulnerability was first detected on the system, not from the date a ticket was raised. When a finding's priority is raised later — for example, when it is newly listed as exploited — its new deadline is set as the [[Vulnerability Risk Rating & SLA Model]] describes (rule RM-12), and is never later than the deadline it already had.

VM-09 Where a Priority 1 vulnerability cannot be fixed within 72 hours, a compensating control (for example, blocking access, disabling the affected feature or isolating the system) must be applied within 72 hours and recorded.

VM-10 A priority may be lowered only by the standard owner, with the reason recorded, for example when a compensating control removes internet exposure. It must not be lowered to avoid a missed deadline.

6. Remediation and verification

VM-11 Every Priority 1 to 3 finding must be recorded in the [[Vulnerability Remediation Tracker / ticketing system]] with asset, priority, owner, detection date and deadline. Priority 4 findings may be tracked in bulk through the normal patch cycle, but keep their 90-day deadline.

VM-12 Findings are reviewed at a triage meeting at least weekly, following the [[Vulnerability Triage & Remediation Operating Procedure]].

VM-13 A finding is closed only when a later scan confirms it is no longer present, or when other objective evidence (such as a configuration export) is attached. A ticket marked complete is not sufficient evidence on its own.

VM-14 A finding may be closed as a false positive only with recorded evidence, approved by the standard owner.

VM-15 Systems that are no longer supported by their vendor must be recorded, with compensating controls and a planned retirement date, and reviewed at least quarterly.

7. Exceptions

VM-16 If a vulnerability cannot be fixed by its deadline, the asset owner must request an exception before the deadline passes, following the [[Security Exception & Waiver Standard]].

VM-17 Every exception must name a risk owner, describe the compensating controls in place, and have an expiry date no later than 90 days after approval. Renewal requires a new review.

VM-18 Exceptions for Priority 1 vulnerabilities must be approved by the approver of this standard.

VM-19 A finding that is past its deadline without an approved exception is reported as overdue and escalated to the asset owner's manager and, if still open after a further 14 days, to the approver.

8. Reporting

VM-20 The standard owner reports monthly to IT and security leadership, and quarterly to [[the management body / executive committee]], on at least: scan coverage; authenticated scan success rate; open findings by priority; percentage fixed within deadline; overdue findings and their age; and active exceptions.

VM-21 Reports must use the definitions in the [[Vulnerability Management Metrics Workbook]] so that figures are comparable between periods.

9. Records to keep

10. Compliance

Compliance with this standard is monitored through the reports in section 8 and checked through [[internal audit / independent review]]. Repeated failure to meet deadlines without an approved exception is escalated as described in VM-19 and may be treated under [[the disciplinary procedure / supplier performance terms]].

11. Review

This standard is reviewed at least every 12 months, and also after a significant incident caused by an unfixed vulnerability, a major change in the systems in scope, or a change in applicable regulation.

12. Related documents

13. Adapting this template

14. Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. 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.

Appendix A — Definitions