Building a Vulnerability Management Process That Works in Practice

An auditor asks a simple question: show us that the critical VPN gateway vulnerability every industry newsletter covered in the spring has been fixed. The team opens the ticketing system. The task was closed three months ago with the comment "update installed." An engineer goes to check and discovers there are two gateways. The second was deployed at a backup site for a temporary project long ago. It never made it into the inventory, the scanner never knew about it, and it still has no owner. Nobody installed the update on it, simply because nobody knew it needed one.

This is a hypothetical scenario, not an account of a real incident. But every detail in it is recognizable: a closed ticket standing in for a confirmed fix, an asset with no owner, a scanner that diligently checks only what it has been shown. An organization like this can have an expensive platform, weekly reports and even a regular pentest, and still not have a vulnerability management process. What it has is a set of activities that occasionally overlap.

What follows is how to turn scattered scans and one-off fixes into a repeatable cycle with clear owners: rank findings by risk rather than by the color in a report, close them in a way you can prove, and know when a platform or contractor makes sense. It is written for security leaders, operations and application security teams, and procurement.

Why a scanner is not yet a process

A vulnerability management process is neither a product nor a scan schedule. It is a cycle of decisions: know which assets you have, find their weaknesses, decide what matters most, fix or mitigate the risk, verify the result, and remove the causes that make the same problems come back. A scanner answers only the second part, and only partly.

NIST SP 800-115 (2008) offers a useful reminder of this. The document explicitly describes itself as an overview of the key elements of technical security testing and assessment rather than a comprehensive testing program. It describes the phases of an individual assessment, namely planning, execution and post-execution, but does not attempt to cover how an organization lives with the results between assessments. That part, covering ownership, prioritization, exceptions and closure control, is the process you have to build yourself.

What belongs in scope

The first design decision is the boundary. A mature process covers infrastructure, cloud and on-premises hosts, web applications, APIs, and the software you build or buy. Every narrowing creates a predictable blind spot. A process limited to network scanning misses entire classes of weaknesses that live in code and architecture: authorization errors, business operation logic, unsafe data handling. A process limited to code review does not see configuration drift in production: an open port, a weakened header, a test interface someone forgot to switch off.

Scope does not have to be complete on day one. But it must be written down, and exclusions from it must be deliberate. "We do not yet assess our contractors' SaaS services" is a decision with an owner. "We did not know we were using contractors' SaaS services" is a gap.

A practical cycle

In practice it helps to think in five connected steps. This is the author's working model, not a formal model from any standard: the SP 800-115 phases describe a single assessment, while this cycle describes how the results of many assessments turn into decisions and changes.

1. Inventory and ownersEvery in-scope asset has an owner, a criticality class and a flag for external exposure. Without this, every finding floats in the air.
2. AssessmentScanning, testing and analysis are matched to the asset class. The method and its version are recorded so that results can be compared over time.
3. PrioritizationTechnical severity is combined with exploitation evidence, business criticality and asset exposure. Ranks are recalculated whenever the inputs change.
4. Remediation or decisionA fix, a compensating control, time-bound risk acceptance, or documented closure as a false positive, not-applicable case or retired asset.
5. Retest and root-cause reviewRepeat the original scenario and, where relevant, add related variants or a valid equivalent check with documented limitations. Recurring weakness classes feed into development and operations standards.

Governance and roles: who owns the cycle

Governance comes first because every other step depends on it. If nobody is defined as authorized to accept risk, any inconvenient finding will sit in the backlog indefinitely: formally open, in practice accepted by no one.

The process policy should answer a handful of questions: what is in scope; who owns each asset; who is permitted to test what; how quickly risks at each level should be closed; and who may formally accept residual risk, and for how long. Policy sets the timeframes from risk, operational capacity, and applicable regulatory and contractual obligations; there is no universal industry deadline for every organization.

