Vulnerability assessment: process, ranking and sample report

A vulnerability assessment finds, lists and ranks security weaknesses in a defined set of systems. It answers one question: what known weaknesses do we have, and which should we fix first? It does not try to break in.

What is a vulnerability assessment?#

A vulnerability assessment is a systematic review of systems for security weaknesses. The NIST glossary, citing CNSSI 4009-2022 and NIST SP 800-30 Rev. 1, defines it as a "systematic examination of an information system or product to determine the adequacy of security measures". The definition adds that the purpose is to find security gaps and to verify that fixes work after they are in place.

In practice, most assessments combine automated scanning with a person who checks the results. The scanner compares what it finds, such as software versions and open ports, against a database of known issues. The person removes false alarms and adds context. The output is a ranked list of weaknesses with fix guidance.

An assessment fits a team that needs to know its exposure on a regular basis. It suits IT and compliance staff who manage many assets and need a repeatable routine. Penetration testing is a different activity with a different goal, and the last section below covers when to add it. Our what is penetration testing guide explains that side.

What are the six steps of the vulnerability assessment process?#

The process runs in six steps, and the last one feeds the first. Each step has an output you can check.

Two choices in step 3 change the result. An authenticated scan logs in to the system and sees installed software and local settings. An unauthenticated scan sees only what an outsider sees. Run both, because they answer different questions: what is inside, and what is exposed.

Step 1 matters for safety. Scans send a lot of traffic, and some old devices and services fail under it. Agree the scan windows and the rate limits in writing. NIST SP 800-115, published in 2008 and still listed as final, treats scanning as one of several technical testing techniques and discusses its benefits and limits.

Step 2 is where many programs fail. A scanner cannot assess an asset it never found. Cloud accounts, forgotten test servers and third-party hosted apps are common gaps.

How do you rank vulnerability assessment findings?#

Rank by three things together: how bad the flaw is, how likely someone is to exploit it, and what the affected asset is worth. A severity score alone is not enough.

Severity. CVSS gives a 0 to 10 score. FIRST's v4.0 specification maps scores to ratings: None 0.0, Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. CVSS measures how severe a flaw is in general. It does not know your environment unless you add the environmental metrics.

Exploitability. Two public sources help. EPSS, from FIRST, is "a data-driven machine-learning model" that estimates "the probability that a published CVE will be exploited in the wild in the next 30 days". The CISA Known Exploited Vulnerabilities (KEV) catalog is, in CISA's words, "the authoritative source of vulnerabilities that have been exploited in the wild", and CISA says organizations "should use the KEV catalog as an input to their vulnerability management prioritization framework."

Asset value. A flaw on a public login server that holds customer data matters more than the same flaw on an isolated test box. Tag each asset as high, medium or low based on the data it holds and its exposure to the internet.

A simple order of work follows from these inputs:

1. In KEV and exposed to the internet: fix first.
2. High or Critical severity, on a high-value asset: fix next.
3. High EPSS score on any asset that handles data: fix after that.
4. Everything else: fix by severity, in the normal patch cycle.

Record the reason for each ranking. An auditor or a customer may ask why a Critical item waited, and a written reason is the answer.

What does a vulnerability assessment report contain?#

A good report lets an engineer fix each item without a follow-up call, and lets a manager see the risk at a glance. No standard fixes one format, so ask for a sample before you buy from any provider.

Include these parts:

• Scope, dates and scan types (authenticated or not), with tool names and versions.
• A summary of counts by rating and by asset group.
• A ranked finding list, with one entry per finding.
• Fix guidance and an owner for each entry.
• A list of items scanned but not assessable, and why.
• Rescan results when the report is a follow-up.

Each finding entry needs the same fields. This sample shows one row.

For a longer list of what to look for in a report, see how to read a penetration testing report. The structure applies to both report types.

How often should you run a vulnerability assessment?#

Run one on a fixed schedule, and again after any major change. The right schedule depends on how fast your systems change and what your standards require.

Common triggers:

• A fixed cycle that you set, such as monthly or quarterly, for the whole estate.
• After a major release, a new cloud account or a network change.
• When a new KEV entry affects software you run.
• After a fix, to confirm it with a rescan.

Standards set their own minimums, and they differ. Read the exact text for the standard you follow, and ask your auditor what they accept. Do not assume that one scan type covers another requirement. Our how often should you pentest guide covers the matching question for penetration tests.

Between full runs, keep the asset list current. New assets are the most common source of unscanned risk.

What can a vulnerability assessment not tell you?#

An assessment reports known weaknesses. It does not show what an attacker can do with them, and it misses flaws that no scanner has a check for.

It cannot tell you whether user A can read user B's data, whether a discount code can be abused, or whether three small flaws chain into a breach. These need a person who tests how the app works. The difference between a scan and a pentest is a common buyer question, and PentestCompare answers it in a neutral pentest versus vulnerability scan guide.

When should you add a penetration test?#

Add a pentest when you need proof of impact, when a customer or standard asks for one, or when you ship a new app or API. Run the assessment first and fix what it finds, so the tester's time goes to deeper problems.

A pentest takes the same systems and asks what an attacker can do with the weaknesses. A tester confirms real effects with evidence, such as reading another account's record through a second session. The result is a smaller list of proven findings with fix guidance. Read after the pentest: remediation and retest for the follow-up work. To see what a delivered report looks like, open our sample report.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report