Vulnerability Management Maturity Model: Five Programme Levels
A vulnerability management programme is mature when its discipline holds on the live operating record between assessments, not only when its dashboards look clean at audit week. Internal security teams that read maturity through tooling depth alone end up reporting Managed metrics on Repeatable-level discipline. Programmes that read maturity through the five-dimension grid (discovery, triage and severity, remediation governance, exception and risk acceptance, leadership reporting) surface the uneven capability that single-axis metrics hide.1,2,3,11,12
This research lays out a defensible vulnerability management maturity model in five levels and five dimensions, anchored to ISO 27001 Annex A 8.8, NIST SP 800-53 RA-5 and SI-2, PCI DSS v4.0 Requirements 6 and 11, SOC 2 CC7.1, CISA BOD 22-01, and the OWASP SAMM and BSIMM scaffolding. The argument is not that Optimised is right and Reactive is wrong. The argument is that programmes that score themselves honestly on the five-dimension grid sequence their investment toward the lowest-scoring dimension rather than spreading capital across every dimension in parallel.2,3,5,6,7,11,12
Maturity is a grid, not a number
When a CISO asks whether the programme is mature, the question collapses two questions into one. The first is the level question: how disciplined is the operating cadence (event-driven, cadence-based, policy-defined, measured, or upstream-loop-closed). The second is the dimension question: at which capability is the discipline actually operating (discovery, triage, remediation, exception, reporting). Programmes that answer one of these at the cost of the other end up with the same headline rating describing very different operating realities.
The five-by-five grid below frames the answer. Each row is a maturity level (Reactive, Repeatable, Defined, Managed, Optimised) drawn from the CMMI scaffolding. Each column is a dimension that vulnerability management programmes have to operate to be defensible (discovery, triage and severity, remediation governance, exception and risk acceptance, leadership reporting). A programme is mature when it scores similar levels across all five dimensions; the most common picture is uneven maturity (Level 4 on discovery, Level 2 on remediation governance) that single-axis metrics hide.1,11,12,13
The audit, regulatory, customer, and incident reads of the programme each sample a different cell of the grid. The audit reads exception and reporting. The customer questionnaire reads discovery and remediation. The incident reads triage and remediation. Programmes that map their evidence to the grid rather than to a single rating survive each read because the cell the reader sampled is the cell the programme already scored honestly.
Five maturity levels
The level scaffolding maps to CMMI structure (Initial, Managed, Defined, Quantitatively Managed, Optimising) but uses vulnerability management vocabulary. Names below are intentionally operational rather than abstract because the evidence the programme produces at each level is what the audit, regulator, and audit committee actually read.1,11,12
| Level | Operational signature | Reading the evidence |
|---|---|---|
| 1. Reactive | Findings are found when an audit, customer, regulator, or incident forces a scan. Tracking lives in spreadsheets or scanner consoles. Severity is ad-hoc. Closure has no SLA. Exceptions live in email. | Audit reads gaps. Customer questionnaire reads informal answers. Incident reads slow. Most programmes that have not invested in vulnerability management as a discipline operate here even with modern scanners. |
| 2. Repeatable | Scanning runs on cadence. Critical findings carry an SLA. Tracking has moved off spreadsheets onto a system of record. Severity follows CVSS but is not yet calibrated against exploit signal. | Audit reads cadence. Customer questionnaire reads policy commitments. Incident reads reproducible. Cadence operates partially across the estate; full coverage is the next investment. |
| 3. Defined | Written policy. Scanning across the in-scope estate (external, authenticated, code). Severity calibrated against CVSS plus KEV plus EPSS. SLA per severity band. Defensible exception process. Monthly leadership reporting. | Audit reads framework satisfied. Customer questionnaire reads documented programme. Incident reads contained. ISO 27001 Annex A 8.8 routinely satisfied at this level; SOC 2 CC7.1 satisfied if the cadence operates across the observation period. |
| 4. Managed | Cycle-time stages (triage, ownership, investigation, remediation, verification, closure) are measured. Inflow is read against closure per severity. Retest durability is a programme metric. Reporting against external SLA references (CISA BOD 22-01, PCI DSS 6.3.3). | Audit reads quantitatively managed. Customer questionnaire reads measured. Incident reads short cycle. Programmes at this level can answer the throughput question without a separate evidence sprint. |
| 5. Optimised | Discovery, remediation, and detection upstream are linked. Finding inflow shrinks at source through secure-by-default platform patterns, baseline enforcement, and SDLC integration. Same class of finding does not recur. | Audit reads continuous improvement. Customer questionnaire reads upstream prevention. Incident reads upstream prevented. Few programmes operate fully at this level; most Level 4 programmes have isolated Level 5 patches in mature platforms. |
The level descriptions read a programme as it actually operates rather than as it self-declares. A programme that has bought a Level 4 platform but operates Level 2 discipline reports Managed metrics on Repeatable-level discipline; the audit and the next incident read the discipline gap rather than the tooling depth. The platform purchase is a necessary condition for higher levels, not a sufficient one.
Five dimensions the grid scores
Each dimension below scores a distinct capability the programme has to operate. The dimensions are roughly orthogonal so a programme can score Level 4 on one and Level 2 on another; the grid is designed to surface that asymmetry, not hide it. Specific level descriptions per dimension follow each summary.
Dimension 1. Discovery
How comprehensively the programme finds vulnerabilities across the in-scope estate. Includes asset coverage, scanner mix (external, authenticated, code, API, cloud), authenticated coverage of applications behind login, code coverage across the repository inventory, and external attack-surface coverage. Reactive discovery scans only the assets the audit asks about; Optimised discovery covers the full asset register and feeds the source code SDLC.
Level signals: Reactive scans only audit-driven targets. Repeatable scans the in-scope external surface on cadence. Defined adds authenticated coverage and code scanning. Managed reads scan coverage against the asset register and reports the gap. Optimised feeds discovery upstream into platform guardrails so finding classes are eliminated rather than remediated.
The artefact that distinguishes Level 3 from Level 4 on this dimension is a maintained security tool coverage overlap matrix: weakness class along the rows, tool category along the columns, primary or secondary or out-of-scope or silent gap per cell, built per asset type. Programmes at Level 2 have a tool list; programmes at Level 4 have the matrix and review it when the stack changes.
Dimension 2. Triage and severity
How findings are calibrated, deduplicated, and prioritised. Includes severity calibration policy, CVSS-plus-context decision rule, exploit signal (CISA KEV, FIRST EPSS, in-the-wild observation), and the deduplication mechanism across overlapping scanners. Reactive triage assigns severity ad-hoc; Optimised triage applies a policy that combines CVSS, KEV, EPSS, asset criticality, and exposure context.7,8,9,10
Level signals: Reactive uses scanner default severity. Repeatable applies CVSS consistently. Defined adds KEV and EPSS context plus a written calibration policy. Managed measures triage cycle time and noise rate. Optimised pushes calibration upstream into intake-time deduplication and suppression rules pegged to the live engagement record.
Dimension 3. Remediation governance
How findings move through ownership, SLA, retest, and closure. Includes the SLA per severity band, the ownership routing rule, the retest cycle time, and the closure verification rule. Reactive governance closes findings when somebody happens to fix the asset; Optimised governance reports SLA-bound closure rate per severity band against external references and reads the cycle-time stage breakdown so bottlenecks are visible.3,4,5,7
Level signals: Reactive has no SLA. Repeatable has a critical-only SLA. Defined has an SLA per severity band with a documented owner. Managed reads cycle-time stage breakdown reproducibly. Optimised closes the loop between detection and remediation upstream so the same class of finding does not recur.
Dimension 4. Exception and risk acceptance
How deferred risk is documented, reviewed, and aged. Includes the eight-field acceptance pattern (linked finding, severity, compensating controls, residual likelihood, residual impact, business rationale, expiry, review cadence), the review cadence, and the expiry handling rule. Reactive exceptions live in email; Optimised exceptions live on the same engagement record as the originating finding with a reproducible audit trail.
Level signals: Reactive has informal acceptances. Repeatable maintains a list. Defined has a policy and an eight-field register. Managed measures the residual-risk profile of the register and the expiry-renewal rate. Optimised treats expired exceptions as a programme metric rather than administrative overhead and routes them through the same governance as new findings.
Dimension 5. Leadership reporting
How the programme communicates posture to the audit committee, the CISO, and the engineering organisation. Includes the cadence, the breakdown by severity, the trend lines, and the four-axis view (open, remediated, exception-closed, expired-exception). Reactive reporting is annual and narrative; Optimised reporting carries the same data the operational team uses, with leadership reading the same record without translation.
Level signals: Reactive reports annually if at all. Repeatable reports quarterly. Defined reports monthly with severity breakdown. Managed reports against external SLA references with cycle-time stage breakdown. Optimised has unified leadership and operational reads on the same record.
The five-by-five grid
The grid below shows the operational signature of each level for each dimension. Programmes that score themselves honestly across the grid produce a heat map rather than a single rating; the heat map names the lowest-scoring dimension as the next investment target rather than asking the programme to invest in parallel across five dimensions at once.
| Level | Discovery | Triage | Remediation | Exception | Reporting |
|---|---|---|---|---|---|
| 1. Reactive | Audit-driven scans only | Scanner default severity | No SLA, opportunistic close | Email and shared drives | Annual narrative |
| 2. Repeatable | External cadence in place | CVSS used consistently | Critical-only SLA | List maintained | Quarterly count summary |
| 3. Defined | External plus auth plus code | CVSS plus KEV plus EPSS | SLA per severity band | Eight-field register | Monthly breakdown |
| 4. Managed | Coverage measured vs estate | Triage cycle time measured | Cycle-time stage breakdown | Residual-risk profile read | External SLA references |
| 5. Optimised | Upstream platform guardrails | Intake-time dedup and suppress | Detection-remediation loop closed | Expired-exception governance | Unified leadership and ops view |
The grid is a self-assessment tool, not an audit ledger. Programmes that fill the grid honestly tend to land on between two and four different levels across the five dimensions; uniform Level 3 across the row is rare and often reflects optimistic self-rating rather than uniform discipline. The lowest cell in the row is the next investment target, not the highest.
How the model maps to compliance frameworks
Each major framework reads vulnerability management through a different control lens. The level descriptions translate to framework-readable evidence at predictable points; the table below names the framework cell that each maturity level routinely satisfies.2,3,5,6,7,14
| Framework | Control reference | Routinely satisfied at |
|---|---|---|
| ISO 27001:2022 | Annex A 8.8 Management of Technical Vulnerabilities, plus 5.36 Compliance with policies | Level 3 (Defined). Cadence, severity policy, and exception register routinely meet surveillance audit reads at this level. |
| SOC 2 Type 2 | Trust Services Criterion CC7.1 Detection of Vulnerabilities, plus CC4.1 monitoring | Level 3 if cadence operates across the observation period. Level 4 if cycle-time evidence is reproducible from the live record. |
| PCI DSS v4.0 | Requirement 6.3 Identification and ranking, 6.3.3 patch SLA, 11.3 quarterly scans, 11.4 annual penetration testing | Level 3 satisfies the on-paper requirements. Level 4 satisfies them on the live operating record without an evidence-collection sprint. |
| NIST SP 800-53 | RA-5 Vulnerability Monitoring and Scanning, SI-2 Flaw Remediation, plus SP 800-40 patch management planning | Level 3 establishes the control. Level 4 produces the metrics SP 800-53 expects organisation-defined frequencies to operate against. |
| CISA BOD 22-01 | Federal civilian executive branch directive, 14-day window for known exploited vulnerabilities | Level 3 if KEV is part of severity calibration. Level 4 if the 14-day window is measured and reported against external SLA reference. |
| NIST CSF 2.0 | DE.CM (continuous monitoring), RS.MI (mitigation), GV.RM (risk management governance) | Level 3 covers DE.CM and RS.MI. Level 4 reads the GV.RM dimension reproducibly from the operational record. |
The shared pattern is that frameworks operate as readers of the maturity grid rather than as substitutes for it. A programme that scores Level 3 across the row routinely passes ISO 27001 and SOC 2; a programme that scores Level 4 routinely satisfies them on the live record without an audit-week sprint. The framework view of vulnerability management is a derived artefact from the maturity grid rather than the grid itself.
Six common failure patterns
Programmes that fail an honest maturity read tend to fail in recognisable patterns. The list below is the durable shape of the failure modes drawn from ISO 27001 surveillance audits, SOC 2 Type 2 examinations, PCI DSS QSA reviews, customer security questionnaire responses, and post-incident reviews.2,3,5,6
The tooling-on-discipline mismatch
The programme has bought a Level 4 platform but operates Level 2 discipline. The dashboard reports cycle-time stages and SLA-bound closure rates, but the underlying findings have inconsistent severity calibration, an informal exception register, and a closure rule that closes administratively rather than verifiably. The platform produces clean numbers on noisy data; the audit and the next incident read the discipline gap.
The discovery-without-remediation gap
Discovery scores Level 3 or 4 because scanners run on cadence across the in-scope estate. Remediation governance scores Level 1 or 2 because findings accumulate without an SLA, ownership rule, or verified-closure rule. The open queue grows quarter on quarter; the audit reads the open queue against ISO 27001 Annex A 8.8 and PCI DSS 6.3.3 as a remediation failure rather than as a scanning success. The fix is to invest in remediation governance before adding scanner coverage.
The exception-as-closure pattern
Findings are closed by being moved to the exception register rather than by remediation. The closure rate looks healthy on the headline metric; the residual-risk profile of the exception register grows. SOC 2 and ISO 27001 both read this pattern through the four-axis view (open, remediated, exception-closed, expired-exception). Programmes that report closure as a single number rather than as a four-axis breakdown carry hidden risk debt.
The audit-week sprint
Evidence is assembled in a sprint immediately before audit. Cadence operated at Level 1 or 2 across the observation period; Level 3 evidence is produced retroactively. SOC 2 Type 2 reads this pattern as a control deficiency because the criteria expect ongoing operation. The programme passes the audit with qualifications, then operates Level 1 or 2 again until the next sprint.
The dashboard-divergence pattern
Operational and leadership reports describe the same programme through different numbers. The operational team reads scanner output; the leadership team reads a slide deck assembled monthly from a separate spreadsheet. The two reads diverge over time as the spreadsheet stops tracking the live queue. Programmes at Level 3 and below routinely operate this way; Level 4 unifies the two reads on the same record.
The platform-purchase plateau
The programme buys a vulnerability management platform expecting it to raise maturity by two levels. Six months later the platform is configured and the maturity grid has not moved because discipline investment (severity policy, ownership rule, exception process, leadership cadence) was not paired with the tooling investment. Tooling is a necessary but not sufficient condition; the discipline investment is what moves the grid.
Sequencing investment from the lowest cell
Programmes that read the grid honestly typically sequence investment from the lowest-scoring dimension rather than spreading capital across all five in parallel. The audit, the regulator, the customer, and the next incident each read whichever cell the programme scored lowest; raising the floor matters more than raising the ceiling on dimensions that are already mature.
Lowest cell is discovery
Investment target: scan coverage measured against the asset register. Add authenticated coverage of applications behind login, code coverage across the repository inventory, and external attack-surface coverage that includes subdomains and exposed services. The investment moves discovery from Level 1 or 2 toward Level 3 or 4 over six to twelve months.
Lowest cell is triage and severity
Investment target: a written severity calibration policy that combines CVSS, KEV, EPSS, and asset criticality. Add intake-time deduplication so overlapping scanner findings collapse to one record rather than landing as three. Move from scanner-default severity toward a documented decision rule that the audit can read.
Lowest cell is remediation governance
Investment target: an SLA per severity band with a documented owner, a verified-closure rule, and a retest cycle time. Anchor the SLA to external references (CISA BOD 22-01 14-day window, PCI DSS 6.3.3 30-day window) so the audit committee reads the same window the framework reads. Move governance from Level 1 or 2 toward Level 3 in six months.
Lowest cell is exception and risk acceptance
Investment target: the eight-field acceptance pattern (linked finding, severity, compensating controls, residual likelihood, residual impact, business rationale, expiry, review cadence) and a review cadence that catches expired exceptions. Move the register off shared drives onto the same engagement record the originating finding lives on so the audit chain reproduces from the live record.
Lowest cell is leadership reporting
Investment target: a monthly report with severity breakdown, SLA-bound closure rate, exception count, expired-exception count, and trend lines. Move from annual narrative toward monthly cadence that uses the same data the operational team uses, so the leadership read carries the same currency as the operational read.
How the engagement record carries maturity evidence
Maturity gets cleaner when the audit trail lives on the same engagement record the operational work lives on, rather than on a separate scorecard that diverges from operational reality after assessment. The platform does not score the maturity grid for the programme, but it makes the five-dimension read reproducible at any moment between assessments.
SecPortal pairs every finding to a versioned engagement record through findings management. CVSS 3.1 vector, severity, owner, evidence, and remediation status are captured on the finding, so the discovery and triage dimensions of the grid read directly from the live record rather than from a separate spreadsheet.17 The engagement management layer holds the policy, scope, and stakeholder record per assessment so the maturity grid is scored against the same source of truth the audit reads.20
The compliance tracking feature maps findings and controls to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST frameworks, with CSV export for auditors. The framework view of the grid (which level routinely satisfies which framework cell) is derived from the same record rather than reconstructed.18 The continuous monitoring feature schedules cover daily, weekly, biweekly, and monthly cadence so the discovery dimension is observable rather than asserted.21
The activity log captures every state change with timestamp and named user, so the cycle-time stages (triage, ownership, investigation, remediation, verification, closure) that distinguish Level 4 from Level 3 are observable without separate instrumentation.19 The AI report generation workflow produces leadership summaries from the same engagement data, so the leadership reporting dimension carries the same currency as the operational record.22
The companion artefact to this research is the vulnerability management program scorecard: a structured self-assessment that turns the five-by-five grid into a fillable scorecard with a named owner, a current level, a target level, and a sequenced investment list per dimension.23
For internal security and vulnerability management teams
Internal security teams and vulnerability management owners carry the maturity question between assessments. The pattern that survives assessment cycle after assessment cycle is to score the grid honestly, sequence investment from the lowest cell, and treat the discipline investment as load-bearing rather than ancillary to the tooling investment.
- Score the grid annually against named, observable artefacts rather than against a self-rating questionnaire.
- Sequence investment from the lowest-scoring cell because that is the cell each external read samples first.
- Pair tooling investment with discipline investment; tooling alone moves the grid by less than half the levels the marketing material suggests.
- Track exception-to-remediation ratio alongside SLA-bound closure rate so the four-axis view shows whether the programme is closing risk or moving it.
- Surface the same data on the leadership report that the operational team uses so the two reads do not diverge.
For internal security teams, vulnerability management teams, GRC and compliance teams, AppSec teams, product security teams, security engineering teams, and cloud security teams, the operating commitment is to keep the maturity question reproducible at any moment between assessments rather than only at audit week. The vulnerability remediation throughput research covers the closure-side measurement discipline that distinguishes Level 4 from Level 3 on the remediation governance dimension.25 The vulnerability reopen rate research covers the durability axis that distinguishes verified closure from administrative closure.26 The audit evidence half-life research covers the evidence-currency discipline that turns Level 3 from on-paper compliance into on-record compliance. The security control drift research covers the upstream side: how controls erode between audits along the asset, scope, ownership, and configuration axes that quietly drag a Level 3 programme back toward Level 2. The MTTD vs MTTR research covers the time-axis pairing that the leadership reporting dimension actually has to deliver: per-channel detection latency against scan cadence and intelligence-ingestion clocks paired with per-severity remediation latency against the framework anchors. Reporting one without the other is the load-bearing failure mode that distinguishes Level 3 reporting from Level 4 reporting.
The operational workflows that operationalise each maturity dimension live in the use-case library: remediation tracking, vulnerability SLA management, vulnerability acceptance and exception management, vulnerability prioritisation, vulnerability backlog management, scanner result triage, scanner-to-ticket handoff governance, security leadership reporting, and control gap remediation workflow.
The educational primers that set the vocabulary the maturity grid scores against live in the blog: vulnerability management programme guide, risk-based vulnerability management buyer guide, vulnerability prioritisation framework, and the CISA KEV catalog vulnerability management guide. The programme-level operating model that wraps these workflows on a continuous cadence is the Continuous Threat Exposure Management (CTEM) framework, which sequences scope, discovery, prioritisation, validation, and mobilisation as a cycle rather than as overlapping disciplines.
For security leadership and audit committees
Security leaders and audit committees read maturity through a different lens than operational teams. The leadership read is whether the programme is durably mature between assessments, not just rated mature on a self-assessment. A programme that scores Level 3 across the row at audit week and operates Level 1 or 2 between audits carries higher residual risk than the maturity rating suggests.
- Read the maturity grid as a heat map rather than a single rating; uniform Level 3 across the row is rare and often reflects optimistic self-rating rather than uniform discipline.
- Ask the operational team for the lowest-scoring cell first because that is the cell external readers sample first.
- Sequence budget allocation against the heat map rather than spreading capital across every dimension in parallel.
- Track the discipline investment alongside the tooling investment because tooling moves the grid by less than the vendor pitch suggests.
- Read SLA-bound closure rate per severity band and exception-to-remediation ratio together because closure rate alone hides risk movement into the exception register.
The leadership question that drives this discipline is straightforward: if a regulator, customer, or auditor asked for current vulnerability management evidence today, would the answer come from one query against the live record, or from a multi-team evidence-collection sprint. Programmes whose answer is the live record operate at Level 4 or 5. Programmes whose answer is the sprint operate at Level 2 or 3 regardless of how the maturity self-assessment scores.
The leadership-side platform discipline that supports this is covered on SecPortal for CISOs and security leaders, SecPortal for security operations leaders, and the broader security testing programme management workflow.
Conclusion
Vulnerability management maturity is a five-by-five grid, not a single rating. The level scaffolding (Reactive, Repeatable, Defined, Managed, Optimised) and the dimension scaffolding (discovery, triage, remediation, exception, reporting) interact rather than operate independently. A programme is mature when each dimension scores similar levels and the audit, regulator, customer, and incident reads each land on the same picture as the self-assessment.1,2,3,11,12
Treating maturity as a property of the live engagement record rather than as a static scorecard is the highest-leverage discipline in vulnerability management between assessments. It surfaces uneven capability that single-axis metrics hide, sequences investment toward the lowest-scoring cell, and produces evidence that survives the second and third audit cycle rather than passing one assessment and rebuilding from scratch for the next. The platform you use does not have to score the maturity grid for you. It does have to make the five-dimension read available as a query against the live record, which is the structural prerequisite for moving from Repeatable toward Defined and beyond.
Frequently Asked Questions
Sources
- CMMI Institute, Capability Maturity Model Integration
- ISO/IEC 27001:2022 Annex A 8.8 Management of Technical Vulnerabilities
- NIST SP 800-53 Revision 5: RA-5 Vulnerability Monitoring and Scanning, SI-2 Flaw Remediation
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- PCI Security Standards Council, PCI DSS v4.0 Requirement 6.3 and 11.3
- AICPA, SOC 2 Trust Services Criteria CC7.1 Detection of Vulnerabilities
- CISA, Binding Operational Directive 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
- CISA, Stakeholder-Specific Vulnerability Categorization (SSVC)
- FIRST, Common Vulnerability Scoring System (CVSS) v3.1 Specification
- FIRST, Exploit Prediction Scoring System (EPSS)
- OWASP, Software Assurance Maturity Model (SAMM)
- BSIMM, Building Security In Maturity Model
- CIS, Critical Security Controls Implementation Groups
- NIST, Cybersecurity Framework (CSF) 2.0
- NCSC, Vulnerability Management Guidance
- ENISA, Good Practices on Vulnerability Disclosure
- SecPortal, Findings & Vulnerability Management
- SecPortal, Compliance Tracking
- SecPortal, Activity Log & Workspace Audit Trail
- SecPortal, Engagement Management
- SecPortal, Continuous Monitoring
- SecPortal, AI-Powered Security Reports
- SecPortal, Vulnerability Management Program Scorecard
- SecPortal, Remediation Tracking Use Case
- SecPortal Research, Vulnerability Remediation Throughput
- SecPortal Research, Vulnerability Reopen Rate
Score the maturity grid on the live engagement record
SecPortal keeps findings, remediation actions, retests, exceptions, and compliance mappings paired to one versioned engagement record so the five-dimension maturity read is reproducible at any moment between assessments rather than reconstructed from a self-rating questionnaire at audit week.