Vulnerability Management: A Practical Guide to Building a Program That Works

What is vulnerability management?

Vulnerability management is the ongoing work of finding security weaknesses in your systems. You decide which ones matter most, fix them and check that each fix worked. It is a cycle, not a one-off project. A clean scan in March says little about June.

People often mix it up with a vulnerability assessment. That is a one-time review that finds and rates weaknesses in a set scope. An assessment is one input. Vulnerability management is the program around it: owners, deadlines, exceptions, checks and reports. The cycle has six steps:

1. Discover every asset you own or run.
2. Scan and assess those assets for known weaknesses.
3. Prioritize findings by real-world risk.
4. Remediate or mitigate within agreed deadlines.
5. Verify that each fix worked.
6. Report and improve using a small set of metrics.

Step 1: Build and maintain an asset inventory

You cannot protect what you do not know about. Many scanning gaps come from systems nobody listed. Think of a forgotten test server, or a cloud account set up for a trial. Or think of a SaaS tool (software you rent online) linked with an admin API key. An API key is a password that lets one program talk to another. Your list should cover:

• Internet-facing IP addresses, domains and subdomains
• Servers, workstations, laptops and network devices
• Cloud accounts, subscriptions and projects, and the workloads inside them
• Container images and registries
• Web applications and APIs
• Code repositories and the open-source dependencies they pull in

For each asset, record an owner and the environment: production (live), staging (test) or development. Note whether it faces the internet and what type of data it holds. These details drive your priorities later. Pull the list from trusted sources, not a spreadsheet someone updates by hand. Good sources include your cloud provider's APIs, your EDR console and your DNS records. EDR is software on each computer that spots and stops attacks. DNS records link your domain names to your servers.

What is a vulnerability scan, and how often should you run one?

A vulnerability scan is an automated check. It compares your systems against a list of known weaknesses. These include missing patches (software fixes), old software versions, weak settings and exposed services. The scanner gives each finding a severity rating, usually based on CVSS. CVSS is a 0 to 10 score for how serious a flaw is. A scan does not break in or prove harm. It only flags what looks weak.

A mature program uses several types of scan, each on its own schedule. In the table, DAST tests a running website from the outside. SCA checks the open-source code your software borrows. A CVE is the public ID number for a security flaw.

Use authenticated scans where you can. These scans log in, so they can see missing patches that an outside scan cannot. If a compliance standard applies to you, check its rules. PCI DSS is the security standard for businesses that take card payments. It requires internal and external vulnerability scans at least once every three months and after significant changes. An Approved Scanning Vendor (ASV) must run the external scans.

How to prioritize: CVSS, EPSS, CISA KEV and asset criticality

Scanners can report thousands of findings. If you rank them by CVSS alone, teams chase high scores that attackers may never use, while real risks wait. Use four signals together. CVSS rates how serious a flaw is. EPSS estimates how likely attackers are to use it soon. CISA KEV lists flaws that attackers are already using. Asset criticality is how much the system matters to you.

A simple order of work that you can defend:

1. Anything in CISA KEV on a system that faces the internet or runs the business goes first, whatever its CVSS score.
2. Next, findings with a high EPSS score and a High or Critical CVSS score on exposed or sensitive systems.
3. Then the other High and Critical findings, ordered by how much the system matters.
4. Medium and Low findings go into routine patch cycles.

Remediation SLAs, patching and exceptions

Ranking only works if every finding has an owner and a deadline. Write your deadlines, often called service level agreements (SLAs), into policy. Get sign-off from leaders and measure against them. The table below is a common starting point, not a standard. Adjust it to your systems, contracts and compliance duties.

Check outside rules before you set the numbers. PCI DSS v4.0.1 (requirement 6.3.3) requires critical security patches to be installed within one month of release. Other patches must go in within a timeframe the organization sets based on risk. Some customer contracts also set their own timelines.

Most fixes mean patching or upgrading. A few habits help:

• Patch the operating systems and browsers on staff computers automatically. Save human effort for servers and applications.
• Send findings into the tools engineers already use, such as Jira or GitHub issues, with the owner assigned.
• Group findings by fix. One library upgrade can close dozens of findings.

Sometimes you cannot fix a flaw in time. The vendor may have no patch yet, or an upgrade would break a key system. That is what an exception process is for. A good exception records the flaw, the business reason and who accepted the risk. It sets an expiry date. It also lists the compensating controls, meaning the extra safeguards you put in place. Examples are cutting the system off from the network, a WAF rule, turning off the weak feature or extra monitoring. A WAF (web application firewall) filters harmful web traffic. Exceptions without expiry dates quietly become permanent.

Verification and vulnerability management metrics

A ticket marked done is not proof. Rescan or retest to confirm the flaw is gone. Close the finding only when the scanner or tester agrees. Watch for flaws that come back when servers are rebuilt from old images.

Track a few metrics and report them monthly:

• Mean time to remediate (MTTR): the average number of days from finding a flaw to a checked fix, split by severity.
• SLA compliance: the share of findings fixed by their deadline.
• Scan coverage: the share of known systems scanned in the period, ideally with a login.
• Overdue findings: how many critical and high issues are past their deadline, and by how long.
• Recurrence: flaws that come back after being closed. This points to process or image problems.

Trends matter more than single numbers. A falling MTTR for critical issues says more than a raw count of open findings.

Where penetration testing fits

Scanning finds known weaknesses at scale. It cannot tell you if an attacker can chain three medium findings into full access. It also misses flaws in business logic, such as a way to skip a payment step. That is the job of a penetration test. In a pentest, a skilled tester tries to break in the way a real attacker would, with your permission. We cover the difference in vulnerability assessment vs penetration testing.

Use pentesting to check the program, not replace it:

• Run a pentest at least once a year and after major changes, such as a new product, a move to the cloud or a large release.
• Feed pentest findings into the same tracking and deadlines as scanner findings.
• For fast-moving products, consider continuous testing. See PTaaS vs an annual pentest.
• For your own code, add SAST, DAST and SCA to the build process. SAST checks source code for flaws. See SAST vs DAST.

How NextGarrison helps

NextGarrison's penetration testing gives you an independent check on your vulnerability management program. It shows whether you are catching what matters, including systems and attack paths your scanners miss. Our 24/7 SOC can watch for attacks on systems still waiting for a patch. A SOC is a team that watches your systems for attacks around the clock. Not sure where you stand? Start with our free 10-question security assessment.