Vulnerability Management Process: How to Build a Program

The vulnerability management process is the repeating cycle an organization uses to find, rank, fix and verify security weaknesses in everything it runs: prepare, discover assets, identify vulnerabilities, validate and prioritize, respond, verify, and report. A vulnerability management program is that process made durable, with a written policy, named owners, deadlines and evidence, so it keeps running when the person who built it is on vacation.

To have the scanning, validation and rescans run for you, our vulnerability management service starts at $1,500 per cycle; every tier is on the vulnerability scanning cost page.

Why the process matters more than the scanner

In the 2026 Verizon Data Breach Investigations Report, exploitation of vulnerabilities became the most common initial access vector, at 31%, and our vulnerability management metrics guide shows how slowly exploited flaws are being closed. More than 48,000 CVEs were published in 2025 (2025 CVE data review), while CISA added 245 entries to its Known Exploited Vulnerabilities catalog that year. Keeping up depends less on the scanner than on a process that decides quickly what matters, assigns an owner, and confirms the fix.

Process, program, framework and policy

Term	What it is	Evidence it leaves
Process	The stages every finding passes through	One finding’s history, detection to verified fix
Program	The process plus policy, owners, tools, cadence and metrics	A year of scans, tickets, exceptions and trends
Framework	An outside model you map to, such as NIST SP 800-40 or CIS Control 7	A mapping of your practice to it
Policy	The written rules: scope, deadlines, exceptions, who decides	A signed, dated, reviewed document

Most struggling programs have a process and a scanner but no policy, so every deadline is negotiable and every exception permanent.

The vulnerability management process: seven lifecycle stages

Stage	What happens	Output that proves it ran
1. Prepare	Set scope, maintenance groups, deadlines and owners	Approved policy and deadline table
2. Discover	Build and refresh the asset inventory	Owner, exposure and criticality per asset
3. Identify	Scan, and match new advisories and KEV entries to the inventory	Scan results and an advisory log
4. Validate and prioritize	Remove false positives, rank by real risk	A validated, ranked findings list
5. Respond	Remediate, mitigate, transfer, avoid or accept	Tickets, change records, signed exceptions
6. Verify	Rescan or retest the fix	A rescan report showing findings closed
7. Report and improve	Measure, review, adjust the plan	Monthly metrics, quarterly review notes

Vendors list five, six or seven steps in the vulnerability management lifecycle; there is no official count. NIST’s SP 800-40 Rev. 4 uses three: know when new vulnerabilities affect your assets, plan the risk response, and execute it (prepare, implement, verify, keep monitoring).

1. Prepare: scope and maintenance groups

List what is in scope (servers, endpoints, network devices, cloud, containers, SaaS, OT) and name every exclusion. Then sort assets into what NIST calls maintenance groups: sets of assets “with similar characteristics that generally have the same software maintenance needs.” Each group gets a plan for NIST’s four scenarios: routine patching, emergency patching, emergency mitigation and unpatchable assets. Unpatchable assets are a group with their own plan, usually isolation, not exceptions.

2. Discover: an inventory you can trust

You cannot scan what you do not know you own. On the internet-facing side, external attack surface management finds the hosts, subdomains and cloud services nobody recorded. NIST SP 800-40 Rev. 4 favors automated, near-continuous discovery over inventories refreshed by a monthly or quarterly scan. Pull from cloud APIs, endpoint management, EDR, DHCP and DNS, reconcile the sources, and record each asset’s owner, exposure, criticality tier and maintenance group. Under 23 NYCRR 500.13, NYDFS-regulated companies also track location, classification, support expiration date and recovery time objective.

3. Identify: coverage before volume

Run scans that see different things: unauthenticated external, authenticated internal, cloud configuration, and container and dependency scans in the build pipeline. Credentials are the biggest coverage lever: NIST notes unauthenticated scans generally underreport vulnerabilities. A validated vulnerability scan with credentials is the quickest way to see the real backlog, and our network vulnerability assessment checklist walks through the scan procedure.

