CIS Control 7 Continuous Vulnerability Management Guide

Many organisations scan and patch every month yet still fail CIS Control 7, because they cannot show which assets were scanned, which findings were fixed and how long the exploitable ones stayed open. CIS Control 7 (Continuous Vulnerability Management) in CIS Controls v8.1 sets the process, patching, scanning and remediation cadence an organisation should meet. This guide explains its seven Safeguards by Implementation Group, the cadences CIS sets, an implementation sequence, the evidence assessors expect and how the Control maps to other frameworks. It is for vulnerability management leads, infrastructure teams and GRC staff. It does not repeat general vulnerability management practice: for that, see the Vulnerability Management Guide.

Key takeaways

IG1 is process plus automated patching. Safeguards 7.1 to 7.4 (a documented vulnerability management process, a risk-based remediation process, and automated operating system and application patching at least monthly) apply to every organisation.
Scanning and tracked remediation start at IG2. Internal authenticated and unauthenticated scans at least quarterly (7.5), external scans at least monthly (7.6) and monthly remediation against the process (7.7) are IG2 and IG3 Safeguards.
Cadence is measurable. The CIS assessment specification fails Safeguard 7.7 if more than 30 days pass between the scans used to show remediation, so scan dates are evidence in their own right.
Coverage depends on Controls 1 and 2. Every Control 7 measure starts from the enterprise asset and software inventories; assets missing from them are never scanned or patched, and never counted.
Scanner credentials are privileged non-human identities. Authenticated scanning needs accounts with broad read or admin rights on every asset, so they need vaulting, scoping and monitoring like any other privileged credential.

What it is and who it applies to

CIS describes Control 7 as developing a plan to continuously assess and track vulnerabilities on all enterprise assets, in order to remediate and minimise the window of opportunity for attackers, and to monitor public and private industry sources for new threat and vulnerability information. The Control is about the whole loop: knowing what is vulnerable, deciding what to fix first, fixing it on a predictable cadence and proving it was fixed.

IG1: CIS calls IG1 essential cyber hygiene. For Control 7 that means 7.1 to 7.4. A small organisation without a scanner can still meet IG1 by documenting its process, enabling automatic updates through its endpoint management and SaaS-managed tools, and checking patch status monthly.
IG2: adds 7.5, 7.6 and 7.7, which require scanning tools and tracked remediation. This is the realistic target for most organisations with dedicated IT staff.
IG3: has no additional Control 7 Safeguards; the difference at IG3 is depth of practice and its links to Control 16 (Application Software Security) and Control 18 (Penetration Testing).

CIS Controls v8.1 (June 2024) clarified some Safeguard descriptions, revised asset classes, added a Governance security function and realigned mappings to NIST CSF 2.0. CIS states that no Implementation Group assignments changed, and the Control 7 Safeguard numbers and titles are unchanged from v8. Take asset class and security function values from the v8.1 spreadsheet if you report them.

Structure and key requirements

Safeguard	Title	IG	Minimum cadence	What it requires
7.1	Establish and Maintain a Vulnerability Management Process	IG1, IG2, IG3	Review annually or on significant change	A documented vulnerability management process for enterprise assets
7.2	Establish and Maintain a Remediation Process	IG1, IG2, IG3	Review monthly or more often	A risk-based remediation strategy documented in a remediation process
7.3	Perform Automated Operating System Patch Management	IG1, IG2, IG3	Monthly or more often	Operating system updates through automated patch management
7.4	Perform Automated Application Patch Management	IG1, IG2, IG3	Monthly or more often	Application updates through automated patch management
7.5	Perform Automated Vulnerability Scans of Internal Enterprise Assets	IG2, IG3	Quarterly or more often	Automated authenticated and unauthenticated scans of internal assets with a SCAP-compliant scanner
7.6	Perform Automated Vulnerability Scans of Externally-Exposed Enterprise Assets	IG2, IG3	Monthly or more often	Automated scans of externally exposed assets with a SCAP-compliant scanner
7.7	Remediate Detected Vulnerabilities	IG2, IG3	Monthly or more often	Remediation through processes and tooling, based on the 7.2 remediation process

What the cadences mean in practice

Monthly patching is a floor, not a target: 7.3 and 7.4 set a monthly minimum. The remediation process in 7.2 should set shorter timelines for actively exploited vulnerabilities; CISA's Known Exploited Vulnerabilities (KEV) catalogue is the usual trigger. CISA recommends every organisation use KEV as an input to prioritisation, even though BOD 22-01 binds only US federal civilian agencies. The catalogue held 1,754 entries in the 21 October 2026 release. See the Zero-Day and Exploited Vulnerabilities Guide.
Quarterly internal scanning is slow for exposed estates: 7.5 allows quarterly scans, which leaves up to three months of blind spot. Agent-based assessment or monthly authenticated scans are common in IG2 organisations that patch monthly, so scan data and patch data line up.
"Authenticated and unauthenticated": unauthenticated scans show what an attacker on the network sees; authenticated scans read installed software and configuration, and find most missing patches. 7.5 requires both. See the Vulnerability Scanning Guide.
"Risk-based" in 7.2: the assessment specification checks that the remediation process considers asset sensitivity (assets storing or processing sensitive data) and the criticality of the vulnerability. CVSS alone does not meet that. See the Vulnerability Prioritisation Guide.

