Vulnerability Management Program Guide: Lifecycle, Framework & Best Practices

You run a vulnerability scan. It returns 4,200 findings. Your team triages the critical ones, patches what they can, creates tickets for the rest, and moves on. Next quarter, the scan returns 4,800 findings. Some are the same ones from last quarter. Some are new. Some of last quarter's findings were "fixed" but reappeared. The backlog grows. The team burns out. Nobody knows whether the organisation is actually more secure than it was a year ago.

This is what vulnerability management looks like without a programme. It's reactive, exhausting, and produces motion without measurable progress. Scans run, tickets get created, patches get applied, and the vulnerability count never meaningfully decreases because nobody is addressing why vulnerabilities keep appearing in the first place.

A vulnerability management programme transforms this reactive cycle into a structured, measurable process where vulnerabilities are continuously identified, prioritised based on actual risk, remediated within defined timelines, verified as resolved, and the root causes are addressed so they stop recurring.

The difference between vulnerability scanning and vulnerability management is the difference between a fire alarm and a fire prevention programme. One tells you there's a problem. The other systematically reduces the likelihood of problems occurring and ensures effective response when they do.

This guide covers how to build a vulnerability management programme from the ground up: what vulnerability management actually is, the vulnerability management lifecycle, framework design, policy creation, tool selection, the remediation process, metrics that demonstrate programme value, and how to mature your programme from basic scanning to proactive security that measurably reduces organisational risk.

What Is Vulnerability Management?

Vulnerability management is the continuous, systematic process of identifying, evaluating, prioritising, remediating, and verifying security vulnerabilities across an organisation's technology environment. It's not a tool or a scan. It's an ongoing programme that organises how your organisation finds weaknesses and eliminates them.

Vulnerability Management vs Vulnerability Scanning

Vulnerability scanning is one activity within vulnerability management. Scanning identifies potential vulnerabilities through automated tools. Vulnerability management encompasses everything around scanning: governance defining programme scope and ownership, policy establishing remediation timelines and accountability, prioritisation determining which vulnerabilities matter most based on business context, remediation tracking ensuring fixes are implemented, verification confirming fixes actually work, and measurement demonstrating whether the programme reduces organisational risk over time.

Organisations that run scans without a management programme generate findings without resolution. The programme is what converts scan output into security improvement.

Vulnerability Management vs Vulnerability Assessment vs Penetration Testing

Understanding how these related concepts fit together prevents confusion and gap creation.

Vulnerability scanning identifies potential weaknesses through automated tools. Fast, broad, produces unvalidated findings.

Vulnerability assessment combines scanning with manual review to validate findings and eliminate false positives. More accurate than scanning alone.

Penetration testing actively exploits validated vulnerabilities proving real-world risk. Deepest validation but point-in-time.

Vulnerability management is the ongoing programme that orchestrates all three: continuous scanning for detection, periodic assessment for validation, regular penetration testing for exploitation proof, and systematic remediation connecting findings to fixes.

For the complete testing methodology, see our VAPT process guide.

The Vulnerability Management Lifecycle

The vulnerability management lifecycle is the repeating process through which your programme identifies and eliminates vulnerabilities. Each cycle improves organisational security posture incrementally.

Phase 1: Asset Discovery and Inventory

You cannot protect what you don't know exists. Asset discovery is the foundation.

What to inventory: Every system, application, service, and device across your environment. This includes servers (physical and virtual), cloud instances, containers, serverless functions, workstations, network devices, web applications, APIs, mobile applications, cloud infrastructure, IoT devices, and third-party services.

