CIS vulnerability management policy template contents

What a CIS vulnerability management policy template must contain

A customer, contract or regulator that asks for a CIS-aligned vulnerability policy usually wants to see three things in writing: a documented vulnerability management process reviewed once a year or after significant enterprise changes (Safeguard 7.1), a written remediation process that sets a risk-based strategy for fixing vulnerabilities and is reviewed at least monthly (Safeguard 7.2), and operating system updates on enterprise assets applied through automated patch management at least monthly (Safeguard 7.3). Those three commitments form the core of the policy, and each one needs a named owner, an approval date and a review record that an assessor can inspect. CIS publishes a free policy template for Control 7 as part of its policy template set. That template is written for IG1 Safeguards only. Control 7 contains 7 Safeguards in total (7.1 to 7.7): 4 apply from IG1 and 3 more are added at IG2, so an organization that has to meet IG2 must extend the template with the additional Safeguards. Confirm which Implementation Group your contract or regulator expects before you decide how far the template needs to grow. The organization owns the policy, its approval, its scope and the evidence behind it. A policy signed by leadership is not proof that the scanning, remediation and patching actually happen. An implementation partner can draft the policy against the Safeguard wording, configure the scanning and patching tools, and assemble the evidence for each review cycle. Only an independent auditor, assessor or certification body can report on whether those controls operate as described. Ask any partner to show how each policy statement maps to a named system, report or ticket, and ask your assessor which evidence formats they will accept before the first review cycle starts.

What Safeguards 7.1, 7.2 and 7.3 ask the written policy to cover

Control 7 turns vulnerability handling into three written, repeatable duties: a documented process, a remediation process with its own review cadence, and automated operating system patching. The cards below set out what each policy clause must say, what evidence proves it operates, and which choices belong to the organization rather than to CIS.

Safeguard 7.1: vulnerability management process

The policy must define a written process for finding and tracking vulnerabilities across all enterprise assets, with named owners for scanning, triage and reporting. Assessors look for the document itself, its yearly review date, and a record of any review triggered by a significant enterprise change such as a major acquisition or a new hosting platform. The organization decides the scan scope, scan frequency and who signs off the process. Evidence is the approved document, the revision history and the asset list the scans are meant to cover.

Safeguard 7.2: risk-based remediation process

The policy must describe a remediation process that ranks vulnerabilities by risk and sets how quickly each class is fixed. The assessment specification fails the Safeguard when no remediation process exists or when it was last reviewed more than 30 days ago, so the monthly review date must be recorded and kept current. The organization owns the risk criteria, such as exploitability, exposure and asset criticality, and the remediation timeframes attached to each rating. Evidence includes the signed process, monthly review entries and a sample of tickets showing priority decisions.

Safeguard 7.3: automated operating system patching

The policy must require operating system updates on enterprise assets to be applied through automated patch management at least monthly. Manual patching that depends on individual administrators does not meet the Safeguard, so the policy should name the patch tooling, the scope of managed assets and the exception path for systems that cannot be patched on schedule. The organization decides the patch window, maintenance windows for production systems and how emergency out-of-cycle patches are approved. Evidence is patch deployment reports from the management tool showing completion per asset per month.

IG1 and IG2 split for Control 7

Four of the seven Control 7 Safeguards apply from Implementation Group 1, the essential cyber hygiene baseline, and three more are added at IG2 for enterprises with greater operational complexity. The policy written for IG1 should cover the three Safeguards above and the IG1 subset of the rest, with the IG2 additions drafted as a second phase. Organizations should confirm which Safeguards apply to their group before scoping the policy, since the IG2 additions usually expand scanning and remediation duties. Evidence requirements grow with the group, so the evidence plan should follow the same split.

How the assessment specification scores the 30-day remediation review

The CIS Controls Assessment Specification for v8.1 scores Safeguard 7.2 as failing in two situations: when no remediation process exists, or when the process was last reviewed more than 30 days ago. The Safeguard itself asks for a written remediation process with a risk-based strategy for fixing vulnerabilities, reviewed at least once a month. The 30-day figure is the specification's test window, so a review that is due monthly but completed on day 35 fails even though the team believes it is on schedule. Before relying on this, confirm the exact measures against the current specification in the Control 7 section of the CIS Controls Assessment Specification, because the assessor will use that wording, not the summary here.

