Vulnerability Management Policy Template (With Patch Management SLAs)

A vulnerability management policy is the document that sets how an organization finds, rates and fixes vulnerabilities, and how long each severity may stay open before the fix is due. The template below keeps vulnerability management and patch management in one policy, with remediation targets of 48 hours for Emergency vulnerabilities (Critical or High, internet-facing, and known to be exploited or with a public exploit), 7 days for Critical, 30 days for High and 90 days for Medium and Low.

What does a vulnerability management policy contain?

A vulnerability management policy contains the rules for the full loop from detection to closure, written as short clauses a team can follow and an auditor can test. The Truvo house-style vulnerability and patch management policy template has these sections:

• Header: policy owner (a role), approver, version, effective date, next review.
• Purpose and defined terms: Vulnerability, CVSS, Known Exploited Vulnerability, Internet-facing, Patch, Remediation Target, Risk Acceptance, Personnel.
• Scope: production and staging servers, internet-facing infrastructure, and the management systems that support them.
• Related policies: secure development, endpoint security, change management, risk management, asset management, incident response and vendor management, by name.
• Policy clauses: identification, severity, remediation targets, remediation clock, severity changes, emergency vulnerabilities, missed targets, exploitation, tracking, patching, patch testing, need to know, records, program review.
• Roles, exceptions, enforcement and review.

The vulnerability management policy holds what happens and by when. Scan tools, schedules, package exclusions and step-by-step procedures belong in the Security Program Manual.

Why vulnerability management and patch management belong in one policy

A combined vulnerability and patch management policy keeps the remediation target and the patching rule in the same document, because applying a vendor patch is the usual fix for an infrastructure vulnerability. When the two are separate documents, we often see a monthly patch window in the patch policy next to a 7-day Critical target in the vulnerability policy, two deadlines for the same fix. With one policy, the team works to one clock.

The combined vulnerability and patch management policy is scoped to infrastructure, and the same Remediation Targets apply to every vulnerability the company finds. Adjacent topics go to the policy for that process:

Vulnerability remediation SLA: the remediation targets by severity

The remediation targets in the vulnerability management policy are the maximum time allowed to fix a vulnerability of each severity. The template has this table, clause (c) of the policy:

The vulnerability management policy clauses, in full

The vulnerability and patch management policy template has each commitment as a lettered clause an auditor can test. Below is the full policy section, with the SLA table above as clause (c).

(a) Identification. Vulnerabilities are identified through:

• Host-based scanning of in-scope servers, at least weekly
• External scanning of internet-facing infrastructure, at least weekly
• Monitoring of vendor advisories, CVE sources and the CISA Known Exploited Vulnerabilities Catalog
• Independent penetration testing, at least annually

(b) Severity. Severity is the scanner rating, including any adjustment the scanner makes for the environment, with the CVSS base score as the fallback. The same vulnerability may have a different severity on different systems. Severity may be adjusted for context, such as a compensating control. The reason is recorded.

(c) Remediation Targets. Vulnerabilities are fixed within these targets: [the severity table above].

(d) Remediation Clock. The clock starts when a vulnerability is detected. For a vulnerability covered by an approved Risk Acceptance, the clock starts when it leaves that Risk Acceptance. Medium and Low vulnerabilities covered by an approved Risk Acceptance follow its review schedule instead of the 90-day target.

(e) Severity Changes. A vulnerability that moves to a higher severity, for example when it is added to the CISA Known Exploited Vulnerabilities Catalog, takes the new Remediation Target from the date of the change. The original due date applies if it is sooner.

(f) Emergency Vulnerabilities. Emergency vulnerabilities are fixed as emergency changes under the Change Management Policy.

(g) Missed Targets. A vulnerability that cannot be fixed within its target is recorded as a Risk Acceptance under the Risk Management Policy. It is reviewed until it is fixed. A vulnerability with no vendor fix available follows the same process.

(h) Exploitation. Active exploitation reported in the wild does not by itself make a vulnerability a security incident. An incident is declared under the Security Incident Response Plan when there is evidence or reasonable suspicion of exploitation against [Short Name].