The NIST Cybersecurity Framework 2.0 is a convenient anchor for writing such a policy. NIST positions CSF 2.0 as a tool to help organizations understand and improve their management of cybersecurity risk. It includes profiles for describing current and target state, quick-start guides for common tasks, and informative references that link the framework to other NIST resources. Vulnerability management deserves the same treatment: a risk process with decisions and owners, not a report generator.

Roles without which the cycle falls apart

The minimum set of roles looks like this. The process owner is accountable for the whole cycle and its metrics. Asset owners are responsible for inventory accuracy and risk decisions in their systems. Internal or contracted remediation teams carry out the changes. A person authorized to accept risk approves time-bound exceptions. Closure verification needs enough objectivity; for material risk, separating it from the person who made the fix is sensible.

In a small company one person may hold several roles. If an independent verifier is disproportionate to the risk or unavailable, support self-checks with reproducible evidence, approval by the risk owner or peer review. No one should close their own ticket without any verification.

Authorizing testing

Authorization is part of governance too. Any scanning and testing is acceptable only with written permission that defines boundaries, timing, contacts and safety constraints. SP 800-115 gives planning particular attention precisely because permissions and rules of engagement are fixed before work begins.

A practical subtlety: permission must come from every party empowered to approve testing of the affected assets and environments. A cloud provider, a hosting company, a contractor who maintains the system, the owner of a SaaS service: each may have its own rules. The CIO's consent does not automatically extend to infrastructure the organization does not own.

Inventory and discovery: you cannot protect what you do not know about

The foundation of the process is an asset inventory with assigned owners. Not a spreadsheet filled in when the platform was rolled out, but a regularly reconciled list: what exists, who owns it, how critical it is to the business, whether it is reachable from the internet. Reconciliation is the key word. There are usually several sources of truth: the CMDB, cloud consoles, DNS, certificate registries, network equipment data. Discrepancies between them are your candidates for a "second gateway."

The external attack surface deserves a separate look, because an inside-out inventory sees what the organization considers its own, while an attacker sees what actually answers requests. For more on assessing it from the outside and ranking what you find, see our article on external attack surface assessment.

Scanning, testing and analysis are different tools

SP 800-115 offers practical recommendations for designing, conducting and maintaining technical testing. Its value for the process is that it describes the benefits and limitations of different techniques: vulnerability scanning, penetration testing, analysis and review. That helps you match technique and frequency to an asset class instead of running everything through one scanner at one cadence.

For example, automated version and configuration checks can provide repeatable coverage of a workstation fleet and detect patch lag. On a public API with payment logic, a scanner alone does not fully test authorization and business logic; manual testing may be needed around material releases. For a stable internal system, set the interval for deep assessment from risk, changes and obligations. The choice is a trade-off between cost, frequency and depth, and it is worth writing into the policy by asset class.

Web applications and APIs: a versioned methodology

For web applications and APIs, the OWASP Web Security Testing Guide remains one of the main public testing references. When the original material was prepared, version 4.2 was the stable release and 5.0 was in development; check the current status before writing a number into a contract. The idea matters more than the number: if you pin the exact methodology version in test plans, contracts and reports, results from different years can be compared with each other.

OWASP ASVS covers the requirements side. The standard sets verifiable application security requirements and a basis for testing technical security controls. ASVS 5.0.0 recommends referencing requirements with the version included, for example v5.0.0-1.2.5, because numbering may change between versions. Requirement lists are published in machine-readable formats, including CSV and JSON. You can import them into a ticketing or vulnerability management system and link each finding to a specific requirement. "A vulnerability in the login form" then becomes a verifiable statement: requirement such-and-such of version such-and-such is not met.

Configuration drift

Configuration weaknesses need lightweight but continuous checking. MDN documents browser security mechanisms, and each has its own boundary of responsibility that is worth understanding when triaging findings. Content Security Policy restricts where a page may load scripts and other resources from. CORS determines whether a script in the browser may read a response from another origin; it is not server-side authorization, and a permissive CORS policy is no substitute for permission checks. Cross-Origin Resource Policy lets you withhold the body of certain no-cors responses from other origins, but it does not necessarily stop the requests themselves. Permissions Policy controls a page's access to browser features.