A monthly cadence leaves a margin only if the review date is tracked and recorded. Many teams hold the review informally and cannot show when it last happened, which makes the 30-day test impossible to pass with confidence. Record the approval date and the reviewer in the policy document itself, keep a dated revision history, and set a calendar reminder a week before each due date. The specification states what to measure, not how to run the process, so the organization decides the mechanism, but it must be able to show the date. Ask the assessor early which document, version history or approval record they will accept as proof of the last review.

Two other timing tests sit alongside Safeguard 7.2. Safeguard 7.1 asks for a written vulnerability management process reviewed once a year or after significant enterprise changes, so the policy needs a yearly review date and a trigger for major infrastructure or architecture changes. Safeguard 7.3 expects operating system updates on enterprise assets to run through automated patch management at least monthly, so the assessor will look for patch job logs or tool reports covering each month, not a single successful run. Confirm how the current specification phrases each of these measures and which evidence it accepts before you set your review calendar.

The three timing rules the policy must set and record

Safeguard 7.1 asks for a written process for managing vulnerabilities across enterprise assets. The policy should state that the process is reviewed once a year and also after significant enterprise changes, such as a merger, a new platform or a major change to the asset estate. The policy text should name the owner of the process and say where the approved version is kept. A revision history at the front of the document lets an assessor see that the yearly review actually happened and what changed.

Review trigger: State the yearly review and the event-driven review for significant enterprise changes, and define what counts as significant in your organization.
Ownership: Name the role that approves each version, not only the author.
Revision history: Record the version number, date, reviewer, approver and a short summary of changes.
Scope: Confirm the policy covers all enterprise assets, not only servers or only the perimeter.

Evidence an assessor would ask for: the approved policy versions, the revision history, and the minutes or tickets showing the yearly review and any post-change review. Common gap: the policy has a yearly review date printed on it, but no record that the review took place, so the assessor cannot confirm it was performed.

How to adapt CIS's template and get the policy approved

This sequence turns CIS's free IG1 vulnerability management template into an organization-specific policy that names its own risk criteria, remediation timelines and owners, and that management has approved and the organization can evidence. Each step ends with a record that an assessor can read.

Download and read the CIS template
Obtain the Vulnerability Management (Control 7) policy template from CIS's policy templates page and read it against the Control 7 Safeguards it supports, 7.1 to 7.3 among them. The owner is usually the security lead or GRC lead, with IT operations reviewing the technical sections. The step is complete when the team has a list of every section in the template and a note on which Safeguards each section supports.
Map sections to assets and existing tools
Compare each template section with the enterprise asset inventory from Control 1 and the software inventory from Control 2, so the policy names the actual device types, operating systems and applications in scope. Record which scanning and patching tools already run, including any open-source scanner such as Greenbone Community Edition, and which asset groups they do not reach. The output is a scope and tooling map that shows any gaps before the policy is written.
Set risk criteria and remediation timelines
Write the risk-based strategy that Safeguard 7.2 requires, including how the organization rates vulnerability severity, which factors raise priority (such as internet exposure or sensitive data), and the remediation timeline for each priority level. Security leadership sets these values, and IT and business owners confirm they can meet them. The output is a completed risk criteria table with an approver's name against it, not the template's placeholder text.
Assign owners for monthly and yearly reviews
Name one accountable owner for the monthly remediation process review that Safeguard 7.2 requires, and a separate owner for the yearly review of the vulnerability management process under Safeguard 7.1. Name a patching owner for the automated operating system updates in Safeguard 7.3. Each owner should have a deputy so a review does not lapse when someone is absent. The output is a responsibilities table in the policy with named roles, plus a calendar entry for each review.
Obtain management approval
Send the completed draft to the executive or board committee that owns security risk, with the risk criteria and remediation timelines highlighted, since these are the decisions leadership must accept. Record any changes requested and reissue the draft until it is approved. The output is an approved policy version with a version number, approval date and approver name recorded in the document control section.
Publish the policy to staff
Store the approved policy in the controlled document repository and notify the teams that operate scanning, patching and remediation, so they know where it lives and what it requires of them. Withdraw earlier drafts so that only the approved version is in circulation. The output is a published policy location, a distribution record and an archive of superseded versions.
Start recording review dates and patch results
Begin the evidence log on the first working cycle: the monthly remediation review entry, the patch deployment results for each automated OS update cycle, and the scan reports from the chosen tools. An assessor will check these records against the policy's own review dates, so each entry should name the reviewer, the date and the decisions made. The output is a dated monthly review entry and a first set of patch and scan records kept under the policy.

