Vulnerability Assessment Report Template (With Example)

A vulnerability assessment report answers four questions. What did we scan? What did we find? Which findings are real? What do we fix first? Leadership reads the summary, IT works from the findings table, and an auditor, insurer or customer checks the scope and the dates. The template below serves all three readers. Each section is explained, there is a filled-in example finding, and you can download the template as a Word document.

If you are reporting on a manual penetration test rather than a scan, use our penetration testing report template instead. The two reports look alike, but they prove different things.

Vulnerability assessment report vs penetration test report

	Vulnerability assessment report	Penetration test report
Question it answers	Which known weaknesses exist across everything in scope?	What can an attacker actually reach, and how?
How findings are found	Automated scanning, then an analyst validates the results	Manual testing that exploits and chains weaknesses
Coverage	Broad: every host, service or application in scope	Deep: selected targets, tested by hand
Typical findings	Missing patches, known CVEs, weak configuration, unneeded services	All of those, plus business logic flaws and attack paths
Proof	Validation status for each finding	Proof of exploitation and impact
Cadence	Monthly or quarterly	Annually and after major changes
Compliance examples	PCI DSS 11.3.1 internal scans, CMMC RA.L2-3.11.2	PCI DSS 11.4, SOC 2 testing evidence

Most programs need both: scans for breadth between tests, and a test for depth once or twice a year. Our penetration testing vs vulnerability scanning guide covers when each one fits.

The template at a glance

1. Cover and document control
2. Executive summary
3. Scope and method
4. Summary of findings
5. Findings table
6. Detailed findings
7. Risk ranking and remediation plan
8. Rescan results
9. Appendices

1. Cover and document control

Client name, report title, version, date issued, classification (usually Confidential), who performed the assessment, and a short version history. Auditors check the dates first, so put the scan dates here as well as in the scope.

2. Executive summary

Half a page to a page, written for someone who will read nothing else.

Template wording:

Between [start date] and [end date], [Firm] performed a vulnerability assessment of [scope in one line] for [Client]. Scanning was [authenticated / unauthenticated] and covered [number] hosts across [networks, sites or cloud accounts].

Overall risk: [Critical / High / Medium / Low]. [One sentence on the most important finding and where it sits.]

After analyst validation, [N] findings remain: [x] critical, [y] high, [z] medium and [w] low. [M] scanner results were removed as false positives or duplicates.

Fix first. [Three to five actions in priority order, one line each.]

What held up. [Two or three things that were in good shape, such as patching on workstations or no services exposed to the internet that should not be.]

Include the count of false positives removed. It tells the reader the report was checked by a person, not exported from a tool.

3. Scope and method

State exactly what was scanned, so nobody later assumes a system was covered when it was not.

• Assets in scope: IP ranges, hostnames, cloud accounts, application URLs, and the host count.
• Exclusions: anything left out, and why.
• Scan type: authenticated or unauthenticated, internal or external, and where the scanner sat on the network.
• Tools: scanner name and version, and the date of the vulnerability feed used.
• Dates and times: when each scan ran, including any rescans.
• Validation method: how findings were confirmed, for example authenticated package checks, configuration review or manual verification.
• Limitations: hosts that were offline, credentials that failed, or services that could not be reached.

Authenticated scans log in to each host and read installed package versions and settings. They find far more than an unauthenticated pass, and they are how false positives get settled. If credentials failed on some hosts, say so here.

4. Summary of findings

A small table of counts by severity, before and after validation, is enough. Use the CVSS qualitative scale so severity means the same thing in every report: Critical 9.0 to 10.0, High 7.0 to 8.9, Medium 4.0 to 6.9, Low 0.1 to 3.9 (FIRST CVSS v3.1 specification).

Severity	Scanner results	After validation
Critical	[ ]	[ ]
High	[ ]	[ ]
Medium	[ ]	[ ]
Low	[ ]	[ ]
False positives and duplicates removed		[ ]

5. Findings table