Someone must also match vendor advisories and new KEV entries against the inventory the day they appear. NIST CSF 2.0 gives the intake side its own outcome: ID.RA-08 asks for established processes for receiving, analyzing and responding to vulnerability disclosures, whether they arrive as a vendor advisory or a report from an outside researcher. Scanners also need a signature: an authorization flaw in your own application or a chained path to domain admin through your configuration has no CVE to match. Our guide to penetration testing vs vulnerability scanning explains which finds what.

4. Validate and prioritize

Validate before anyone else sees a finding; a list that opens with false positives teaches engineers to ignore it. Record what survives in one consistent format; our vulnerability assessment report template has the fields. Then rank by confirmed exploitation (KEV), predicted exploitation (EPSS), exposure and asset criticality, not CVSS alone. CISA’s Binding Operational Directive 26-04, issued June 10, 2026, sets federal deadlines from exposure, KEV listing, automatability and technical impact, in a table informed by CISA’s Stakeholder-Specific Vulnerability Categorization (SSVC), the decision tree that sorts each vulnerability into Track, Track*, Attend or Act; our risk-based vulnerability management guide has the full model and a tier table to copy.

5. Respond: remediate, mitigate, transfer, avoid or accept

NIST lists four risk responses (accept, mitigate, transfer, avoid) and counts patching as mitigation. In practice: patch or reconfigure; add a compensating control (segmentation, a WAF rule) while you wait; move to a SaaS product whose vendor patches it; remove the software; or accept it with a signed, expiring exception. NIST also recommends canary groups and forced installation after a grace period. Group tickets by the change that fixes them: one base image rebuild can clear hundreds of container findings. Our vulnerability remediation guide has the workflow and a tracker to copy.

6. Verify: a closed ticket is not a closed vulnerability

Close a finding only when a rescan or retest shows it gone. PCI DSS Requirement 11.3.1 expects rescans to confirm high-risk and critical findings are resolved, and 11.4.4 requires penetration test findings to be retested. NIST adds a step most programs skip: check that the fix stays in place, because patches get rolled back.

7. Report and improve

Measure each cycle against your policy’s deadlines, split by risk tier and asset importance; NIST warns that simple counts, such as open vulnerabilities or percentage patched, are not actionable. Our vulnerability management metrics guide defines the KPIs and formulas. Feed the results back into stage 1: a group that misses every deadline needs a different plan, not another reminder.

Vulnerability management frameworks and the cadence each one sets

Framework	Reference	What it asks for	Cadence
NIST SP 800-40 Rev. 4	Section 3	Inventory, maintenance groups, a plan per scenario, tracked exceptions, actionable metrics	Risk-based
NIST CSF 2.0	ID.AM-01, ID.AM-02, ID.RA-01, ID.RA-06 to ID.RA-08, PR.PS-02	Inventories; vulnerabilities identified, validated and recorded; responses and exceptions tracked; disclosures handled	Outcome-based
CIS Controls v8.1	Control 7	Process (7.1, 7.2), automated patching (7.3, 7.4), scanning and remediation (7.5 to 7.7)	Internal scans quarterly, external monthly (IG2)
ISO/IEC 27001:2022	Annex A 8.8	Obtain vulnerability information, evaluate exposure, take appropriate measures	Risk-based
PCI DSS v4.0.1	6.3.1, 6.3.3, 11.3, 11.4	Risk ranking, critical patches within one month of release (PCI SSC FAQ 1597), authenticated internal scans, ASV external scans	Scans every three months; penetration test every 12 months
NYDFS Part 500	23 NYCRR 500.5	Written vulnerability management policies, automated scans plus manual review of systems scans do not cover, monitoring for new vulnerabilities, risk-based remediation	Annual penetration test; scans at a risk-based frequency and after material changes
FTC Safeguards Rule	16 CFR 314.4(d)(2)	Continuous monitoring, or periodic testing	Otherwise annual penetration test and vulnerability assessments every six months
SOC 2	CC7.1	Monitoring for newly discovered vulnerabilities and configuration changes that introduce them	Set by you, tested by your auditor