Use CIS's template as written or tailor it for your environment

This table compares adopting CIS's free IG1 vulnerability management template with minimal edits against writing a tailored policy from your own risk method and regulatory obligations. Read each row as a decision point: the first column names the question, and the two columns show how each path answers it. The main takeaway is that the template is a starting point for the Control 7 Safeguards, while a regulated organization usually needs more than the template provides.

Question	Use the CIS template largely as published	Tailor a policy to your risk method and obligations
When it fits	Organizations at Implementation Group 1 with a small, mostly standard estate and no sector regulator asking for more detail	Organizations facing a sector regulator, a customer audit clause or a larger estate with varied asset types and patch cycles
What the policy covers	The documented vulnerability management process, the risk-based remediation process and the monthly automated OS patching commitment, in CIS's own structure	The same Safeguard 7.1 to 7.3 commitments, plus scoring criteria, severity thresholds, exception handling and links to your change and risk registers
Internal effort	Mainly assigning named roles, confirming tool names and filling in review dates; usually a short editing exercise	Mapping existing risk methods, interviewing system owners and reconciling the policy with other security policies; a larger drafting exercise
Who signs off	Typically the security lead and the executive owner of IT operations, with a record of approval	Security, IT operations, risk or compliance functions, and where required, the board or a committee that owns risk appetite
Recurring obligations	Yearly review, or sooner after significant enterprise changes, and the monthly remediation process review that Safeguard 7.2 requires	The same review cycle plus updates when regulatory expectations, contracts or the risk method change
What an assessor still asks for	Evidence that the process is followed: scan records, remediation tickets, patch reports and dated review records	The same evidence, plus proof that the tailored risk method is applied consistently and that exceptions are approved
Coverage of other frameworks	CIS states the Controls do not replace regulatory or compliance schemes, so gaps remain for frameworks with their own vulnerability requirements	Written to cover obligations beyond CIS, such as sector rules or other frameworks you must meet; confirm each requirement with the relevant authority
Main risk	Adopting the template without tailoring it, so roles and tools do not match what happens in practice	Drafting more than the team can run, creating policy text that no one follows and that assessors then test

CIS vulnerability management policy readiness checks before an assessment

Before an assessor reviews a CIS-aligned vulnerability management policy, the documents and records behind Safeguards 7.1, 7.2 and 7.3 need to exist, match each other and cover the same period. The five checks below are the ones an assessor is most likely to sample, and each one can be checked internally before the assessor arrives.

Approved policy with revision history

The written vulnerability management process under Safeguard 7.1 must be approved, dated and reviewed once a year or after a significant enterprise change. Check the document header for an approver, an effective date and a revision table that shows each review. Confirm the most recent review is no more than a year old, and that any major change to the enterprise, such as a new cloud account or acquired business unit, triggered an earlier review. An assessor will test whether the version in use is the one that was approved and whether the review cycle was actually followed.

Dated monthly remediation review records

Safeguard 7.2 requires a remediation process that is reviewed at least monthly, and the assessment specification scores it as failing when the last review is more than 30 days old. Keep a dated record for every review, showing attendees, the vulnerabilities discussed and the decisions taken. Sample two records from the period under review and confirm the dates fall no more than 30 days apart. A gap in the sequence is the most common reason this check fails.

Documented risk-based ranking method

The remediation process must set out a risk-based strategy, so the ranking method needs to be written down and applied consistently. Document the inputs used to rank findings, such as scanner severity, asset criticality, exploit availability and exposure, and the order in which each category is fixed. Select a sample of closed findings and confirm each one can be traced to the ranking rule that set its priority. An assessor will test whether the method in the policy is the method actually used in the tickets.

