Building a Vulnerability Management Program: From Ad-Hoc Scanning to Mature Operations

Most companies have vulnerability scanning. Few have vulnerability management. The difference is the gap between running a tool that produces a list of findings and operating a program that systematically reduces your organization's risk exposure over time. Scanning tells you what is wrong. A vulnerability management program ensures something actually gets done about it.

This guide covers how to build a vulnerability management program that moves beyond scan-and-forget, with practical frameworks for prioritization, remediation SLAs, metrics that demonstrate progress, and compliance mapping for organizations subject to SOC 2, PCI DSS, or ISO 27001.

The Vulnerability Management Lifecycle

An effective vulnerability management program operates as a continuous cycle with four phases. Skipping any phase means the program is not actually managing vulnerabilities -- it is just generating reports.

Phase 1: Discover

Discovery is about finding vulnerabilities across your entire environment. This requires a combination of automated scanning, manual testing, and continuous monitoring.

• Automated vulnerability scanning. Regular scans of infrastructure, applications, and cloud environments using tools like Nessus, Qualys, or Rapid7. Scanning should run at least quarterly, with weekly or continuous scanning for internet-facing assets
• Penetration testing. Annual or semi-annual expert-driven testing that identifies vulnerabilities automated scanners miss, including business logic flaws, chained attack paths, and complex authentication bypass scenarios
• Attack surface management. Continuous discovery of external assets to ensure your scanning program covers everything, not just the assets you know about. See our attack surface monitoring guide for details on what ASM discovers
• Code analysis. Static and dynamic application security testing (SAST/DAST) integrated into your CI/CD pipeline to catch vulnerabilities before they reach production
• Threat intelligence. Monitoring for newly disclosed vulnerabilities that affect your technology stack, allowing you to test for specific issues between regular scan cycles

Phase 2: Prioritize

A typical vulnerability scan of a mid-size environment produces hundreds or thousands of findings. Without prioritization, engineering teams are overwhelmed and nothing gets fixed, or resources are spent fixing low-risk issues while critical vulnerabilities remain exploitable.

Risk-based prioritization considers three factors:

1. Vulnerability severity. The CVSS score provides a baseline, but it measures theoretical severity in isolation. A CVSS 9.8 vulnerability on an internal-only development server is lower risk than a CVSS 7.5 vulnerability on your internet-facing payment processing application
2. Asset criticality. What is the business impact if this asset is compromised? Systems handling customer data, payment processing, or authentication are higher priority than internal documentation servers
3. Exploitability context. Is the vulnerability being actively exploited in the wild? Is there a public exploit available? Is the asset internet-facing? These factors dramatically affect the real-world risk of a given vulnerability

Phase 3: Remediate

Remediation is where most vulnerability management programs break down. Findings are identified and prioritized, but fixing them requires engineering time, which competes with feature development and other business priorities.

Strategies that make remediation actually happen:

• Integrate with engineering workflows. Vulnerability findings should flow into the same ticketing system your engineering team uses (Jira, Linear, GitHub Issues). Creating a parallel tracking system that only the security team monitors guarantees findings will be ignored
• Assign ownership. Every vulnerability must have a specific owner responsible for remediation. Findings assigned to a team rather than a person tend to languish
• Provide remediation guidance. A finding that says "vulnerable to CVE-2026-XXXX" is less actionable than one that says "upgrade the express.js dependency in the payments service from v4.18.2 to v4.21.0." The more specific the guidance, the faster remediation happens
• Accept risk formally when appropriate. Not every vulnerability needs to be fixed. Some are genuinely low risk given your environment. But the decision to accept risk should be documented, reviewed, and have an expiration date that triggers re-evaluation

• Do not allow risk acceptance to become a default path for avoiding remediation work
• Do not let critical or high findings sit in a backlog behind feature work -- these need escalation paths to engineering leadership
• Do not rely solely on automated patching for application-layer vulnerabilities -- patches can introduce breaking changes that require testing

Phase 4: Verify

Verification confirms that remediation actually resolved the vulnerability. This step is frequently skipped, which means organizations believe they have reduced risk when in fact the fix was incomplete, the patch did not apply correctly, or a deployment reverted the change.

• Re-scan remediated assets to confirm the vulnerability no longer appears
• For critical findings from penetration tests, request a retest from the testing provider to validate the fix
• Monitor for regression -- a vulnerability that was fixed but reappears after a deployment is a process problem, not just a technical one
• Update your vulnerability tracking system with verification evidence and closure dates

Metrics That Actually Matter

The value of a vulnerability management program is demonstrated through metrics that show risk reduction over time. Vanity metrics (total vulnerabilities found) are less meaningful than operational metrics that demonstrate program effectiveness.