The strictest row that applies sets your floor. Gartner’s CTEM model wraps the same cycle in five stages; our CTEM guide explains each stage and where testing fits. The SOC 2 opinion comes from your CPA firm and the ISO 27001 certificate from your certification body; Invadel supplies the testing evidence. For PCI DSS, ASV scans and Report on Compliance assessments are delivered through Invadel’s PCI partner, Sovereign Secure, a Qualified Security Assessor (QSA) company, quoted from your scope.

How to write a vulnerability management policy

Keep the policy to a few pages and procedures elsewhere. Below are the sections an auditor expects, each with a sample clause. The table works as a starting template: copy the ten clauses into one document, set your own numbers and have the executive owner sign it; for a complete policy worded to ISO 27001 Annex A 8.8 and 8.29, adapt Template 2 of our ISO 27001 policy templates.

Section	Sample clause
Scope	“Covers all company-owned and company-managed assets, including cloud accounts and SaaS tenants. Named exclusions are in Appendix A.”
Roles	“The vulnerability management lead maintains this policy. Every asset has one named owner, responsible for its remediation.”
Asset inventory	“No asset reaches production without an owner, exposure rating, criticality tier and maintenance group.”
Scanning	“Internet-facing assets are scanned monthly. Internal assets are scanned with credentials at least quarterly and after significant change.”
Rating	“Findings are ranked on KEV status, EPSS, exposure and asset criticality. CVSS alone does not set priority.”
Deadlines	“Deadlines run from patch release or discovery, whichever is earlier, and never exceed a contractual or regulatory limit.”
Exceptions	“An exception requires a tested compensating control, a director-level approver and an expiry of no more than 90 days, renewable once.”
Verification	“A finding closes only after a rescan or retest confirms it is resolved.”
Independent testing	“An independent penetration test runs at least annually and after significant change.”
Metrics and review	“Metrics go to IT monthly and to leadership quarterly. This policy is reviewed annually.”

Keep the deadline table in an appendix so it can change without re-approving the policy; our risk-based vulnerability management guide has example tiers. The exception clause gives the policy teeth: CSF 2.0’s ID.RA-07 asks for exceptions to be managed, assessed for risk, recorded and tracked.

Roles and responsibilities: a RACI for the program

R is responsible, A accountable, C consulted, I informed.

Activity	VM lead	Asset owner	IT ops or DevOps	Executive risk owner	Outside tester
Maintain policy and deadlines	R	C	C	A
Maintain the asset inventory	A	R	R
Run scans and track advisories	A, R in-house		C		R if outsourced
Validate and rank findings	A, R in-house	C			R if outsourced
Deploy fixes	I	A	R
Request and approve exceptions	C	R		A
Verify fixes	A, R for rescans	I	I		R for retests
Annual penetration test	A	C	C	I	R
Report metrics	A, R			I

Two rules make it work: every asset has one owner, a person rather than a team, and whoever approves a risk acceptance is not the person who would do the fix. Without a security team, the VM lead is usually the IT manager, whose hours go mostly into validation and chasing owners, the part worth outsourcing.

How to build a vulnerability management program in 90 days

Weeks	Work	Done when
1-2	Name the VM lead and executive owner; draft the policy	Policy approved and signed
3-4	Reconcile asset sources; tag owner, exposure, criticality, maintenance group	Every internet-facing asset has a named owner
5-6	Baseline scans: external, authenticated internal, cloud configuration	Credentialed scans succeed everywhere in scope
7-8	Validate and rank; group by fix; open tickets	A ranked backlog with owners and due dates
9-10	Close KEV-listed findings on exposed assets; sign exceptions for the rest	No exposed KEV finding open without a signed exception
11-12	Rescan; first metrics report; set the year’s calendar; book the penetration test	Recurring scans scheduled, first trend line recorded

Expect the baseline to be long, and to grow as coverage improves; the first 90 days aim for a working cycle, not a clean report.

Where vulnerability management programs break

• Scanning the inventory instead of the network. If targets come only from the asset list, the forgotten server is never scanned.
• No owner for shared infrastructure. Findings on load balancers, base images and shared services sit unassigned.
• Clocks that start late. PCI DSS counts the month for critical patches from release, not from ticket creation.
• Treating the scan as the test. Our guide to security between penetration tests shows how scanning and testing share one calendar.

