Skip to main content

Pro audit program · v1.0.0

Vulnerability Management Maturity

How well does your VM programme find, prioritise, and fix what matters? 5 minutes.

  • Vulnerability Management Maturity target area
  • — framework
  • 13 controls in this program
  • Cyentrix Cyentrix Trusted Author
Sign in to run → Back to library

About this program

Most breaches start with a vulnerability somebody knew about. This assessment walks the full vulnerability management lifecycle — discovery, scanning, prioritisation, remediation, and reporting. Aligned to ISO 27001 A.8.8, NIST CSF ID.RA / PR.PS, CIS Control 7, and NIS2 Art 21.2(b).

Controls (13)

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

    Medium

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

    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

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

    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

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

    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

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

    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

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

    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

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

    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

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

    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

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

    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

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

    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

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

    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

    Is patching automated for routine OS/software updates?

    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

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

    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

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

    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