Vulnerability Management Policy Template: Scope, Timelines and Roles

Auditors, regulators and certification bodies increasingly ask not just whether you scan for vulnerabilities, but where the documented policy is that says what gets scanned, how fast findings are fixed, and who may approve a delay. This template gives you that policy. It covers scope, roles, scanning frequency, a remediation timelines table, exceptions, and the non-human identity findings most policies forget: secrets exposed in code and expiring certificates. The default values are set so that they meet the common external timelines (CISA KEV due dates, PCI DSS v4.0.1 Requirement 6.3.3, UK Cyber Essentials and the Essential Eight), but you must confirm which of these apply to you. Adapt it with your security, IT operations, engineering and risk teams, and have it reviewed by compliance before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [CISO] and [30 days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• Before changing any timeline in section 4.4, check it against the external deadlines that apply to that asset group. The reasoning behind each value, and how to tier findings, is explained in the Remediation SLAs and Vulnerability Exceptions Guide, the companion to this template.
• Keep procedures (scanner configuration, ticket workflow, maintenance windows) in separate documents referenced from this policy, so the policy itself changes rarely.
• Place this policy beneath your information security policy. See the Information Security Policy Template and the Security Policy Framework Guide.

1. Purpose

This policy sets the requirements for identifying, prioritising, remediating and verifying technical vulnerabilities across [Organisation]'s technology estate, and for governing the cases where remediation cannot be completed on time. Its aim is to reduce the time that exploitable weaknesses remain open, to meet [Organisation]'s legal, regulatory and contractual obligations, and to ensure that every decision to accept vulnerability risk is made by an accountable person, recorded and time-limited.

2. Scope

This policy applies to all assets owned, operated or managed by or on behalf of [Organisation] that store, process or transmit [Organisation] data or connect to [Organisation] networks, including:

• Servers, workstations, laptops and mobile devices, including their operating systems, drivers and firmware.
• Network and security devices, including firewalls, VPN and remote access gateways, load balancers and wireless controllers.
• Applications and services, whether commercial, open source or developed by or for [Organisation], including their third-party libraries.
• Cloud infrastructure, platform and SaaS configurations under [Organisation]'s control, container images and infrastructure-as-code templates.
• Identity infrastructure, including directory services, identity providers and privileged access tools.
• Non-human identity artefacts: secrets (API keys, tokens, passwords, private keys) exposed in source code, build logs, container images or configuration, and digital certificates used by [Organisation] services.
• [Operational technology and medical devices], subject to the maintenance group arrangements in section 4.6.

It applies to all employees, contractors and third parties who own, administer or develop these assets. Third-party providers that host or manage assets in scope must meet equivalent requirements through contract, as set out in section 4.8.

3. Roles and responsibilities

4. Policy statements

4.1 Asset inventory and ownership

1. Every in-scope asset must be recorded in [the asset inventory or CMDB] with a named owner who is a current employee.
2. Assets discovered without an owner must be assigned one within [10 working days] or isolated.
3. Asset discovery must run at least [fortnightly] to identify assets missing from the inventory.

4.2 Vulnerability identification

1. [Organisation] must use authenticated (credentialed) scanning wherever the asset supports it.
2. Scanning must run at least at the frequencies below, and after significant change:

• The vulnerability team must monitor [vendor advisories, the CISA Known Exploited Vulnerabilities catalog, national CERT alerts and threat intelligence] for vulnerabilities affecting [Organisation] assets, including those that scanners cannot detect.
• Penetration tests and vulnerability disclosure or bug bounty reports must be entered into the same tracking process. See the Bug Bounty and Vulnerability Disclosure Guide.

4.3 Prioritisation

1. Each finding must be assigned a priority (P0 to P4) based on known exploitation, exploit likelihood, technical severity and asset exposure and criticality, using [the prioritisation procedure]. CVSS base score must not be the only input.
2. Any finding listed in the CISA KEV catalog, or with credible evidence of active exploitation, must be treated as P0.
3. Priority must be raised, and the deadline shortened, when exploitation status changes. Priority must not be lowered because a finding is old.

4.4 Remediation timelines

Timelines run from [vendor release of the fix, or the date the finding is first identified where no vendor release applies]. Where an external requirement (such as a KEV due date) sets a shorter deadline, the shorter deadline applies.

1. Automatic updates must be enabled wherever the product supports them, unless an asset is in a maintenance group with an approved alternative plan.
2. Software and firmware no longer supported by the vendor must be replaced, removed or isolated by [date or within 6 months of end of support]. Continued use requires a long-term exception under section 5.

4.5 Remediation and verification

1. A finding is closed only when a rescan or configuration check confirms the fix, or the component has been removed. A mitigation is not closure.
2. For vulnerabilities that may have disclosed credentials, sessions or keys, or given code execution on a host that stores secrets, closure must also include revoking active sessions and tokens and rotating secrets held on the affected host. See the Secrets Rotation Runbook Template.
3. Patches must be tested and deployed under [the patch management procedure], using phased rollout where available. Emergency changes for P0 findings follow [the emergency change procedure].
4. For exposed secrets, removing the secret from code is not sufficient: the secret must be revoked, and the system that relied on it reissued a new credential stored in [approved secrets manager].

4.6 Maintenance groups

1. Assets with similar constraints (for example [OT], [medical devices], [legacy mainframe]) may be placed in a maintenance group with its own documented remediation plan, timelines and approved long-term mitigations, approved by [CISO].
2. Each maintenance group plan must be reviewed at least [annually].

4.7 Escalation

1. Open findings must be escalated to the asset owner's line manager at [75 per cent] of the deadline and to [the CISO] at the deadline.
2. P0 findings without a change ticket within [24 hours] must be escalated to [the CISO] immediately.

4.8 Third parties

1. Contracts with providers that host or manage in-scope assets must require them to remediate vulnerabilities within timelines no longer than those in section 4.4, to notify [Organisation] of critical vulnerabilities affecting its services within [X days], and to report remediation status on request.

5. Exceptions

1. Where a finding cannot be remediated within its deadline, the asset owner must request an exception before the deadline in [the exception register]. A request after the deadline is recorded as a policy breach.
2. Each request must state the finding IDs and assets, the business reason, the proposed compensating controls, and a target remediation or decommission date.
3. The vulnerability team must assess the residual risk and verify that compensating controls address the actual attack path before approval.
4. Approval authority is: P0 and P1, [CISO]; P2, [Head of security risk]; P3 and P4, [asset owner's director with security sign-off]. Nobody may approve an exception for an asset they own.
5. Every exception must have an expiry date no later than [90 days] from approval, or the decommission date for end-of-life assets, reviewed every [6 months]. Expired exceptions revert automatically to breach status.
6. An exception may be renewed once at the same level. Further renewals require approval by [the executive risk owner].
7. Findings confirmed as false positives or not applicable are closed with technical evidence, not treated as exceptions, and must be re-validated when the asset's software version changes.

6. Compliance and monitoring

1. The vulnerability team must report monthly to [the CISO] and quarterly to [the risk committee] on:
   • Percentage of findings remediated within deadline, by priority and asset group.
   • Mean and median time to remediate, by priority.
   • Number of KEV-listed findings open past their due date.
   • Number and age of open exceptions, and renewals.
   • Credentialed scan coverage against the asset inventory.
   • Exposed secrets found, and median time to revoke.
   • Certificates expiring within 30 days without a renewal scheduled.
2. Compliance with this policy is subject to internal audit at least [annually].
3. Assets with repeated or serious non-compliance may be isolated from the network by [the CISO]. Breaches of this policy by staff may be handled under [disciplinary procedure].

7. Review and approval

Implementation guidance

• Check the external timelines first: CISA BOD 22-01 requires US federal agencies to remediate KEV entries within two weeks for CVEs assigned from 2021 onwards (six months for older CVEs) unless CISA sets a shorter date, and each KEV entry has its own due date. PCI DSS v4.0.1 Requirement 6.3.3 requires critical or high-security patches within one month of release. Cyber Essentials v3.2 requires updates within 14 days of release where they fix a vulnerability with a CVSS v3 base score of 7 or above, or the vendor rates the fix critical or high, or gives no severity. The Essential Eight sets 48 hours for critical or exploited flaws in online services. If any apply, your values in section 4.4 must be equal or shorter.
• Regulated EU entities: DORA's ICT risk management RTS (Delegated Regulation (EU) 2024/1774, Article 10) requires automated scanning at least weekly for assets supporting critical or important functions, recorded tracking of every vulnerability until resolved, and defined patch deadlines with escalation. The default weekly frequency in section 4.2 reflects this. NIS2 sets vulnerability handling as a required risk management measure without fixed days. See the DORA Guide and the NIS2 Directive Guide.
• Start in report-only mode: publish the policy, run the timelines for one quarter without escalation, then fix delivery blockers before enforcing. Do not quietly lengthen deadlines that are missed.
• Treat exceptions as maintenance groups where they recur: NIST SP 800-40 Rev. 4 recommends planning for unpatchable assets through maintenance groups with approved long-term mitigations rather than permanent exceptions.
• Wire the NHI items into existing tools: route secrets scanning alerts and certificate expiry alerts into the same tracker as scanner findings so they appear in section 6 reporting. See the Secrets Management Guide and the Machine Identity, PKI and Certificate Lifecycle Guide.
• Map for auditors: this policy supports NIST CSF 2.0 ID.RA-01 and ID.RA-06, NIST SP 800-53 Rev. 5 RA-5, SI-2 and CA-5, CIS Controls v8.1 Control 7, and ISO/IEC 27001:2022 Annex A 8.8.

Related NHI Mgmt Group resources: Vulnerability Management Guide · Patch Management Guide · Vulnerability Prioritisation Guide · Remediation SLAs and Vulnerability Exceptions Guide · Security Exceptions and Risk Acceptance Guide