Current list of in-scope enterprise assets

Scanning and patching cover enterprise assets, so the scope must come from a current asset inventory rather than memory. Export the list from the inventory system used under Control 1, and reconcile it against the scanner target list and the patch management console. Look for assets that appear in one source but not the others, including cloud instances, containers and devices that join the network intermittently. An assessor will compare these lists to see whether the scan and patch scope matches what the enterprise actually runs.

Patch compliance reports for the review period

Safeguard 7.3 requires operating system updates on enterprise assets through automated patch management at least monthly. Generate a patch compliance report for each month in the review period, showing the number of assets, the patch level and the assets that missed the cycle. Record the reason for each exception and the date it was closed. Confirm the reports cover every month, not only the months that look clean, because an assessor will select months at random.

Who writes, runs and checks the vulnerability management policy

The organization owns the vulnerability management policy and everything it requires. Leadership approves the written process under Safeguard 7.1, and the security function owns the risk criteria that decide how quickly each finding is fixed under Safeguard 7.2. Staff who run the monthly remediation review must be named, and they must make the decisions about patch exceptions, compensating measures and risk acceptance. An implementation partner can draft these documents, but the organization's own people must be able to explain and defend them.

Policy approval: A named executive or governance body approves the process and records the date of each yearly review or review after a significant enterprise change.
Risk criteria: The organization sets how severity, asset importance and exposure combine into a remediation priority.
Monthly remediation review: Owners review open findings at least once a month, which is the frequency the assessment specification checks.
Patch exceptions: Each exception, including its reason, compensating control and expiry, is approved and recorded by the organization.
Operational ownership: Asset owners apply OS updates through automated patch management at least monthly under Safeguard 7.3.

Before accepting any partner's draft, confirm that your own staff can name who approves exceptions and where the monthly review record is kept.

What usually breaks the Control 7 policy and how to prevent it

A Control 7 policy rarely fails on its wording. It fails when the review cycle, the risk method, the exception handling and the scan scope stop matching what the organization actually does. The cards below cover five failures that assessors commonly find and the preventive step for each.

Policy written once and never re-reviewed

The vulnerability management process is approved at launch and then left in a shared drive. Safeguard 7.1 expects the written process to be reviewed once a year or after significant enterprise changes, such as a cloud migration or a new scanning tool. Check the document's revision history against your change calendar. Assign a named owner and a fixed annual review date, and record each review with its reviewer and the changes made, even when the outcome is no change.

Monthly reviews recorded only in email

The remediation process is reviewed each month, but the only trace is a thread of messages that nobody can retrieve by date. Safeguard 7.2 is scored against the last review date, so an assessor needs a clear, dated record that the process was examined in the window. Keep a review log in the ticketing or GRC system with the date, the attendees, the findings reviewed and any changes. Store the log where the assessor can read it without asking you to search mailboxes.

Risk method that exists only on paper

The policy describes a risk-based strategy for fixing vulnerabilities, but tickets are worked in order of arrival or by whichever team complains loudest. Safeguard 7.2 asks for a strategy that is actually applied. Check whether severity, asset criticality and exposure appear in the ticket fields and whether the sequence of work follows them. Apply the written method to a sample of recent tickets and note any that do not match it. Those mismatches are the first items to fix before the review.

Patch exceptions with no approval or expiry

Systems that cannot be patched on the monthly cycle are carried as open exceptions with no named approver, no compensating control and no end date. Safeguard 7.3 expects operating system updates through automated patch management at least monthly, so each exception needs a documented reason and a limit. Record who approved the exception, the compensating control, and the date it must be closed or re-approved. Review the open exceptions in the monthly remediation review so none drifts unnoticed.

Scan scope that does not match the inventory

The scanner is configured against a list of hosts that was built years ago, while the asset inventory has grown with cloud instances, containers and new subnets. Assets outside the scan targets never appear in findings, so the process looks complete when it is not. Reconcile scan target ranges and credentialed scan lists against the enterprise asset inventory at each review. Record the assets that are in inventory but unscanned, and assign each one a scanning owner and a date.

Common questions about the CIS vulnerability management policy

Is the CIS vulnerability management policy template free to use?