One row per finding, not one row per host. Grouping every affected host under the finding keeps the list short and lets you assign it to one owner.

ID	Finding	Severity	CVSS	Affected hosts	Validation status	Owner	Due
VA-001	[Title]	[High]	[8.1]	[3 flagged, 1 confirmed]	[Confirmed]	[Team]	[Date]
VA-002	[Title]	[Medium]	[5.3]	[14]	[Confirmed]	[Team]	[Date]

Use a fixed set of validation statuses and define them in the report:

• Confirmed: verified present by an authenticated check or manual review.
• False positive: reported by the scanner but not present, with the reason.
• Not validated: could not be checked, for example because credentials failed. Treat as open.
• Risk accepted: present, with a documented business decision not to fix it now.

6. Detailed findings

Each finding gets its own entry: title, severity and CVSS vector, affected hosts, description, validation evidence, business impact, remediation, and references. Here is a filled-in example.

Example finding: VA-003

Title: OpenSSH signal handler race condition (CVE-2024-6387)

Severity: High. CVSS v3.1 base score 8.1, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (NVD).

Affected hosts: The scanner flagged three hosts. One is confirmed.

Host	Scanner result	Validation	Status
10.20.4.15 (build server)	OpenSSH 9.6p1	Authenticated check: OpenSSH 9.6p1 compiled from source, inside the affected range	Confirmed
10.20.4.21 (Ubuntu 22.04)	OpenSSH 8.9p1	Authenticated check: package openssh-server 1:8.9p1-3ubuntu0.10, which includes the fix	False positive
10.20.4.22 (Ubuntu 22.04)	OpenSSH 8.9p1	Same package version as 10.20.4.21	False positive

Description: A race condition in the OpenSSH server affects portable OpenSSH 8.5p1 through 9.7p1 and is fixed in 9.8p1 (OpenSSH 9.8 release notes). A remote attacker who succeeds could run code as root on the server.

Validation notes: The scanner read the version from the SSH banner. On Ubuntu, the fix ships in a patched package that keeps the upstream version number, so the banner still says 8.9p1. The authenticated package check shows the fixed build from USN-6859-1, so both Ubuntu hosts are false positives. The build server runs a version compiled from source, and no distribution fix applies to it. The finding was confirmed by version and not exploited; a vulnerability assessment confirms presence, and proving impact is the job of a penetration test.

Exposure: SSH on the build server is reachable from the internal server network only. The external scan confirmed it is not exposed to the internet.

Business impact: The build server has access to source code and deployment credentials. Code execution as root there would put the release pipeline at risk.

Remediation: Upgrade OpenSSH on the build server to 9.8p1 or later, or replace the source build with the distribution package so future fixes arrive through normal patching. Until then, limit SSH on this host to the admin jump host.

Owner and due date: Infrastructure team, 30 days (High).

Rescan: [Fixed / Open], verified [date].

The false-positive rows are the point of the example. A raw export would have sent the Ubuntu team chasing two fixes they had already installed, while the one real exposure sat in the same list with the same severity.

7. Risk ranking and remediation plan

CVSS is a starting point, not the order of work. Rank findings on four things:

• Severity: the CVSS base score.
• Known exploitation: whether the CVE is on CISA’s Known Exploited Vulnerabilities catalog. A listed vulnerability goes to the top.
• Exposure: internet-facing hosts before internal ones.
• Asset value: systems that hold sensitive data, credentials or payment data before the rest.

Then set target fix times by severity, and write them in the report so the rescan can measure against them. Set your own, but put them in writing. For example:

Severity	Example target
Critical, or on the KEV catalog	15 days
High	30 days
Medium	90 days
Low	Next maintenance cycle

Our guide to vulnerability remediation covers how to set fix timelines you can defend and run the workflow that meets them.

8. Rescan results

After the fixes, rescan the affected hosts and update each finding’s status and date. Keep the original finding and add the result under it, so the report shows both the problem and its closure. This is the evidence an auditor or a customer asks for.

9. Appendices