What it costs to have Invadel run the process

Our managed vulnerability management program runs stage 2, the scanning part of stage 3, and stages 4 and 6 on a monthly or quarterly cycle, and tracks stage 5: rediscovery, authenticated and unauthenticated host and cloud scans, analyst validation, ranking by real risk, tracking on the findings platform, and rescans that prove fixes. You keep the policy, the owners, the fixes, day-to-day advisory monitoring and pipeline scanning.

What you buy	Invadel price	Notes
One validated scan, up to 250 devices	$1,500	Internal or external, with or without credentials
One validated scan, 251 to 1,000 devices	$2,500	Larger estates quoted from the scope
Quarterly program, one scan of up to 250 devices per cycle	$6,000 a year	4 scans at $1,500 each, billed per cycle
Monthly program, one scan of up to 250 devices per cycle	$18,000 a year	12 scans at $1,500 each, billed per cycle
External network penetration test	From $4,200	Free retest of remediated findings
Internal network penetration test	From $6,000	Active Directory paths included, free retest

Each scan is priced on its device count, so quarterly internal and external scans (up to 250 devices each) are eight scans a year; with annual external and internal tests, that starts at $22,200 a year. Re-scans of remediated findings are included, and onboarding starts within 24 hours of a signed proposal. The price calculator adds one of each test you pick, so multiply the scan line by the number of scans in your year. It is testing and validation, not a SOC, MDR, a software license or a vCISO retainer.

Frequently asked questions

What are the 5 steps of vulnerability management? The common version is identify, evaluate, prioritize, remediate and verify. There is no official count: NIST uses three stages (know, plan, execute), and this guide uses seven to add preparation and reporting.

How often should we scan for vulnerabilities? CIS Control 7 sets automated internal scans, authenticated and unauthenticated, at least quarterly (Safeguard 7.5) and external scans at least monthly (7.6). PCI DSS requires internal and external scans every three months and after significant change. The FTC Safeguards Rule requires assessments every six months and after material changes unless you monitor continuously (16 CFR 314.6 exempts small institutions). NYDFS sets a risk-based frequency plus a scan after any material system change.

What tools does a vulnerability management program need? An asset inventory; an authenticated network scanner; cloud configuration checks; container and dependency scanning in the build pipeline; a ticketing system; and a place to track exceptions and rescans. Validation and ownership matter more than the tools.

What is the difference between a vulnerability management program and a vulnerability disclosure program? A vulnerability management program is internal: you find and fix weaknesses in the systems you run. A vulnerability disclosure program is the public front door: a published policy and contact that tell outside researchers how to report a security vulnerability and what to expect in return. They meet at intake, the process CSF 2.0’s ID.RA-08 asks for, where an outside report enters the same validate, prioritize and fix cycle. To report a vulnerability in Invadel’s own systems, use our responsible disclosure policy.

Who should own vulnerability management in a company without a security team? Usually the IT manager, as VM lead, with an executive who signs the policy and approves risk acceptances. Every asset still needs one named owner accountable for its fixes. Validation and chasing owners take most of the lead’s hours, which is why that part is the one most often outsourced.

Is vulnerability management the same as patch management? No. Patching is one response inside vulnerability management. Misconfigurations, weak credentials, end-of-life software and flaws in your own code have no vendor patch but still need a decision.

Does a vulnerability management program replace penetration testing? No. Scanning finds known weaknesses across many systems on a schedule. A penetration test finds what scanners cannot, such as authorization flaws and chained attack paths, and proves the impact. PCI DSS requires both, as does NYDFS Part 500 unless the limited exemption in 500.19(a) applies.

The short version

The vulnerability management process is a cycle: prepare, discover, identify, validate and prioritize, respond, verify, report. A program makes it durable with a policy, owners, deadlines and evidence, and is judged on how fast exploitable findings close, not how many it finds. To have the scanning, validation and rescans run for you, from $1,500 per scan with re-scans of remediated findings included, see our vulnerability management program and its published pricing, or scope it now.