MDN also points to HTTP Observatory for checking a site's configuration. Such checks are cheap to automate: not a replacement for testing, but an early sensor for drift between releases.

Vulnerability prioritization: severity, exploitation and context

A high severity score on its own does not make a finding a priority. Rely on it alone and the team ends up with hundreds of "critical" tasks closed in order of arrival, while a genuinely dangerous problem on an internet-facing server gets lost in the middle of the list.

Workable prioritization combines four groups of signals: technical severity, evidence of real-world exploitation, the asset's business criticality, and its exposure, for instance whether it is reachable from untrusted networks. These signals answer different questions, and confusing them is dangerous.

A few caveats on the table. EPSS is a probabilistic estimate, not a promise: a low value does not mean the vulnerability will never be used. Absence from KEV does not prove a vulnerability is safe; the catalog records what there is evidence of exploitation for, not everything that is being exploited. Remediation deadlines associated with KEV are addressed primarily to US federal agencies and are not a universal requirement for every organization.

MITRE, for its part, notes that certain weakness classes, such as command injection, are particularly attractive to attackers, and publishes a ranking of weaknesses built from KEV data. That is useful for root-cause discussions, but remember that CWE classifies defect types, not the probability that a specific vulnerability will be exploited. How to turn these signals into a reproducible ranking method is covered in detail in our article on risk-based vulnerability prioritization.

Priority tiers as a design decision

It is convenient to reduce the signals to a small number of tiers. What follows is a design proposal, not an industry norm; your risk owners should set the timeframes for each tier.

Emergency tier can include the combination of exploitation evidence, reachability from untrusted networks and a critical asset. But this is not a closed filter: signs of active compromise, incident-response needs, or regulatory and contractual deadlines can raise a finding to the emergency track without all three conditions. Expedited tier: known exploitation on internal assets, or high severity on external critical systems. Standard tier: high or medium severity with no signs of exploitation; these fixes ride the normal release cycle unless an obligation requires otherwise. Planned tier: low severity or strong compensating controls; batch remediation or documented risk acceptance.

More tiers make the model more precise but harder to operate. The four tiers in this example provide a usable frame that each organization should calibrate to its risks and obligations.

Recalculating priorities

Priority is not a property of a finding but a function of its inputs, and the inputs change. A vulnerability is added to KEV, a service gets an external address, a system starts processing payments: the ranks of open findings should be recalculated automatically. If priority is assigned by hand once at registration, a month later it no longer describes your reality.

Remediation: patch, configuration, compensating control or risk acceptance

Every finding needs a recorded outcome: a fix through an update, code or configuration; a verifiable compensating control; formal risk acceptance with an owner and expiry; or confirmed closure as a false positive, not-applicable case or result on a retired asset. An exception or accepted risk is not the same as a fix, and "it sits there until someone gets to it" is not an outcome.

A compensating control is an honest option when a fix cannot be made quickly, for example when the vendor has not yet released an update and the system cannot be taken down. But it must have a verifiable mechanism. "We restricted access" is a claim. "Firewall rule such-and-such allows access to the port only from administrator addresses, verified by such-and-such test" is a control that can be confirmed at retest.

Exceptions that do not become permanent

An exception is a decision with an end date. It records the finding, the reason, the compensating controls, the risk owner, who approved it and when it expires. On expiry it is not silently extended: either the problem has been fixed or the exception is reviewed afresh with the same questions. It is also worth tracking exceptions that have been extended several times in a row: they usually signal not a particular vulnerability but architectural debt that needs to be raised to budget level.

How to organize tracking of fixes and exceptions so that the history of decisions can be reconstructed for any finding is described in detail in our article on vulnerability remediation control.

Changes without fear of downtime