Full host list, open ports and services by host, scanner configuration, and the raw export if the client wants it. The raw export belongs at the back, never in place of the validated findings.

The network vulnerability assessment report variant

A network vulnerability assessment report uses the same sections, with three additions:

• Results by network segment: group findings by subnet, site or VLAN, so each network owner sees their part.
• Host and service inventory: every live host, with open ports and services, compared with what should be running.
• Internal and external views: report the external scan and the internal scan separately. A service that is fine inside may be a finding when it faces the internet.

If segmentation matters for PCI DSS or CMMC, note which segments could reach each other during the scan. Our network vulnerability assessment checklist covers what to check before and during the scan.

Download the template

The Word template has every section above with placeholder text, the findings table, the validation statuses, a blank finding entry, the example finding, and a rescan log.

Download the vulnerability assessment report template (DOCX)

A validated report vs a raw scanner export

A scanner export is not a report. It lists every plugin that fired on every port of every host. The same missing patch shows up once per host and sometimes once per port. Banner checks flag software the vendor already patched, as in the example. Informational results sit next to criticals, and nothing is ranked against what the host does for your business.

A validated report is shorter and more useful. Duplicates are merged into one finding with a host list. False positives are removed, each with a reason. Findings are grouped by the fix, so one change can close many rows. The order of work reflects exploitation and exposure, not only CVSS.

A validated report is still not a penetration test. It shows which known weaknesses are present. It does not show how an attacker would chain them, or find flaws no scanner knows about. The VAPT guide explains how the two fit together.

How often to run a vulnerability assessment

• PCI DSS: internal scans at least every three months under Requirement 11.3.1, and external scans by an Approved Scanning Vendor at least every three months under 11.3.2. See ASV scan vs penetration test.
• HIPAA: the current Security Rule sets no fixed cadence. A rule proposed in January 2025 would require scanning at least every six months; our HIPAA penetration testing guide tracks its status.
• CMMC Level 2: RA.L2-3.11.2 requires scanning at a frequency you define, and again when new vulnerabilities are announced. See the CMMC Level 2 checklist.
• CJIS: vendors that handle criminal justice information scan at least monthly under RA-5 and fix criticals within 15 days. See the CJIS compliance checklist.
• Insurers and customers: cyber insurance applications and security questionnaires often ask when you last scanned and how fast you fix critical findings.
• After significant change: a migration, a new site, a merger or a major upgrade.

Monthly or quarterly is the usual rhythm, with a rescan after each round of fixes.

Get a validated scan at a fixed price

We run validated vulnerability scanning at $1,500 per scan for up to 250 devices and $2,500 for 251 to 1,000. An analyst removes false positives, merges duplicates and ranks what is left, and you get a report in this format with a free re-scan of what you fix. Prices are on the vulnerability scanning pricing page. For a broader assessment across network, cloud and applications, see our vulnerability assessment service, or scope your scan and get the price in writing.

Frequently asked questions

What should a vulnerability assessment report include? An executive summary, the scope and method, a findings table with severity and validation status, a detailed entry for each finding, a remediation plan with owners and dates, and rescan results.

Is a vulnerability scan report the same as a vulnerability assessment report? No. A scan report is the tool’s output. An assessment report is what an analyst produces after validating that output: false positives removed, duplicates merged, findings ranked and explained.

How long should the report be? As short as the findings allow. The executive summary fits on one page, and each finding needs enough detail for the owner to fix it without asking questions.

Can I use this template for a network vulnerability assessment? Yes. Add results by network segment, a host and service inventory, and separate internal and external views, as described above.

Does a vulnerability assessment report satisfy PCI DSS? It covers the internal scans in Requirement 11.3.1. External scans under 11.3.2 must be run by a PCI SSC Approved Scanning Vendor, and that scan has its own report format. We provide both: the validated internal scans and the quarterly ASV scan.

Who should write it? Someone who can validate the findings, not only run the scanner. Validation is where the false positives go and the priorities come from.