Vulnerability Management Maturity

About this program

Controls (13)

1. Do you have a complete, current inventory of internet-facing assets (hosts, services, certificates, domains)?

   Medium

   This control requires the organization to maintain a continuously updated inventory of all internet-facing assets, including web servers, API endpoints, domain names, SSL/TLS certificates, cloud services, and other externally accessible infrastructure. The inventory must be comprehensive (covering all subsidiaries, business…

   How to test + evidence

   Risk: You can't patch what you can't see. Externally-visible reconciliation catches shadow IT, decommissioned services left running, and forgotten subdomains.

   Testing procedure: Pull the asset inventory and reconcile to two independent sources: external port scan (your perimeter) and DNS records. Investigate any host or service in the scan that is not in the inventory.

   Evidence to collect: Asset inventory export with classifications External port scan from the audit period DNS zone records for owned domains Reconciliation notes

2. Do you maintain an inventory of internal assets including OS, software, and version?

   Medium

   This control requires organizations to create and continuously maintain a comprehensive inventory of all internal assets, including details such as operating systems, installed software packages, and their respective versions. The inventory serves as a foundational element for vulnerability management, patch…

   How to test + evidence

   Risk: Vulnerability prioritisation depends on knowing every asset's software version. Stale inventories produce stale risk decisions.

   Testing procedure: Inspect the inventory tool (osquery, Wazuh, SCCM, Lansweeper). Verify it covers servers, workstations, network gear, and that records include OS/version. Sample 10 assets and confirm version data is current.

   Evidence to collect: Inventory tool screenshot showing OS + version Coverage report (% of asset estate) Sample 10 records vs reality

3. How often do you scan internet-facing systems for vulnerabilities?

   Medium

   This control establishes the frequency at which automated vulnerability scanning is performed against internet-facing assets such as web applications, mail servers, VPN gateways, and public APIs. Scanning identifies exploitable weaknesses (CVEs, misconfigurations, weak ciphers) before attackers can leverage them. Regular…

   How to test + evidence

   Risk: CISA KEV (Known Exploited Vulnerabilities) requires 14-day SLA for federal systems — continuous scanning is the only way to meet that on a real estate.

   Testing procedure: Inspect scan schedules for the external scanner. Pull the last 4 scan reports. Confirm coverage matches the asset inventory.

   Evidence to collect: Scan schedule configuration Last 4 scan reports Coverage report (% of assets scanned)

4. How often do you scan internal systems for vulnerabilities (authenticated where possible)?

   Medium

   This control establishes the cadence and methodology for conducting vulnerability scans against internal infrastructure, endpoints, databases, and applications. Authenticated scanning uses credentials to probe deeper into system configurations, installed software, and patch levels—providing more accurate identification of exploitable weaknesses than…

   How to test + evidence

   Risk: Unauthenticated scans miss most real findings. Credentials-on-the-host scans surface installed-software CVEs that external scanners cannot detect.

   Testing procedure: Inspect internal scanner config. Verify credentials are configured for authenticated scans (10x more accurate than unauthenticated). Check coverage of servers, workstations, and network devices.

   Evidence to collect: Scanner config showing credentials Sample authenticated scan report Internal scan schedule

5. Do you actively monitor the CISA KEV (Known Exploited Vulnerabilities) catalogue for relevance to your estate?

   Medium

   This control ensures the organization maintains a systematic process to monitor the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities (KEV) catalogue and correlate entries against the technology estate to identify applicable threats. The KEV catalogue contains vulnerabilities actively…

   How to test + evidence

   Risk: KEV represents vulnerabilities being actively exploited — they have the highest probability of mattering. Monitoring KEV is the single highest-leverage VM activity.

   Testing procedure: Inspect the KEV monitoring process. Cross-reference the latest KEV catalogue against your asset inventory for matches. Trace one KEV-listed CVE to its remediation in your environment.

   Evidence to collect: KEV monitoring tool / script Recent KEV-driven remediation tickets Last 3 KEV adds traced to your assets

6. How do you prioritise findings (CVSS alone, EPSS-augmented, asset criticality, exploitation observed)?

   Medium

   This control governs how an organization ranks and prioritizes vulnerability remediation efforts by combining multiple risk signals beyond base CVSS scores. Effective prioritization integrates exploit prediction scoring systems (EPSS), asset criticality classifications, threat intelligence on active exploitation, and environmental context…

   How to test + evidence

   Risk: CVSS alone correlates poorly with exploitation. EPSS (the probability of exploitation) and asset criticality are the discriminators that turn lists into queues.

   Testing procedure: Inspect the prioritisation policy. Pull a sample 20 findings and verify each has a documented priority justification using the documented criteria.

   Evidence to collect: Prioritisation policy / scoring matrix Sample 20 prioritised findings EPSS / KEV integration in scanner / SIEM

7. Are findings prioritised with business context (data classification, regulatory scope, criticality)?

   Medium

   This control ensures that security findings from vulnerability scans, penetration tests, and security assessments are ranked using organizational context such as asset criticality ratings, data classification levels (e.g., PII, PCI, PHI), regulatory applicability (e.g., GDPR, HIPAA, SOX), and business impact…

   How to test + evidence

   Risk: A medium CVSS on a crown-jewel system out-prioritises a high CVSS on a sandbox. Without business context VM becomes mechanical CVSS sorting.

   Testing procedure: Sample 10 findings on systems of varying criticality. Verify each has a business owner, criticality tier, and documented rationale for the priority assigned.

   Evidence to collect: Business criticality classification per asset Sample findings with business owner + tier Crown-jewel inventory

8. What is your SLA for remediating critical / KEV-listed vulnerabilities on internet-facing systems?

   Medium

   This control defines and enforces a documented Service Level Agreement (SLA) that specifies maximum timeframes for patching or remediating vulnerabilities classified as critical or listed in CISA's Known Exploited Vulnerabilities (KEV) catalog on systems exposed to the internet. The SLA…

   How to test + evidence

   Risk: CISA mandates 14 days for federal systems. Internet-facing critical CVEs are exploited within hours of disclosure — anything beyond 7 days is a significant risk window.

   Testing procedure: Pull all critical / KEV-listed findings from the audit period. Calculate mean time to remediate. Compare to the SLA. Investigate any over-SLA findings for documented exceptions.

   Evidence to collect: SLA policy MTTR report for critical findings Sample 10 remediated findings within SLA Exception register for over-SLA findings

9. What is your SLA for remediating critical findings on internal systems?

   Medium

   This control defines and enforces a Service Level Agreement (SLA) specifying the maximum allowable time between discovery of a critical vulnerability or security finding on internal systems and its successful remediation. The SLA typically distinguishes between critical, high, medium, and…

   How to test + evidence

   Risk: Internal SLAs can be longer than external because exploitation requires foothold first — but 30 days remains the credible upper bound for criticals against lateral-movement risk.

   Testing procedure: Same as external SLA but for internal critical findings. Calculate MTTR and compare.

   Evidence to collect: Internal SLA policy MTTR report for internal criticals Sample 10 internal remediations

10. Are exceptions (cannot remediate) formally requested, approved by risk owner, time-bound, and tracked?

    Medium

    This control ensures that when security vulnerabilities, policy violations, or compliance gaps cannot be remediated within normal timelines, a formal exception process is followed. The process requires written justification, approval by a designated risk owner (typically business or system owner…

    How to test + evidence

    Risk: Auditors care more about the exception process than that no exceptions exist. Time-bound, owner-approved exceptions are the only sustainable model — anything else accumulates silent risk.

    Testing procedure: Inspect the exception register. Sample 10 exceptions and verify each has: documented reason, risk-owner approval, expiry date, compensating control, review cadence.

    Evidence to collect: Exception register Sample 10 exceptions with approvals + expiry Compensating control documentation

11. Is patching automated for routine OS/software updates?

    Medium

    This control ensures that operating system and application software patches are deployed automatically through enterprise patch management systems, reducing manual intervention and time-to-patch for routine, non-critical updates. Automated patching leverages pre-approved update policies, scheduled maintenance windows, and rollback capabilities to…

    How to test + evidence

    Risk: Manual patching cannot keep up at any scale beyond ~50 systems. Automation with staged rings catches breakage early and cuts MTTR by an order of magnitude.

    Testing procedure: Inspect the patch tool (Intune, WSUS, Ansible, BigFix). Verify scheduled deployment with rings (test → pilot → prod). Pull patch compliance report.

    Evidence to collect: Patch tool config showing rings Patch compliance report Sample patch deployment with timeline

12. Do you track and report VM KPIs (open findings by severity, MTTR, scan coverage, exception count)?

    Medium

    This control requires organizations to define, collect, and regularly report key performance indicators (KPIs) for their vulnerability management (VM) program. Core metrics include the count of open findings segmented by severity level (Critical, High, Medium, Low), mean time to remediate…

    How to test + evidence

    Risk: Trend lines tell the story that point-in-time numbers don't. Boards care about direction, not absolute counts.

    Testing procedure: Inspect the VM dashboard. Verify metrics: open findings by severity, MTTR, scan coverage %, exception count, KEV-matched count. Trend over 6 months.

    Evidence to collect: VM dashboard / monthly report KPI definitions and targets 6-month trend

13. Do you run penetration tests at least annually against critical applications and infrastructure?

    Medium

    Penetration testing involves simulating real-world attacks against critical applications, systems, and network infrastructure to identify exploitable vulnerabilities before adversaries do. Testing must be conducted at least annually by qualified internal teams or third-party specialists using industry-standard methodologies such as PTES,…

    How to test + evidence

    Risk: Scanners find known patterns. Pen tests find logic flaws, chained vulnerabilities, and the weak controls that humans walk past. Both are needed.

    Testing procedure: Inspect the most recent pen test report. Verify scope, executive summary, finding remediation status, and re-test confirmation.

    Evidence to collect: Pen test report (most recent) Scope of test + methodology Remediation tracker Re-test confirmation