Yes, the Controls themselves are free for any organization to use to improve its own cybersecurity, and CIS publishes its policy templates for that purpose. The content is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0, though, and commercial use requires CIS's prior approval. If you plan to reuse the template inside a paid service, such as a consulting deliverable or a product, confirm the terms directly with CIS before you start. Your own internal use to run your environment is the case CIS describes as free.

Does adopting the policy alone satisfy CIS Control 7?

No. A policy only states what the organization intends to do. Safeguard 7.1 asks for a written vulnerability management process, and Safeguard 7.2 asks for a remediation process that is reviewed at least monthly, so the assessment looks for both the document and proof that the work happens. Assessors expect scan results, remediation tickets, review records with dates and evidence that operating system patching ran at least monthly. A policy that nobody follows will fail the assessment specification even if its wording is perfect.

How much effort does a CIS Control 7 program take to run?

Effort depends mostly on four drivers: the size and variety of the estate, how many asset types need scanning and patching, the tooling you choose, and how many approval steps a remediation change must pass. The policy text is the smallest part. Ongoing work includes running scans on a schedule, triaging findings, assigning owners, tracking exceptions, running the monthly remediation review and keeping patch records. Ask any provider to break its quote into one-time setup work, such as scanner deployment and policy drafting, and recurring work, such as scan triage and monthly reviews, so you can compare like with like.

Can we write and run a CIS vulnerability management policy in house?

Yes, provided you name a accountable owner, have an inventory of enterprise assets to scan and patch, and keep dated records of each review. The CIS template gives a structure, and an internal team can adapt it to its own roles, systems and approval chain. Where in-house teams usually struggle is consistency: the monthly remediation review and the yearly policy review are easy to miss when staff are busy. A simple calendar, a ticket trail and a named reviewer make these checks much easier to show later.

What will an assessor check for Control 7?

An assessor will check that the written process exists and was reviewed within the required window, and that a remediation process with a risk-based strategy was reviewed within the last 30 days, which is the window the CIS Controls Assessment Specification uses for Safeguard 7.2. They will also look for evidence that operating system updates went through automated patch management at least monthly. Expect them to sample scan reports, check that high-risk findings were fixed or formally accepted, and confirm that exceptions have owners and expiry dates. The CIS Controls Assessment Specification for Controls v8.1 sets out the measures they use.

Do we need an outside partner to implement Control 7?

Not always. Many organizations run the process themselves, and some bring in help for specific gaps, such as deploying a scanner, integrating patch tooling or preparing evidence. An implementation partner can prepare systems and records, but it cannot issue a CIS attestation or certificate. CIS also states that the Controls do not replace any regulatory or compliance scheme, so if a customer or regulator asks for a formal report, an independent assessor must provide it. Ask any partner for a fixed scope in writing, with named deliverables, before work begins.

How DeployOpen prepares Control 7 evidence for your assessment

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the vulnerability scanning, patching and remediation records that support Control 7 are produced where your systems run. We prepare the systems, processes and evidence; your organization owns the policy and its approval, and only an independent assessor can issue a report or certificate.

How we scope

We agree in writing which enterprise assets fall under the vulnerability management process for Safeguard 7.1.
We confirm the remediation process owner, the monthly review cadence and the risk criteria used for Safeguard 7.2.
We document which operating systems and endpoints are in automated patch scope for Safeguard 7.3 before work starts.

How we build

We deploy an open-source scan engine such as Greenbone Community Edition, configured to scan the agreed asset set on a schedule.
We configure automated operating system patch workflows and record each run so monthly patching can be shown from logs.
We set up tracking that links each finding to a risk rating, an owner and a remediation date, aligned to your written process.

How we hand over

We deliver the written vulnerability management and remediation process as drafts for your review, approval and yearly update.
We provide evidence packs with scan reports, patch logs, remediation tickets and monthly review records, labeled by Safeguard.
We walk your team through where each record lives so you can answer an assessor's questions without us in the room.

How we support

Engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, scanner and platform upgrades, and continuous testing are available as a retainer after handover.
Ask us to confirm the assessor's evidence expectations for your environment before the assessment window opens.

CIS vulnerability management policy template: what it must include