The Vulnerability Management Maturity Model: Five Pillars, Four Levels

Episode 11 of the CAXA Technologies Security Operations Series

Most organisations find out where their VM programme sits when something external names the gap. A QSA points at the absence of a lifecycle log: the record demonstrating a finding's journey from discovery through remediation to validated closure, for vulnerabilities at severity thresholds that trigger reporting obligations. Or the finding is a missing mapping between pentest severity classifications and the organisation's risk model: findings are scored, but the scoring is not connected to how the organisation has defined and tiered risk. Neither is an exotic finding. Both sit at the boundary between a programme that documents its intentions and one that operates on them consistently.

The problem with discovering this in an audit is not the cost of remediation. It is that the gap was already present, and without the external trigger there was no systematic way to see it.

A maturity model should answer that question before the auditor does. Most do not manage it, not because the concept is wrong but because the models that exist are either too coarse (the NCSC CAF gives you three states: not achieved, partially achieved, achieved) or measure the wrong thing. The SANS Vulnerability Management Maturity Model is well-structured and worth knowing, but its lower levels measure process capability: whether your process is documented, repeatable, and managed. A programme can score well at those levels and still carry a large unaddressed critical backlog on high-tier assets, because the process is documented but miscalibrated. Vendor-provided models tend to reflect what the vendor can convert into a paid project rather than an objective view of where a programme sits.

Episode 3 defined the Five Pillars of vulnerability management: Asset Management, Vulnerability Assessment, Risk Analysis and Prioritisation, Remediation and Mitigation, and Measurement. This model uses those Pillars as its axes, and defines four levels of progression along each one.

The four levels

Episode 10 introduced a staged progression as a forward reference to this article. The full model:

L1: Reactive.  The programme responds to events rather than operating systematically. Scanning is triggered by advisories or incidents. Remediation is driven by urgency rather than a defined process.

L2: Defined and Documented.  Processes exist and are recorded. SLAs are defined. Coverage is estimated. The programme is recognisable as a programme.

L3: Measured and Risk-Led.  The programme operates on its processes consistently, produces evidence of that operation, and makes decisions based on data rather than intuition. Compliance with major frameworks is a natural output at this level.

L4: Optimised and Continuous.  Automation handles defined classes of work. Evidence is maintained continuously rather than assembled for audit cycles. The frameworks that required L3 effort are now lagging indicators.

One design principle sits underneath the whole model: the weakest Pillar sets the programme's effective maturity level. A well-built prioritisation engine sitting on an unreliable asset inventory produces well-scored findings for the assets it knows about, and misses everything it does not. A programme at L3 on four Pillars but L1 on Pillar 1 operates effectively at L1. The principle applies with decreasing force for Pillars further downstream: a programme at L3 everywhere but L1 on Pillar 5 can still prioritise and remediate effectively; it just cannot report on what it produces. Assess per-Pillar, not as a programme average.

Pillar 1: Asset Management

Asset inventory is the most common gap I have seen at programme start, and the one that blocks everything downstream. It presents in two forms: a manual inventory updated when time allows, with coverage estimated rather than verified; or automated discovery that covers part of the estate but not all of it (typically one cloud account, or on-premises infrastructure only), giving the appearance of an L3 process while leaving material blind spots.

L1: Assets are discovered reactively. The inventory is in someone's head or in a spreadsheet.

L2: A manual or partially automated inventory exists, updated periodically. Asset classification (the tier structure that determines which SLA applies to which finding) is defined but applied inconsistently.

L3: Automated discovery covers the full estate: on-premises, cloud assets via CSPM agentless discovery, and ephemeral assets tracked through pipeline integration. Classification is maintained, not just defined. The CMDB reflects the actual estate.

L4: The asset inventory is the authoritative source for all security programmes. Coverage is continuously verified.

The critical distinction between L2 and L3 on this Pillar is not whether automation exists, but whether it covers everything. Automated discovery scoped to one part of the estate is L2.

Pillar 2: Vulnerability Assessment

L1: Scanning is ad hoc: triggered by advisories or incidents, no authenticated scanning, no SCA.

L2: Scheduled scanning runs on quarterly or monthly cadences. Authenticated scanning covers internal systems. Coverage gaps are acknowledged but not tracked. Detection window (the time between a vulnerability being disclosed and its identification) is not measured.

L3: Scanning cadence is matched to asset tier. Authenticated scanning operates with managed credentials. SCA is integrated in CI/CD. Cloud-native image scanning includes registry rescanning when base images are updated, not only at build time. Detection window is measured.

L4: Pipeline-integrated scanning runs at build time. CSPM provides continuous posture assessment. Scanner coverage is verified by the asset inventory, not assumed.

Pillar 3: Risk Analysis and Prioritisation

L1: CVSS or a severity label is the prioritisation model. Every High is treated the same regardless of exploitability, asset tier, or whether the CVE is in the CISA KEV catalogue.

L2: CVSS is still the backbone, but KEV is reviewed manually and some contextual adjustment for asset criticality exists. EPSS is not formally integrated. Prioritisation decisions are not documented or repeatable.

L3: A multi-signal composite model is operating: CVSS normalised for severity, EPSS as the exploitability signal, KEV as a hard floor regardless of CVSS score. Asset tier is applied as a multiplier. SSVC is used for exception decisions. Episode 6 established the mechanics of this model; L3 on this Pillar means that model is running consistently and the output is auditable.