Asset classification: Each asset needs a criticality rating based on data sensitivity (what data does it process?), business function (what happens if it's unavailable?), exposure level (internet-facing vs internal), and regulatory scope (PCI DSS, HIPAA, SOC 2, ISO 27001).

Asset criticality directly determines vulnerability prioritisation. A medium-severity vulnerability on a payment processing server is higher priority than a high-severity vulnerability on a test system.

Attack surface management helps organisations maintain continuous asset visibility, discovering unknown assets that traditional inventories miss.

Phase 2: Vulnerability Identification

Systematically discover vulnerabilities across inventoried assets.

Automated vulnerability scanning runs regularly across all assets. Infrastructure scanners (Nessus, Qualys, Rapid7) check servers, network devices, and endpoints. Web application scanners (Burp Suite, OWASP ZAP) check application-layer vulnerabilities. Cloud security tools (ScoutSuite, Prowler) check cloud configurations. Software composition analysis (SCA) tools check third-party libraries. Container scanning tools check container images.

Credentialed scanning provides deeper assessment than external-only scanning. Authenticated scans access operating system details, installed software versions, and configuration settings that unauthenticated scanning misses. Credentialed scanning typically identifies 40 to 60 percent more vulnerabilities than unauthenticated scanning on the same systems.

Manual penetration testing identifies vulnerabilities automated scanning misses: business logic flaws, complex authorisation failures, chained attack paths, and application-specific weaknesses. Penetration testing validates which vulnerabilities are genuinely exploitable.

Scanning frequency:

Phase 3: Vulnerability Evaluation and Prioritisation

Not all vulnerabilities are equal. Prioritisation determines which vulnerabilities get fixed first.

CVSS severity alone is insufficient. A CVSS 9.8 vulnerability on an isolated test system with no data is lower priority than a CVSS 6.5 vulnerability on an internet-facing payment server. Business context must inform prioritisation.

Risk-based prioritisation framework:

Exploitability. Is the vulnerability being actively exploited in the wild? CISA's Known Exploited Vulnerabilities (KEV) catalogue identifies vulnerabilities with confirmed active exploitation. KEV-listed vulnerabilities warrant immediate remediation regardless of CVSS score.

Asset criticality. What is the business impact if this asset is compromised? Critical assets (payment processing, customer databases, domain controllers) warrant faster remediation than low-criticality systems.

Exposure. Is the vulnerable system internet-facing, internal-only, or isolated? Internet-facing systems face exponentially more attack attempts.

Data sensitivity. Does the system process PCI data, PHI, PII, intellectual property, or other regulated/sensitive information?

Compensating controls. Do existing security controls (WAF, IPS, segmentation) reduce the exploitability of the vulnerability?

Remediation complexity. What effort is required to fix? Quick wins (configuration changes) should be prioritised alongside high-severity items that require longer remediation windows.

Prioritisation matrix:

Phase 4: Remediation

Convert prioritised vulnerabilities into resolved security improvements.

Remediation approaches:

Patching. Applying vendor-provided security patches. The most common remediation for infrastructure vulnerabilities. Patching requires testing in staging environments before production deployment to prevent operational disruption.

Configuration changes. Modifying system, application, or network configuration to eliminate the vulnerability. Disabling unnecessary services, strengthening authentication settings, restricting access permissions.

Code fixes. Modifying application code to address vulnerability root causes. Required for application-layer vulnerabilities (injection, XSS, authentication flaws). Development teams implement fixes within sprint cycles.

Architecture changes. Modifying system architecture to eliminate vulnerability classes. Network segmentation, zero trust implementation, service isolation. Longer-term but addresses root causes rather than individual symptoms.

Compensating controls. Implementing mitigating controls when immediate remediation isn't possible. WAF rules, IPS signatures, access restrictions, or monitoring provide risk reduction while permanent fixes are developed.

Risk acceptance. Formally documenting and accepting the risk of a vulnerability that the organisation chooses not to remediate. Risk acceptance requires management sign-off, documented justification, and periodic review.

Remediation workflow:

1. Vulnerability assigned to responsible team/individual
2. Remediation approach determined (patch, config, code, architecture)
3. Fix developed and tested in non-production environment
4. Change management approval obtained
5. Fix deployed to production
6. Verification scan confirms vulnerability resolved
7. Ticket closed with remediation evidence

Phase 5: Verification

Confirm that remediation actually resolved the vulnerability.

Verification scanning. Re-scan remediated systems confirming the vulnerability no longer appears. Verification should use the same scanning methodology that detected the original vulnerability.

Regression testing. Verify that remediation didn't introduce new vulnerabilities or break existing functionality.

Penetration testing retesting. For vulnerabilities originally discovered through penetration testing, retesting by the testing provider confirms exploitation is no longer possible.

Verification closes the loop. Without it, the programme assumes remediation works without evidence.

Phase 6: Reporting and Improvement

Measure programme effectiveness and drive continuous improvement.

Operational reporting tracks vulnerability counts by severity, remediation SLA compliance, mean time to remediate (MTTR), vulnerability age distribution, and open vs closed finding trends.

Strategic reporting communicates programme value to leadership through risk reduction metrics, year-over-year posture improvement, compliance status, and programme maturity indicators.

Continuous improvement uses programme data to address root causes. If SQL injection appears repeatedly, developer training and secure coding standards need improvement. If unpatched systems are the primary finding, patch management processes need strengthening. If cloud misconfigurations recur, infrastructure-as-code templates need security baselines.

Vulnerability Management Framework

Framework Components

A vulnerability management framework defines how the programme operates.

Governance: Who owns the programme? Who has authority over remediation priorities? How are disputes resolved? Typically, the CISO or security director owns the programme. A vulnerability management committee (security, IT, development, operations) resolves prioritisation conflicts.

Scope: What assets and vulnerability types does the programme cover? Start with the highest-risk assets and expand. Most mature programmes eventually cover all organisational technology assets.

Roles and responsibilities: Asset owners are responsible for remediation on their systems. The security team manages scanning, prioritisation, and programme governance. Development teams remediate application-level vulnerabilities. IT operations remediate infrastructure vulnerabilities. Management approves risk acceptance decisions.

Integration: How does vulnerability management connect with other security processes? Incident response (vulnerabilities exploited in incidents get emergency priority). Change management (changes trigger verification scanning). Risk management (vulnerability data feeds organisational risk assessment). Compliance (programme data supports audit evidence).

Aligning with Industry Frameworks

NIST Cybersecurity Framework. Vulnerability management directly supports Identify (ID.RA: Risk Assessment), Protect (PR.IP: Information Protection), and Detect (DE.CM: Continuous Monitoring) functions.

ISO 27001. Annex A controls A.8.8 (Management of Technical Vulnerabilities) and A.8.9 (Configuration Management) directly mandate vulnerability management activities. See our ISO 27001 penetration testing guide.

PCI DSS. Requirements 5 (Malware), 6 (Secure Systems), and 11 (Testing) mandate specific vulnerability management activities including quarterly scanning, annual penetration testing, and vulnerability remediation processes. See our PCI DSS penetration testing guide.

CIS Controls. CIS Control 7 (Continuous Vulnerability Management) provides specific implementation guidance for VM programmes.

For comprehensive compliance alignment, see our penetration testing compliance guide.

Vulnerability Management Policy

A vulnerability management policy formalises programme requirements into organisational policy. Policy documentation supports compliance evidence and establishes accountability.

Essential Policy Elements

Scope statement. Which assets, environments, and vulnerability types the policy covers.

Roles and responsibilities. Programme owner, asset owners, remediation teams, risk acceptance authority.

Scanning requirements. Minimum scanning frequency by asset type, credentialed vs unauthenticated requirements, tool standards.

Remediation SLAs. Maximum remediation timelines by priority level:

Exception and risk acceptance process. How to request remediation timeline extensions. Required justification. Approval authority (typically CISO or VP Engineering for critical/high). Periodic review requirements for accepted risks.

Reporting requirements. What metrics are reported, to whom, at what frequency. Monthly operational reports. Quarterly executive reports. Annual programme review.

Compliance mapping. How the policy satisfies specific compliance requirements (PCI DSS Requirement 11, SOC 2 Trust Services Criteria, ISO 27001 A.8.8).

Vulnerability Management Tools

Infrastructure Scanning

Nessus Professional. Industry-standard vulnerability scanner. Extensive plugin library covering 70,000+ checks. Credentialed and unauthenticated scanning. Strong compliance auditing templates.

Qualys VMDR. Cloud-based vulnerability management platform with continuous monitoring. Asset discovery, vulnerability scanning, and prioritisation in a unified platform. Strong enterprise deployment.

Rapid7 InsightVM. Vulnerability management with live dashboards, risk scoring, and remediation workflow integration. Agent-based and agentless scanning.

Microsoft Defender Vulnerability Management. Integrated with Microsoft security ecosystem. Endpoint vulnerability assessment for Windows environments.

Web Application Scanning

Burp Suite Professional. Web application security testing combining automated scanning with manual testing capabilities.

OWASP ZAP. Open-source web application scanner providing automated vulnerability detection.

Cloud Security

AWS Inspector. Native AWS vulnerability assessment for EC2, Lambda, and ECR.

Azure Defender. Integrated vulnerability assessment for Azure workloads.

GCP Security Command Center. Google Cloud native security and risk assessment.

ScoutSuite. Multi-cloud security auditing across AWS, Azure, and GCP.

Software Composition Analysis

Snyk. Developer-focused SCA identifying vulnerabilities in open-source dependencies with remediation guidance.

Dependabot. GitHub-native automated dependency update and vulnerability alerting.

Mend (WhiteSource). Enterprise SCA with policy management and automated fix recommendations.

Vulnerability Management Platforms

ServiceNow Vulnerability Response. Integrates vulnerability data with IT service management workflows for enterprise remediation tracking.

Kenna (Cisco) Security. Risk-based vulnerability prioritisation using threat intelligence and asset context.

Nucleus Security. Vulnerability aggregation and management platform consolidating findings from multiple scanners.

Tool Selection Considerations

Choose tools based on environment coverage (cloud, on-premises, containers, applications), integration with existing security and IT tools (SIEM, ticketing, CMDB), scanning depth (credentialed support, compliance checks), scalability to your asset count, and reporting and dashboard capability.

Tools provide the detection layer. The vulnerability management programme provides everything else: governance, prioritisation, remediation tracking, verification, and measurement.

Vulnerability Management Best Practices

1. Start with Asset Visibility

You cannot manage vulnerabilities in assets you don't know exist. Invest in asset discovery and inventory before expanding scanning coverage. Shadow IT, cloud sprawl, and unmanaged devices represent the highest risk because they receive no security attention.

2. Prioritise by Business Risk, Not Just CVSS

CVSS scores measure technical severity. Business risk considers asset criticality, data sensitivity, exposure, and exploitability. A programme prioritising purely by CVSS wastes remediation resources on high-CVSS vulnerabilities on low-value systems while medium-CVSS vulnerabilities on critical systems wait.

3. Automate Where Possible, Govern Everywhere

Automate scanning schedules, ticket creation, and notification. But govern prioritisation decisions, risk acceptance, and programme strategy through human judgment and committee oversight. Fully automated programmes generate noise. Fully manual programmes don't scale.

4. Track Mean Time to Remediate (MTTR)

MTTR is the single most important vulnerability management metric. It measures how long vulnerabilities exist between detection and verified remediation. Reducing MTTR reduces the window attackers have to exploit known weaknesses. Track MTTR by severity level and asset type.

5. Measure Vulnerability Age Distribution

The age distribution of open vulnerabilities reveals programme health more accurately than total count. A programme with 500 open vulnerabilities all under 30 days old is healthier than a programme with 200 open vulnerabilities where 80 are over 90 days old. Age distribution exposes remediation bottlenecks.

6. Integrate Penetration Testing into the Programme

Vulnerability scanning identifies known vulnerability patterns. Penetration testing discovers what scanning misses and validates whether identified vulnerabilities are genuinely exploitable. Annual penetration testing should be a scheduled programme activity, not a separate initiative. Pentest findings should enter the same remediation workflow as scan findings.

Continuous penetration testing maintains ongoing expert validation between scanning cycles.

7. Address Root Causes, Not Just Symptoms

If the same vulnerability category (SQL injection, missing patches, weak configurations) recurs across multiple scan cycles, the remediation process is treating symptoms while the root cause persists. Root cause analysis should trigger process improvements: developer training for code-level patterns, patch management automation for infrastructure patterns, and configuration baselines for hardening patterns.

8. Establish Clear Ownership

Every vulnerability needs a responsible owner. Unowned vulnerabilities don't get fixed. Asset ownership should be documented in the CMDB and mapped to vulnerability management so that scan findings automatically route to the team responsible for the affected system.

Vulnerability Management Metrics

Operational Metrics

Total vulnerabilities by severity. Current count of open vulnerabilities segmented by critical, high, medium, and low. Track trend over time.

Mean time to remediate (MTTR). Average time from detection to verified remediation. Track by severity. Target MTTR should align with policy SLAs.

SLA compliance rate. Percentage of vulnerabilities remediated within policy-defined timelines. 90%+ compliance indicates a functioning programme.

Vulnerability age distribution. Percentage of open vulnerabilities by age bracket (0-30 days, 31-60, 61-90, 90+). Aging vulnerabilities indicate remediation bottlenecks.

Scan coverage. Percentage of inventoried assets receiving regular vulnerability scanning. Target: 100% of in-scope assets.

Reintroduction rate. Percentage of previously remediated vulnerabilities that reappear. High reintroduction indicates ineffective fixes or root cause persistence.

Strategic Metrics

Risk reduction trend. Aggregate risk score trending downward over quarters and years. Demonstrates programme value to leadership.

Year-over-year posture comparison. Comparing vulnerability counts, severity distribution, and MTTR across annual periods. Positive trends justify continued programme investment.

Penetration test finding trend. Year-over-year comparison of penetration test results. Decreasing findings and severity indicates the vulnerability management programme is preventing vulnerabilities from reaching production.

Compliance evidence readiness. Ability to produce vulnerability management evidence for auditors within hours, not days. Indicates programme maturity and operational efficiency.

Vulnerability Management Programme Maturity

Level 1: Reactive (Ad Hoc Scanning)

Vulnerability scans run occasionally, typically driven by audit requirements or incidents. No formal programme, policy, or remediation tracking. Findings pile up without systematic remediation. Most organisations start here.

Level 2: Managed (Regular Scanning with Tracking)

Regular scanning schedule established. Remediation tracked through ticketing system. Policy defines SLAs. Basic metrics reported. Findings get assigned but remediation sometimes stalls. This level satisfies basic compliance requirements.

Level 3: Defined (Risk-Based Prioritisation)

Asset criticality drives prioritisation. Business context informs remediation urgency. Credentialed scanning deployed. Penetration testing integrated into programme. Root cause analysis conducted for recurring patterns. Metrics demonstrate programme effectiveness.

Level 4: Quantitative (Measured and Optimised)

Programme effectiveness measured through comprehensive metrics. MTTR targets defined and tracked. SLA compliance monitored. Year-over-year improvement demonstrated. Automation reduces manual effort. Security champions extend programme reach into development teams.

Level 5: Optimising (Continuous Improvement)

Vulnerability management fully integrated with development lifecycle (secure SDLC). Pre-deployment scanning prevents vulnerable code from reaching production. Continuous scanning and continuous penetration testing maintain real-time posture awareness. Programme drives organisational security strategy. Vulnerability data informs technology decisions.

How Penetration Testing Strengthens Vulnerability Management

Vulnerability management programmes that rely solely on automated scanning have a blind spot: they find known vulnerability patterns but miss what scanners can't detect.

What Scanning Misses

Business logic flaws in applications. Complex authorisation failures (IDOR, privilege escalation). Chained vulnerabilities where individually minor findings combine into critical attack paths. Authentication bypass through implementation weaknesses. Configuration issues specific to your application architecture.

How Penetration Testing Fills the Gap

Annual penetration testing discovers the vulnerabilities scanning misses. Pentest findings enter the vulnerability management remediation workflow alongside scan findings. Retesting validates that remediation resolved exploitable weaknesses.

Web application testing, API testing, cloud testing, network testing, and internal testing each address vulnerability categories that automated tools miss within their respective domains.

The Integrated Model

1. Continuous automated scanning detects known vulnerability patterns
2. Annual penetration testing discovers what scanning misses
3. Both feed into the same prioritisation and remediation workflow
4. Remediation is tracked through policy-defined SLAs
5. Verification scanning and pentest retesting confirm resolution
6. Root cause analysis drives programme improvement
7. Metrics demonstrate combined programme effectiveness

How AppSecure Supports Vulnerability Management Programmes

AppSecure provides the penetration testing component that vulnerability management programmes need to identify what scanning alone misses.

Expert Validation Layer

AppSecure's manual penetration testing discovers vulnerabilities automated scanners cannot detect. Business logic, authorisation failures, chained attack paths, and application-specific weaknesses are identified through expert exploitation. Zero false positives ensure every finding entering your remediation workflow is genuine.

Comprehensive Coverage

Testing spans web applications, APIs, mobile, cloud, and networks. Application security assessment and offensive security testing provide end-to-end validation.

Compliance Evidence

Reports map to PCI DSS, SOC 2, ISO 27001, HIPAA, and NIST CSF.

90-Day Remediation Support

Post-delivery support helps your team remediate findings within VM programme SLAs. Complimentary retesting validates remediation.

Ongoing Testing

Continuous penetration testing and pentesting as a service provide the ongoing expert validation mature VM programmes need beyond annual assessment.

Ready to strengthen your vulnerability management programme with expert penetration testing?

Contact AppSecure:

• Schedule Penetration Testing
• Application Security Assessment
• VAPT Testing Services

Frequently Asked Questions

1. What is vulnerability management?

Vulnerability management is the continuous, systematic process of identifying, evaluating, prioritising, remediating, and verifying security vulnerabilities across an organisation's technology environment. It's an ongoing programme encompassing governance, policy, scanning, prioritisation based on business risk, tracked remediation with defined SLAs, verification that fixes work, and metrics demonstrating programme effectiveness. Vulnerability management transforms reactive scanning into structured security improvement that measurably reduces organisational risk over time.

2. What is the vulnerability management lifecycle?

The vulnerability management lifecycle consists of six phases that repeat continuously: asset discovery and inventory (know what you have), vulnerability identification through scanning and testing (find what's wrong), evaluation and prioritisation based on business risk (determine what matters most), remediation through patching, code fixes, or configuration changes (fix it), verification confirming remediation worked (prove it's fixed), and reporting with continuous improvement (measure and improve). Each cycle reduces risk incrementally.

3. What should a vulnerability management policy include?

A vulnerability management policy should include programme scope (which assets and vulnerability types), roles and responsibilities (programme owner, asset owners, remediation teams), scanning requirements (frequency by asset type, credentialed scanning), remediation SLAs by priority level (critical: 48-72 hours, high: 14 days, medium: 30 days, low: 90 days), risk acceptance and exception process with approval authority, reporting requirements and frequency, escalation procedures when SLAs are missed, and compliance framework mapping.

4. What is the vulnerability management framework?

A vulnerability management framework defines how the programme operates: governance structure (ownership, authority, committee), scope and coverage, roles and responsibilities, integration with other security processes (incident response, change management, risk management, compliance), industry framework alignment (NIST CSF, CIS Controls, ISO 27001), tool architecture, prioritisation methodology, and maturity model for programme improvement. The framework is the blueprint. The policy is the formalised rules. The lifecycle is the operational process.

5. How does vulnerability management differ from penetration testing?

Vulnerability management is the ongoing programme continuously identifying and remediating vulnerabilities across all organisational assets. Penetration testing is a periodic assessment where expert testers actively exploit vulnerabilities proving real-world risk. Vulnerability management uses automated scanning for breadth and continuous coverage. Penetration testing uses manual expertise for depth and exploitation validation. Mature programmes integrate both: continuous scanning for known patterns plus periodic penetration testing discovering what scanning misses.

6. What are the most important vulnerability management metrics?

The most important operational metrics are mean time to remediate (MTTR) by severity, SLA compliance rate, vulnerability age distribution, scan coverage percentage, and reintroduction rate. The most important strategic metrics are risk reduction trend, year-over-year posture comparison, penetration test finding trends, and compliance evidence readiness. MTTR is the single most valuable metric because it directly measures how quickly the organisation eliminates known risk.

7. What tools are needed for vulnerability management?

A complete vulnerability management tool stack includes infrastructure scanners (Nessus, Qualys, Rapid7), web application scanners (Burp Suite, OWASP ZAP), cloud security tools (AWS Inspector, ScoutSuite), software composition analysis (Snyk, Dependabot), and a management platform for aggregation and workflow (ServiceNow, Nucleus Security). Additionally, periodic penetration testing by qualified providers discovers vulnerabilities automated tools miss. Tool selection should consider environment coverage, integration capability, and scalability.

8. How often should vulnerability scanning occur?

Scanning frequency should match asset risk and exposure. Internet-facing systems warrant weekly scanning. Internal servers and endpoints warrant monthly scanning. Cloud infrastructure warrants weekly or continuous scanning. Web applications warrant monthly automated scanning plus annual manual penetration testing. PCI DSS mandates quarterly external vulnerability scanning. Higher-risk environments and regulatory requirements may demand more frequent scanning.

9. What is risk-based vulnerability prioritisation?

Risk-based prioritisation uses business context to determine remediation urgency rather than relying solely on CVSS scores. Factors include active exploitation status (CISA KEV listing), asset criticality and business function, data sensitivity, internet exposure, compensating controls, and remediation complexity. A CVSS 7.0 vulnerability on an internet-facing payment server may warrant higher priority than a CVSS 9.0 vulnerability on an isolated test system because business risk considers context that CVSS alone does not.

10. How do I measure vulnerability management programme maturity?

Programme maturity progresses through five levels: Level 1 (Reactive) with ad hoc scanning and no formal programme; Level 2 (Managed) with regular scanning and tracked remediation; Level 3 (Defined) with risk-based prioritisation and penetration testing integration; Level 4 (Quantitative) with comprehensive metrics and demonstrated improvement; Level 5 (Optimising) with full SDLC integration, continuous testing, and programme driving security strategy. Most organisations should target Level 3 as a practical maturity goal.