Choosing a prioritisation input

Input	What it tells you	Use it for	Limitation
CVSS base score	Technical severity of the flaw	Initial sort, regulator and customer reporting	Ignores whether it is exploited and how important the asset is. See the CVSS v4 Guide.
CISA KEV	Reliable evidence of exploitation in the wild, with a clear remediation	Fast-track remediation SLA	Lags new exploitation; covers only CVEs with confirmed exploitation
EPSS	Estimated probability of exploitation activity in the next 30 days	Ranking the large middle of the backlog	A probability, not a confirmation; needs asset context
SSVC	A decision (act, attend, track) from exploitation, exposure, automatability and mission impact	Documented, defensible decisions in the 7.2 process	Needs agreed definitions of mission impact. See the SSVC Guide.
Asset criticality	Business and data sensitivity of the asset	The "sensitive assets" element the CIS specification checks	Only as good as the Control 1 inventory

Identity and NHI requirements

Control 7 touches identity in three places, and each is a common audit question.

Scanning credentials: authenticated scanning (7.5) needs accounts with local admin, root or broad read rights on every target. NIST SP 800-53 RA-5(5) Privileged Access addresses authorising privileged access for scanning. Store these credentials in a vault the scanner retrieves from at run time, use separate accounts per environment, block interactive logon, restrict the source to scanner hosts and alert on use from anywhere else. See the Service Account Security Guide.
Patch and management tooling: automated patching (7.3, 7.4) runs through agents and service accounts that can install software on every endpoint and server. Compromise of the patch platform is equivalent to compromise of the estate. Protect its admin roles under Control 6 (MFA for administrative access) and review who can publish packages.
Credentials on vulnerable appliances: when an exposed device is exploited, patching closes the flaw but not the access already gained. In the Ivanti Connect Secure exploitation, attackers chained an authentication bypass and a command injection on VPN gateways before disclosure, and CISA advised assuming that user and service account credentials stored on affected appliances were compromised. Build a rotation step into the 7.2 remediation process for any exploited system that holds credentials, keys or certificates. See the OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide.

Secrets found by scanners (hard-coded keys, default credentials, exposed tokens) are vulnerabilities in their own right. Route them to the secrets owner with a revoke-and-rotate action, not only a "fix the code" ticket. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.

Implementation steps

Anchor on inventories: confirm Control 1 (enterprise assets) and Control 2 (software) inventories exist and are reconciled with endpoint management, cloud accounts and network discovery. Record which assets are internet facing. See the Asset Inventory and CMDB Security Guide.
Write the process (7.1) and remediation process (7.2): define roles (scanner owner, asset owner, remediation owner), sources monitored for new vulnerabilities (vendor advisories, KEV, national CERT alerts), prioritisation rules, remediation timelines by priority, the exception process and the monthly review of the remediation process. See the Vulnerability Management Policy Template.
Automate operating system patching (7.3): configure update rings: a pilot ring (IT and test systems) receives updates first, a broad ring follows after a few days of monitoring, and critical servers follow a scheduled maintenance window. Keep the ability to pause a ring and uninstall an update as the rollback path. See the Patch Management Guide.
Automate application patching (7.4): extend the same rings to browsers, office suites, PDF readers, runtimes and common third-party applications. Remove software that cannot be updated automatically or is end of life, which also supports Control 2.
Stand up external scanning (7.6): scan every internet-facing IP address and hostname from the inventory at least monthly, plus discovery of assets you did not know were exposed. Compare results with the inventory and treat unknown exposed assets as findings. See the Attack Surface Management Guide.
Stand up internal scanning (7.5): deploy authenticated scanning or agents, start with a pilot subnet to check for service impact, tune scan windows for fragile systems (OT, legacy, medical devices) and then extend to all internal assets. Set up the scanning credentials as described above before the first authenticated scan.
Close the loop (7.7): feed scan findings into the ticketing system with owner and due date from the 7.2 rules, rescan to verify, and close tickets only when the rescan shows the asset and vulnerability combination has gone.
Review monthly: report overdue items, exceptions near expiry and coverage gaps to the risk owner. See the Remediation SLAs and Vulnerability Exceptions Guide.

Small versus large organisations

Small (IG1): rely on automatic updates in the operating system, browser and endpoint management tool, document the process on a page or two, and run a monthly check of devices that are behind. Moving most applications to SaaS removes much of 7.4 from your scope.
Large (IG2/IG3): the hard problems are ownership and scale. Use asset tags to route findings to owning teams automatically, set different timelines for internet-facing and internal assets, and measure teams on overdue counts rather than raw finding volume. See the Risk-Based Vulnerability Management Guide.

Evidence and assessment

The CIS Controls Assessment Specification measures Control 7 through counts of assets, scanners and vulnerabilities, and through dates.