Fixes carry their own operational risk: teams postpone updates for fear of downtime. CISA's Safe Software Deployment guidance describes a deployment process with testing and measurement at each stage. The logic carries over to internal operations: if security fixes go through a proven change pipeline with rollback capability, the temptation to postpone them shrinks.

Applying a fix successfully on a test bench does not automatically mean it will work the same way in production: configurations, data and load differ. Normally, repeat the original scenario in the environment where the finding occurred. If active validation there creates unacceptable risk, a valid equivalent check or configuration evidence can be used, with the environmental differences and limitations stated in the conclusion.

Root causes: working with weakness classes

Fixing findings one at a time is necessary but not enough. The strongest lever is eliminating entire classes of defects so that they stop appearing.

In describing the 2025 CWE Top 25, MITRE emphasizes exactly this role: understanding root causes feeds back into the development lifecycle and architecture and helps eliminate entire classes of problems, such as those related to memory safety and injection, reducing the number of vulnerabilities that have to be dealt with after deployment. Beyond the main list, MITRE also publishes weaknesses that came close to being included in the ranking. That list is useful for teams whose typical findings sit just outside the main one.

The same logic shows up in CISA's Secure by Design materials. The agency issues guidance on eliminating specific vulnerability classes, such as cross-site scripting, OS command injection and directory traversal, and on roadmaps for moving to memory-safe languages, including external open source dependencies. For in-house development the conclusion is practical: recurring findings should become secure coding standards, templates, libraries and checks in the build pipeline. The OWASP Top 10, in its 2025 edition, remains a widely recognized baseline for developer awareness, but a baseline for awareness, not a complete set of requirements.

A hypothetical example. For the third release in a row, a team receives injection findings in different report forms. It could fix the specific field each time. Or it could replace hand-built queries with a parameterized data access layer, add a rule to static analysis and add a check to acceptance criteria. The first path closes tickets; the second closes a class of problems. The difference will show up in the recurrence metrics discussed below.

Retesting and evidence of closure

A closed ticket does not yet mean a fixed vulnerability. For closure, repeat the original scenario and, where relevant, test nearby bypass variants; a valid equivalent check is acceptable when the method and its limits are recorded. That may mean a rescan for a scanner finding, the corresponding methodology test for a web finding, or a check against a specific ASVS requirement for an applicable application or API gap. ASVS helps define coverage and rigor for applications; it is not a closure standard for all infrastructure.

SP 800-115 maps testing to control families including audit and accountability, assessment, authorization and monitoring, and risk assessment. Carefully gathered evidence will therefore also help in audits, but on its own it is not a certification or an opinion of compliance.

Treat evidence as sensitive data. Logs and server responses may contain tokens, personal data and internal addresses. Minimize what you keep, redact secrets, restrict access, protect integrity and define a retention period.

One more boundary: a retest confirms a specific fix under stated conditions and scope, not the permanent absence of risk. If the service is reconfigured a month later, the earlier result says nothing about the new state. How to build such checks and phrase their conclusions is covered in our article on penetration test remediation validation.

An independent test as a check on the process itself

Periodic independent testing, such as an authorized penetration test, can provide evidence about the process as well as the systems. If testers find what scheduled assessment missed, examine coverage, timing, technique choice and system changes; one such result does not prove a single cause. A pentest is not a certification or security opinion: it records the scenarios tested and their outcomes within agreed boundaries and conditions. If you want to discuss which assets and what evidence to include in such an independent check, a good starting point is describing your pentest scope together with the Pentest.red team.

Metrics: flow, not volume

Measure the movement of findings through the cycle and the outcomes, not the count. Useful indicators include: the share of inventoried assets under regular assessment; time to remediate by priority tier; the age profile of open findings; the number of active exceptions and their expiry dates; the share of closures confirmed by retest on the first attempt; and the recurrence of findings by CWE class. These are recommended indicators, not industry benchmarks, and your policy sets the targets for them.