(i) Tracking. Each vulnerability is tracked from detection to closure. A vulnerability is closed when a rescan or a recorded manual check confirms the fix.

(j) Patching. Security patches for in-scope systems are applied within the Remediation Targets:

• Automatically, for components approved for automatic patching
• Through a manual patch cycle at least monthly, and sooner when a Remediation Target requires it, for components excluded from automatic patching

Components excluded from automatic patching, and the reasons, are recorded in the Security Program Manual. Each manual patch cycle is recorded as a change under the Change Management Policy.

(k) Patch Testing. Manual patches are tested in a non-production environment before production, where practical.

(l) Need to Know. Vulnerability details are shared only with Personnel who need them.

(m) Records. Scan results, patch and change records, and Risk Acceptances are kept for at least [15 months].

(n) Program Review. The program is reviewed at least quarterly to confirm:

• Scans ran on schedule, with no missed cycles
• Scanner coverage matches the asset inventory
• Critical and High vulnerabilities are within target
• Open Risk Acceptances remain valid, with compensating controls in place

Design notes on the Exploitation, Tracking, Patching and Program Review clauses:

• Under clause (h), a KEV listing and an incident are separate events. A Critical or High vulnerability exploited at other companies is an Emergency vulnerability with a 48-hour target when the system is internet-facing. An incident starts when there is evidence or reasonable suspicion of exploitation against the company itself.
• Under clause (i), the team closes a vulnerability on proof. A rescan or a recorded manual check confirms each fix, so the closure date in the tracker is a verified date.
• Under clause (j), patch management works to the same targets. Approved components are patched automatically, and the rest go through a manual cycle at least monthly, recorded as a change. For writing automatic updates into change management as a standard change, see the guide to SOC 2 automatic patching.
• Under clause (n), the team checks scanner coverage against the asset inventory every quarter. At one enterprise financial services team, the vulnerability dashboard count was wrong in both directions: the scanner still reported vulnerabilities on devices that were no longer reachable, and some live assets were outside the scanner's reach. A team running the quarterly coverage check finds both problems.

How missed remediation targets and exceptions work in a vulnerability management policy

A vulnerability that misses the remediation target is recorded as a Risk Acceptance under the Risk Management Policy, with the reason, any compensating control and a review date, and the team reviews the vulnerability until the fix is in. A vulnerability with no vendor fix follows the same process. The security committee in the policy's roles section decides on each Risk Acceptance, so every accepted vulnerability has a documented approver.

Missed remediation targets are common, and some have no fix to apply. When a small firm turned on a free cloud vulnerability scanner for one server, 8 of the 28 vulnerabilities reported were OS packages fixed only in the distribution's next major release, so no patch existed to apply within any target. Each of the 8 needed a Risk Acceptance with the reason, the compensating controls and a review date, plus a plan to rebuild on a newer hardened OS. For the approval workflow and what auditors sample, see the SOC 2 vulnerability risk acceptance guide.

The download kit has the policy as a Google Doc and a Vulnerability Remediation Tracker and Exception Register as a Google Sheet, with these tabs:

• Start here: instructions for copying and filling the sheet.
• Remediation: one row per vulnerability per asset, with the ID, date detected, source, asset, whether the asset is internet-facing, the scanner severity and any adjusted severity with the reason, KEV status, clock start, due date, owner, ticket, status, date fixed, rescan verification, days open and whether the fix met the target.
• Exceptions: each Risk Acceptance with the reason, compensating control, residual risk, approving role, approval date, review date and status.
• SLA: the remediation targets from clause (c). The Due date formula on the Remediation tab reads the SLA tab, so when the team changes a target in the policy and on the SLA tab, every due date updates.

For moving the same records into a ticketing system once volume outgrows a spreadsheet, see the SOC 2 ticketing and SLA guide.

What auditors test in a vulnerability management policy: SOC 2 CC7.1 and ISO 27001 A.8.8

