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.

Where [[Organisation Name]] makes a product with digital elements that is made available on the EU market, an actively exploited vulnerability in that product also has to be reported under the Cyber Resilience Act (Regulation (EU) 2024/2847, Article 14) from 11 September 2026: an early warning within 24 hours of becoming aware of it, a notification within 72 hours and a final report, through the EU single reporting platform to the CSIRT designated as coordinator in the Member State of its main EU establishment, and to ENISA. These reports run beside the deadlines in section 5 and do not replace them. Name who makes them, usually the product owner with Legal.

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

The scan interval counts against the deadline. Because the clock can start at the vendor release date (VM-08), a flaw that sits unscanned for a month can use up most or all of a Priority 2 or Priority 3 deadline before it reaches the tracker. Deploy vendor fixes on the patch cycle without waiting for the scanner, and scan more often than the minimum above where vendors release fixes often.

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. Public exploit code for a High or Critical vulnerability on an internet-facing system counts as well (Appendix A).
• Can an attacker reach it? — the affected system is reachable from the internet, or from any network the organisation does not fully control, such as partner links, guest Wi-Fi or third-party connections (Appendix A).
• 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

The days are counted from the clock start (VM-08). 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 clock start, not from the date a ticket was raised. The clock starts on the earlier of the date the vulnerability was first detected on the system and the vendor release date. Where the vendor has published no fix, it starts on the date of first detection. The vendor release date is the date the vendor first published a fix for the vulnerability, or an advisory that names the fix, for the version running on that system. A finding already past its deadline when it is first detected is overdue from that day (VM-19). A vendor release date found after detection brings the deadline forward in the same way. 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. The 72 hours run from the moment of first detection, or from the moment the finding became Priority 1 (rule RM-12 of the [[Vulnerability Risk Rating & SLA Model]]), not from the vendor release date.

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, vendor release date (where there is a vendor fix) 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]]. A request made after the deadline is not an exception: the finding is overdue and is escalated under VM-19. Where the deadline had already passed on the day the finding was first detected (VM-08), the request is made at the finding's first triage meeting.

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, or the shorter maximum the organisation's exception standard sets for the exception's risk. Renewal requires a new review.

VM-18 Exceptions for Priority 1 vulnerabilities must be approved by the approver of this standard. Where the organisation's exception standard names a more senior approver for the exception's risk, that approver decides instead.

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.

Where [[Organisation Name]] has adopted an exception standard ([[Security Exception & Waiver Standard]]), exceptions under this section are requested, decided and recorded under it, in its one register. Where it and this section differ, the more senior approver and the shorter duration apply.

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; the share fixed within deadline, for Priority 1 and Priority 2 apart; overdue findings and their age; and active exceptions. Beside the coverage figure, report how many register systems are out of scanning scope or not scanned. Beside the deadline and overdue figures, report how many findings are under an exception, and how many were closed because the system was retired.

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; Regulation (EU) 2024/2847 (Cyber Resilience Act).

Appendix A — Definitions