These metrics serve dual purposes: they demonstrate program effectiveness to leadership and board members, and they provide the evidence that compliance auditors need to see. A downward risk score trend and high SLA compliance rate tell auditors that your vulnerability management program is not just documented but genuinely operational.

Compliance Mapping: VM Program Requirements by Framework

Every major compliance framework requires some form of vulnerability management. Understanding the specific requirements ensures your program satisfies auditors without building separate processes for each framework.

SOC 2

SOC 2 CC7.1 requires organizations to implement detection and monitoring mechanisms that identify new vulnerabilities. CC3.2 requires identification and assessment of risks, including technical risks from vulnerabilities. Your vulnerability management program directly addresses both controls, and the metrics you track provide the evidence auditors need. See our guide on SOC 2 continuous monitoring requirements for detailed evidence expectations.

PCI DSS

PCI DSS is the most prescriptive framework regarding vulnerability management. Requirement 6.3 mandates identification and management of security vulnerabilities. Requirement 11.3 requires regular vulnerability scanning, including quarterly ASV scans for external systems and internal scanning after significant changes. Requirement 6.3.3 specifically requires patching critical vulnerabilities within one month of release.

ISO 27001

ISO 27001:2022 Annex A 8.8 requires technical vulnerability management, including timely identification and remediation of vulnerabilities. The control expects a documented process, defined roles, and evidence of consistent execution. Your vulnerability management program's SLA framework and metrics reporting directly support this control requirement.

Why Scanning Alone Is Not Enough

Vulnerability scanning is one input to a vulnerability management program, but treating scanning as the entire program is a common and costly mistake. Here is what scanning misses:

• Business logic flaws. Scanners cannot identify that your application allows users to modify their own role to admin, or that your pricing logic can be manipulated through API parameter tampering
• Authentication and authorization bypass. Complex authentication flows, multi-step authorization checks, and session management issues require human analysis to identify
• Chained attack paths. Individual findings that are medium severity in isolation but combine into a critical attack chain. A low-privilege SSRF combined with an internal service misconfiguration can lead to full database access
• Configuration drift. Scanners check point-in-time configuration but do not monitor for changes. A secure configuration that is modified during a deployment may not be caught until the next scan cycle
• Zero-day vulnerabilities. Scanners rely on known vulnerability signatures. They cannot identify novel vulnerabilities in custom application code

This is why a mature vulnerability management program includes both automated scanning (breadth and frequency) and penetration testing (depth and expertise). The Lorikeet Security Offensive Security Bundle at $37,500 per year provides both: quarterly automated vulnerability scanning across your infrastructure plus annual penetration testing (two web application pentests, one network pentest, one API assessment) that identifies the issues automated tools cannot find. The bundle also includes continuous attack surface management to ensure your scanning program covers all assets, not just the ones you know about.

Building Your VM Program: A Practical Roadmap

You do not need to build a perfect vulnerability management program on day one. Start with the fundamentals and mature over time.

Month 1: Foundation

• Complete an asset inventory (or run an ASM scan to discover your actual attack surface)
• Deploy a vulnerability scanning tool and run your first comprehensive scan
• Define severity-based remediation SLAs aligned with your compliance requirements
• Establish a vulnerability tracking process in your existing ticketing system

Months 2-3: Operationalize

• Assign vulnerability ownership to specific teams or individuals
• Configure automated weekly or continuous scanning for internet-facing assets
• Schedule your first penetration test to identify vulnerabilities scanning cannot find
• Begin tracking MTTR and SLA compliance metrics
• Implement a risk acceptance process with documented justification and expiration dates

Months 4-6: Mature

• Integrate vulnerability data with your SIEM for correlation with threat intelligence
• Implement automated remediation for standard patching where possible
• Establish quarterly program reviews with metrics reporting to leadership
• Add SAST/DAST to your CI/CD pipeline to catch vulnerabilities before production
• Conduct your first program audit against compliance framework requirements

Ongoing: Continuous Improvement

A vulnerability management program is never complete. Each quarter, review your metrics, assess whether SLA thresholds need adjustment, evaluate new scanning tools and techniques, and incorporate lessons learned from penetration tests and security incidents. The goal is a measurable downward trend in risk exposure over time.

Getting Started

If you do not have a vulnerability management program today, the fastest way to start is with two steps: run an attack surface discovery scan to understand the true scope of what you need to protect, and conduct a penetration test to establish a baseline of your current vulnerability posture. These two inputs give you the asset inventory and the findings list needed to build your prioritization and remediation processes.

Lorikeet Security's ASM Personal at $29.99 per month provides continuous asset discovery and vulnerability scanning as the foundation for your VM program. Pair that with an annual penetration test (web application pentests from $7,500, network pentests from $8,000) for the depth that scanning cannot provide. Or start with the Offensive Security Bundle at $37,500 per year to get the full stack: quarterly scanning, annual pentests across multiple vectors, and continuous ASM in a single package.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.