Auditors test a vulnerability management policy by comparing each commitment in the policy against dated evidence from the audit period. Every number in the policy becomes a test: a weekly scanning commitment calls for a scan history with a scan every week.

Two vulnerability management evidence gaps from the same cloud server example:

• Automatic updates with no records. Daily automatic security updates had been on for months and left nothing dated for an auditor to sample. Once the team turned on the provider's native patch service, dated patch-job records were available.
• Scanner cadence below the policy cadence. The free scanner tier rescanned weekly with no on-demand trigger, so the scanning cadence written in the policy has to match what the tool delivers. A daily scanning commitment on that tool would produce an exception on the first sample.

For tool options when the current scanner falls short of the cadence in the policy, see the SOC 2 vulnerability scanner comparison, and for scan types and coverage, see what a vulnerability scan is.

The program work around a vulnerability management policy template

A vulnerability management policy template gives the team the commitments, and the program around the policy is separate work:

• Scope depends on the environment. The template scope is production and staging servers, internet-facing infrastructure and the management systems that support them. At one insurtech company with a two-person IT team, the workable approach was tiered: weekly automated scanning for internet-facing production, quarterly reviews for internal infrastructure behind the VPN, and annual manual checks for low-risk network appliances. Name in the scope section the tiers the team will operate.
• CVSS bands are a starting point. Under clause (b), the team may adjust severity for context and records the reason, and the risk-based ranking (exposure, KEV, reachability) is a procedure the team writes in the Security Program Manual.
• Remediation targets depend on team capacity. A 7-day Critical target needs someone available to patch within 7 days, including holidays. Test the targets against the last quarter of scan data before adopting them.
• The policy needs operating evidence. An auditor reads the policy once and samples the records many times. Under clause (m), scan results, patch and change records and Risk Acceptances are kept for at least 15 months, and the tracker, register and patch history have to cover the whole audit period.

Building the vulnerability management capability around the policy

Truvo Cyber writes vulnerability and patch management policies as part of building the vulnerability management capability, one of the roughly 19 security capabilities in an effective security program. In a security capability assessment, Truvo scores where the capability stands today and sequences the fixes. For the annual independent penetration test in clause (a), see penetration testing advisory.

Frequently asked questions

What is the difference between a vulnerability management policy and a patch management policy?

A vulnerability management policy sets the rules for finding, rating and fixing vulnerabilities from any source, with remediation targets by severity. A patch management policy sets the rules for applying vendor updates. Patching is the main way vulnerabilities get fixed, so combining both in one policy gives patching and remediation a single set of deadlines and avoids two conflicting cadences.

What is a typical SLA for critical vulnerabilities?

The template sets 7 calendar days for Critical vulnerabilities (CVSS 9.0 to 10.0) and 48 hours for Emergency vulnerabilities: Critical or High, internet-facing, and listed in the CISA KEV catalog or with a public exploit available. The remediation clock starts at detection. Choose a target the team can meet every time, because auditors sample closures against the written number.

Does SOC 2 require a vulnerability management policy?

Under SOC 2 CC7.1, the entity uses detection and monitoring procedures to identify new vulnerabilities, and the organization chooses the format. In practice, auditors expect a documented policy with scan cadence and remediation targets, then sample scan history, closed vulnerabilities and approved Risk Acceptances against that policy. ISO 27001 A.8.8, management of technical vulnerabilities, is the equivalent control.

What goes in a patch management policy?

A patch management policy sets which systems are in scope, which components are patched automatically, the manual patch cycle for the rest (at least monthly in this template), the deadlines patches must meet, testing before production where practical, and the change management route for emergency patches. Laptop patching usually belongs in the Endpoint Security Policy.

How should a team handle vulnerabilities that cannot be patched?

A vulnerability with no available fix, or one that misses the remediation target, is recorded as a Risk Acceptance with the reason, compensating controls, an approving role and a review date, and is reviewed until fixed. Under this template, the remediation clock starts when the vulnerability leaves the approved Risk Acceptance, for example when the vendor releases a fix.