Linking findings to CWE lets you see trends and check whether root-cause work is paying off. A falling recurrence rate for injection classes or memory-handling errors is stronger evidence of progress than a falling total number of findings. Leadership reporting should use risk terms aligned with CSF 2.0 outcomes: what share of critical assets is under control, how many emergency findings have been open longer than policy allows, which exceptions expire in the coming quarter.

Metrics that do harm

Avoid metrics that exist for reporting's sake. The total number of findings rises when coverage improves: you onboard new network segments, you start testing APIs. Judge a team by that number and you penalize exactly the behavior you are trying to encourage. A similar trap is mean time to remediate across all findings at once: a dozen fast low-tier closures mask a single emergency issue that has been open for a month. That is why remediation time is looked at by tier, not on average.

Choosing a platform or provider to fit a defined process

Tools and contractors are best chosen after the process has been defined. Otherwise the tool's default settings become your process: its priority model, its notion of "closed," its metrics. A platform helps you run the process, but it does not replace decisions about owners, exceptions and evidence.

CISA has published the Secure by Demand guide for software customers; it helps frame questions for suppliers during procurement. A joint publication from Australia's ACSC and CISA on choosing secure and verifiable technologies is addressed directly to procuring organizations. Both are useful as a source of questions, not as a list of mandatory requirements.

What to ask a supplier

When evaluating a platform or an external service, ask for verifiable answers rather than promises:

• which methodologies and versions are used, for example SP 800-115, a specific WSTG version and ASVS 5.0.0;
• how authorization, boundaries and rules of engagement are documented before any work begins;
• whether prioritization takes exploitation evidence and asset context into account, not just a severity score;
• whether findings are mapped to CWE and applicable application and API findings to versioned ASVS requirements;
• which export formats and integrations with your ticketing system are available;
• whether retesting to confirm closure is included, and under what conditions;
• how long evidence is retained, who owns it and how it is protected.

Apply the same rigor to the products you operate. CISA runs the voluntary Secure by Design Pledge with seven goals, against which signatories publish progress reports. Signing is not a certification, but such a report is a useful input signal. In its Secure by Design materials the agency also insists that products should be secure by default and that basic security features such as multi-factor authentication, logging and single sign-on should not be sold at extra cost.

In-house, outsourced or hybrid

The choice of model depends on three factors: the size and diversity of the asset estate, staff skills in testing and remediation, and the volume of in-house development. A small estate with little custom code can often be served by a platform plus periodic external testing. A product company with several development teams usually needs internal ownership of root-cause work, because that work lives inside the development lifecycle.

The trade-offs are these. Handing discovery and testing to a contractor brings expertise and an independent view. A contract can also delegate execution of some fixes, while the organization remains accountable for its assets and risk-acceptance decisions and verifies the work performed. A fully in-house program gives control and context but requires a stable team. A hybrid is one way to divide governance, prioritization, remediation, testing and verification; choose the roles from risk, capability and contractual boundaries. For more on what a managed service can delegate, see our article on vulnerability management as a service.

If a hybrid model suits you, you can discuss the external part with Pentest.red: which asset classes to include in penetration testing, what evidence your ticketing system needs and in what format, and how to organize retesting of fixes. Decisions about owners, timeframes and risk acceptance remain with your organization.

Where to start

A vulnerability management process is built not around a scanner but around ownership, authorization, risk-based prioritization, verified closure and learning from root causes.

Start with scope and owners: write down what you assess and who is responsible for what, and reconcile the inventory against at least two independent sources. Then introduce prioritization that accounts for exploitation and asset context, and an exception rule with an end date. Require evidence for every closure decision and retesting for remediated vulnerabilities and start counting recurrence by weakness class. Once that groundwork is in place, choosing a system or service comes down to selecting providers to fit a clear process, rather than letting providers define the process for you. And then you will have an answer to the auditor's question about the second VPN gateway before it is even asked.