Safeguard	Evidence an assessor expects	Measure to report
7.1	Approved vulnerability management process with version history	Months since last update (12 or fewer)
7.2	Remediation process showing risk factors (asset sensitivity, vulnerability criticality) and timelines; minutes or records of monthly reviews	Days since last review (31 or fewer)
7.3	Patch tool configuration and compliance report by operating system version; documented exceptions	Assets on a current, supported operating system build; assets covered by the patch tool
7.4	Application patch configuration and compliance report; exceptions	Assets running current application versions; assets covered by automated application patching
7.5	Scanner configuration showing schedules; authenticated scan success rates; coverage against the asset inventory	Internal assets covered, and covered by authenticated scanning, versus total
7.6	External scan schedule and reports; external asset list reconciled with results	External assets scanned in the last 31 days versus total
7.7	Consecutive scan reports, tickets showing remediation and verification rescans	Days between scans (fails above 30); remediated versus unremediated vulnerabilities

Metrics that show it is working

KEV exposure: count and age of open KEV-listed vulnerabilities on internet-facing assets (target zero beyond the fast-track SLA).
Time to remediate: median and 90th percentile days to remediate by priority band, measured from detection to verified fix.
Authenticated scan success rate: percentage of internal assets where the last authenticated scan logged in successfully; failed authentication silently hides missing patches.
Coverage: percentage of inventoried assets scanned in the last cycle, and number of scanned assets missing from the inventory.
SLA compliance and exceptions: percentage of findings fixed within SLA, and count of exceptions past their review date.

For detection, the techniques Control 7 most directly reduces are T1190 Exploit Public-Facing Application, T1133 External Remote Services, T1210 Exploitation of Remote Services and T1068 Exploitation for Privilege Escalation. When a KEV entry affects an exposed asset, pair patching with a hunt for prior exploitation in that asset's logs.

Mapping to other frameworks

Safeguards	NIST CSF 2.0	NIST SP 800-53 Rev 5	ISO/IEC 27001:2022 Annex A
7.1, 7.2	ID.RA-01, ID.RA-08	RA-5, SI-5	A.8.8 Management of technical vulnerabilities
7.3, 7.4	PR.PS-02	SI-2, SI-2(2)	A.8.8, A.8.19 Installation of software on operational systems
7.5, 7.6	ID.RA-01	RA-5, RA-5(5)	A.8.8
7.7	ID.RA-01, PR.PS-02	SI-2, SI-2(2)	A.8.8
Inventory dependency	ID.AM-01	CM-8	A.5.9 Inventory of information and other associated assets

The UK NCSC's vulnerability management guidance takes the same shape: update by default (ideally automatically), respond quickly to active exploitation, know your assets, triage and prioritise, have the organisation own the risk of not updating, and verify and review the process. NIST SP 800-40 Rev. 4 frames patching as preventive maintenance and is a useful companion for writing the 7.1 process. CIS publishes official mappings with v8.1; use those for formal crosswalks.

Common pitfalls

Scanning only what is in the CMDB: assets never inventoried are never scanned, so coverage looks perfect. Run discovery alongside 7.5 and 7.6 and report assets found by scans but missing from the inventory.
Authenticated scans that silently fail: rotated or locked scanning credentials turn authenticated scans into unauthenticated ones, and the patch gap disappears from reports. Track authentication success as a metric.
Patching the appliance, keeping the attacker: exposed edge devices are patched after exploitation but credentials, sessions and configuration secrets on them are not rotated, as the Ivanti Connect Secure case showed. The remediation process should require a compromise check and credential rotation for exploited systems.
CVSS-only priorities: teams chase thousands of high-CVSS internal findings while a medium-scored KEV vulnerability sits on the VPN. Put exploitation status and exposure ahead of base score.
Exceptions that never expire: end-of-life systems and "cannot patch" exceptions accumulate. Each needs a compensating control (isolation, virtual patching, removal of exposure), an owner and a review date.
Measuring closure without verification: tickets are closed when the patch is deployed, not when a rescan confirms it. 7.7 evidence is based on consecutive scans, so close only on verification.

Practitioner checklist

Confirm your target Implementation Group: IG1 needs 7.1 to 7.4; IG2 and IG3 need all seven Safeguards.
Reconcile the asset and software inventories (Controls 1 and 2) with endpoint management, cloud accounts and scan results.
Approve a vulnerability management process and a risk-based remediation process with timelines, KEV fast-track and exceptions; review the remediation process monthly.
Configure automated operating system and application patching in rings, with pause and rollback tested.
Scan all externally exposed assets at least monthly and internal assets at least quarterly, with both authenticated and unauthenticated scans.
Vault scanner and patch tool credentials, block their interactive logon and alert on use outside scanner hosts.
Close remediation tickets only on a verifying rescan, and keep scan intervals at 30 days or fewer.
Add credential rotation and a compromise check to remediation for any exploited system that holds secrets.
Report KEV exposure, time to remediate, authenticated scan success and coverage to the risk owner every month.

CIS Control 7 Continuous Vulnerability Management Guide: Safeguards, Implementation Groups and Evidence