--- url: "https://xcademia.com/insights/how-to-build-a-vulnerability-management-programme" title: How to Build a Vulnerability Management Programme description: "The difference between a VM programme that scans and one that fixes: 4 phases, 6 key metrics, smarter prioritisation, and remediation bottlenecks." publishedAt: "2026-05-30T06:15:48.667+00:00" updatedAt: "2026-05-30T06:16:02.933294+00:00" type: article category: cybersecurity author: Xcademia Team tags: - vulnerabilitymanagement - securityoperations - soc - cybersecurity - vmprogramme - riskmanagement - mttr - cvss - epss - patchmanagement --- # How to Build a Vulnerability Management Programme > Most organisations run vulnerability scans. Fewer run vulnerability management programmes that actually reduce risk. Learn the four-phase VM lifecycle, six metrics that matter, and how to prioritise and remediate vulnerabilities using asset criticality, EPSS, and exposure, not CVSS alone. *By Xcademia Team (https://xcademia.com/authors/xcademia-team) · 30 May 2026 · 6 min read* ## That Actually Reduces Risk — Not Just Produces Reports Most organisations run vulnerability scans. Fewer have vulnerability management programmes. The difference is consequential. A scan is a snapshot: here is the list of vulnerabilities that exist on this date. A programme is a process: here is how vulnerabilities are continuously identified, prioritised, assigned, remediated, and verified, with metrics that demonstrate whether the attack surface is getting smaller or larger over time. The organisations that run scans and call it a programme are the ones whose vulnerability backlog grows every quarter, whose critical findings from eighteen months ago are still open, and whose security team spends more time producing scan reports than reducing risk. This guide is for the security professional building or rebuilding a vulnerability management programme that actually closes vulnerabilities rather than cataloguing them. **The metric that distinguishes a functional VM programme from a compliance exercise is mean-time-to-remediate (MTTR) by severity. An organisation that scans monthly but has a critical MTTR of 90 days is not managing vulnerabilities. It is documenting them. MTTR is the number that tells the truth. ## The Four Phases of a VM Programme Every effective vulnerability management programme operates as a continuous cycle across four phases. The cycle never stops. What changes is the speed of each phase and the quality of the transitions between them. PHASE 1**: **Discover and Inventory** You cannot manage vulnerabilities across assets you do not know exist. Phase 1 establishes and maintains a complete, current asset inventory: every endpoint, server, cloud workload, container, network device, and internet-facing system in scope. The inventory is the foundation on which everything else rests. Tools: network discovery scans, cloud asset APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory), endpoint management platforms, CMDB integration. **PHASE 2: Scan and Identify** Authenticated scanning of all in-scope assets against a current vulnerability database. Tools: Tenable Nessus, Qualys, Rapid7 InsightVM. Unauthenticated scanning produces substantially incomplete results; most vulnerability scanners require local credentials to assess patch levels and configuration. Scanning cadence: critical internet-facing assets weekly, internal assets monthly, cloud environments continuously via API integration. Output: a raw vulnerability list with CVSS scores and affected asset details. **PHASE 3: Prioritise and Assign** This is the phase most programmes skip or do poorly. Raw CVSS scores are not sufficient for prioritisation. A CVSS 9.8 vulnerability in a test environment with no network access is lower priority than a CVSS 7.2 vulnerability on an internet-facing authentication endpoint. Effective prioritisation combines CVSS score, asset criticality (business impact of compromise), exploitability in the wild (EPSS score, known exploitation by threat actors), and network exposure. Output: a risk-scored, prioritised remediation queue with ownership assigned to specific teams. **PHASE 4: Remediate and Verify** Assigned vulnerabilities are remediated — patched, mitigated, or risk-accepted with documented justification. Verification is the step most programmes miss: after remediation is reported complete, the system is rescanned to confirm the vulnerability is genuinely closed, not just marked closed in the tracker. Without verification, false closure rates are typically high. MTTR is measured at this phase: from identification to verified closure. The programme uses MTTR trends to identify systemic bottlenecks. ![info-1](https://0a515t3ure77wbvx.public.blob.vercel-storage.com/articles/1780119842972-info-1--20-.webp) ## The Prioritisation Problem CVSS scores were designed to describe vulnerability severity in isolation. They were not designed to tell a specific organisation which of its vulnerabilities to fix first. A CVSS 10.0 on a system that is isolated, has no data, and cannot be reached from the internet is lower priority than a CVSS 6.5 on a customer-facing authentication system. Effective prioritisation requires three inputs that CVSS alone does not provide. **Asset criticality ** Every asset in the inventory needs a criticality rating: what is the business impact if this asset is compromised? Critical assets (customer data repositories, production payment systems, identity infrastructure) warrant faster remediation of lower-severity vulnerabilities than non-critical assets warrant for higher-severity ones. The criticality rating must come from the business, not from IT alone. **Exploitability in the wild ** EPSS (Exploit Prediction Scoring System) provides a probability score that a given CVE will be exploited in the wild within 30 days. A CVSS 7.5 vulnerability with an EPSS score of 0.94 is more urgent than a CVSS 9.2 with an EPSS of 0.01. CISA's Known Exploited Vulnerabilities (KEV) catalogue identifies CVEs that are actively being exploited and should always be treated as critical regardless of CVSS score. **Network exposure ** A vulnerability on an internet-facing system accessible to anyone is categorically more urgent than the same vulnerability on an internal system accessible only to authenticated employees on the corporate network. Exposure context is not captured in CVSS but is the single most important factor in prioritisation for most environments. **The vulnerability management programme that prioritises by CVSS score alone will consistently work on the wrong vulnerabilities. The one that combines CVSS, asset criticality, EPSS, and network exposure will consistently work on the ones that matter most to the specific organisation's risk profile. ## The Remediation Bottleneck In most organisations, the vulnerability management team does not fix vulnerabilities. They identify, prioritise, and track them. The fixing is done by the IT operations team, the cloud infrastructure team, the application development team, or the network team. This dependency is the most common source of VM programme failure. What actually slows remediation ** - **No defined SLAs:** If there is no agreed timeline for remediation by severity, every vulnerability is effectively optional - **Unclear ownership:** If the remediation team does not know who is responsible for a given asset, tickets sit in queues unassigned - **Patch testing requirements:** Enterprise change management processes designed for quarterly maintenance windows are incompatible with weekly patching cadence for critical vulnerabilities - **No executive visibility:** Remediation teams respond to the priorities of whoever is in the room. If security is not in the room, patches do not get prioritised **What actually accelerates remediation ** - **Published SLAs with executive endorsement:** Remediation teams move faster when their management knows the SLAs exist and compliance is reported upward - **Integration with ticketing: **Vulnerabilities auto-create tickets in JIRA, ServiceNow, or whatever the remediation team actually uses, assigned to the right owner - **Metrics visibility:** MTTR dashboards shared with IT leadership produce faster remediation than metrics shared only within the security team - **Patch automation:** Where feasible, automated patching of operating systems and common application components dramatically reduces MTTR for known vulnerabilities **The vulnerability management programme that has excellent scanning and prioritisation but no relationship with the teams that actually fix things is a reporting engine. The one that has established SLAs, integrated ticketing, and metric visibility with IT leadership is a risk reduction engine. The tooling is the same. The relationships and governance are different. Build Applied Security Operations Capability** Xcademia's XSOC programme covers vulnerability management as a core SOC function alongside threat detection, incident response, and security monitoring. Five instructor-led days. Practitioner-assessed. The integrated security operations programme for professionals who need to operate the full SOC function. **Explore **[**XSOC**](https://xcademia.com/courses/xsoc-xcademia-soc-analyst-practitioner) ## Tags `vulnerabilitymanagement` · `securityoperations` · `soc` · `cybersecurity` · `vmprogramme` · `riskmanagement` · `mttr` · `cvss` · `epss` · `patchmanagement` --- ## About this content This Markdown article is the citation-grade twin of [How to Build a Vulnerability Management Programme](https://xcademia.com/insights/how-to-build-a-vulnerability-management-programme). It is published by **Xcademia** (UK Companies House 12322710) and is available for AI search engines and large language models to index, summarise, and cite. When citing or quoting, please attribute *Xcademia* and link back to the source URL above. - Source: https://xcademia.com/insights/how-to-build-a-vulnerability-management-programme - Publisher: Xcademia — https://xcademia.com - Catalogue index: https://xcademia.com/llms-full.txt