L4: Composite scoring is automated. Threat intelligence feeds are applied. EPSS movement triggers dynamic SLA adjustment.

One example PCI finding at the L2/L3 boundary is a missing mapping between pentest severity classifications and the organisation's risk model. The report has its own severity scale; the VM programme has its own; neither is connected to how the organisation has defined risk tolerance. The multi-signal model at L3, applied consistently, closes this gap.

Pillar 4: Remediation and Mitigation

L1: Remediation is driven by advisories and audit requests. No formal SLAs, no exception process.

L2: SLAs are defined and remediation is tracked in a ticketing system. An exception process exists on paper but is applied inconsistently. MTTR is not measured.

L3: SLAs are enforced with escalation triggers. The exception process operates with documented risk owners and review dates. Episode 9 established the lifecycle requirements for compensating controls: defined owner, review date, escalation trigger. L3 on this Pillar means those requirements are applied consistently. MTTR is measured by asset tier and severity.

L4: Automated remediation handles defined patch classes. Exception records feed the risk register. Compensating controls are reviewed on a defined cycle rather than left to accumulate.

Another example PCI finding at the L2/L3 boundary is the absent lifecycle log: the record demonstrating a finding's journey from discovery through remediation to validated closure. SLAs defined (L2) is not the same as SLAs enforced with evidence (L3). The ticketing system records the patch; the lifecycle log demonstrates the process was followed and the finding was confirmed remediated.

Pillar 5: Measurement

L1: No formal metrics. Reporting happens after incidents.

L2: Scan completion rates, open vulnerability counts, and basic MTTR are reported to IT leadership. These are activity metrics: they describe what the programme did, not what it produced.

L3: The metrics shift to outcomes: MTTR by tier and severity, vulnerability age distribution, SLA compliance rate, new criticals per week as a leading indicator. Board-level reporting uses risk language.

L4: Programme health indicators are tracked and the audit evidence pack is maintained continuously, not assembled in the weeks before an audit.

Qualys analysis (March 2026) of over one billion CISA KEV remediation records across 10,000+ organisations found that 88% of the 52 highest-profile weaponised vulnerabilities in the dataset were remediated slower than they were exploited; half were weaponised before a patch existed. A programme without MTTR measurement does not know which side of that gap it sits on for the vulnerabilities where remediation speed is even a factor. That is the gap Pillar 5 L3 closes.

The distinction between L2 and L3 on this Pillar is visible in how the programme is run day to day. Organisations that treat vulnerability management as a performance activity (large weekly meetings working through every finding individually, deciding what to patch and who will do it) tend to report in the same mode: volume counts rather than trajectories. The operational inefficiency and the reporting inefficiency come from the same root. Without risk-based prioritisation, everything gets equal attention; without outcome measurement, the only available metric is how many findings closed this week.

A programme at L3 on Pillar 5 presents data as a trajectory: MTTR on Tier 1 assets over the past two quarters, SLA compliance rate trending up or down, critical exposure reducing. That is the framing that lands in leadership conversations, and it is what survives when a regulator or QSA asks whether the programme is actually effective.

Compliance as a consequence

Episode 10 mapped five frameworks to the Five Pillars in detail. The maturity-level summary:

L2 achieves ISO 27001 A.8.8 with documented process and evidence, and meets the NIS2 and UK CSRB baseline. PCI-DSS is partial: Requirement 11.3.1 is met for non-CDE systems, but CDE requires the SLA enforcement of L3.

L3 satisfies the five frameworks Episode 10 mapped for in-scope systems. QSA-ready evidence exists as a natural output of the measurement infrastructure. DORA compliance follows with IR process integration.

L4 exceeds current framework requirements. The frameworks are lagging indicators at this level.

As a calibration: CIS Controls v8.1 IG1 (the basic hygiene tier, covering monthly patch management and quarterly scanning) aligns approximately with L2. IG2, which requires continuous authenticated scanning and monthly external scans, aligns approximately with L3.

Starting the assessment

Apply the model per-Pillar. A programme average tells you nothing useful; the per-Pillar view tells you where the constraint is.

For programmes at L1, the highest-leverage first investment is almost always Pillar 1. Without a reliable asset inventory, every downstream Pillar is operating on incomplete data. Asset tier cannot be consistently applied to findings; SLA enforcement cannot be verified; MTTR cannot be meaningfully measured by tier. Start there.

For programmes at L2, the L2/L3 transition is about operationalising what is documented: SLAs enforced rather than defined, exception process operated rather than described, lifecycle tracking producing evidence rather than assumed. The two PCI findings described earlier are practical diagnostic tests. If either gap exists, the programme is at L2 on those Pillars regardless of what the documentation says.

The Technical Blueprints companion (the next piece in this series) maps the tooling architecture to each maturity level. L1 to L2 does not require enterprise tooling. L3 requires integration between asset inventory, scanning, and ticketing. L4 requires the automation layer. If the per-Pillar assessment above has identified where you are, the Technical Blueprints piece covers what building to the next level looks like in practice.

If you sit on the governance side of this conversation, the companion piece on what VM programme maturity costs organisations is here.