Network Vulnerability Assessment Checklist: 30 Checks Before, During, and After the Scan

A network vulnerability assessment is easy to run badly. Point a scanner at a range, export the report, and you have a document with hundreds of findings, a third of them false positives, ranked by a score that has nothing to do with your environment. Run well, the same exercise produces a short, verified list of the exposures that actually matter, in the order they should be fixed, with evidence an auditor accepts.

The difference is the work around the scan. This checklist covers it: what to settle before scanning, how to scan for coverage rather than noise, how to validate and prioritize the output, and what the report needs to contain for PCI DSS, SOC 2, NYDFS, and ISO 27001. Our vulnerability assessment services follow this sequence on every engagement, and it works just as well for an internal team.

The 30 checks on one page (printable)

Print this table or copy it into a ticket, and tick each check as you go. Each one is explained in the sections below. If you are preparing for a penetration test rather than a scan, our network penetration testing checklist covers the test side instead.

#	Check	Stage	Done
1	Write down the purpose of the assessment	Scoping	☐
2	List every network range in scope, cloud networks included	Scoping	☐
3	Add public IPs on cloud load balancers, storage and databases	Scoping	☐
4	Decide internal, external or both	Scoping	☐
5	Arrange credentials for authenticated scanning	Scoping	☐
6	Flag fragile systems and give them a gentler profile	Scoping	☐
7	Set scan windows and tell monitoring and system owners	Scoping	☐
8	Agree exclusions in writing, with a reason for each	Scoping	☐
9	Discover hosts across the whole range, not just known hosts	Discovery	☐
10	Reconcile discovered hosts against the asset inventory	Discovery	☐
11	Map the external footprint independently	Discovery	☐
12	Record each host’s role, owner and criticality	Discovery	☐
13	Scan all TCP ports, not the default top thousand	Scanning	☐
14	Add UDP for DNS, SNMP, NTP and TFTP	Scanning	☐
15	Run authenticated scans wherever credentials exist	Scanning	☐
16	Scan web applications separately, with a web scanner	Scanning	☐
17	Check cloud configuration with a cloud tool	Scanning	☐
18	Update scanner plugins and CVE feeds first	Scanning	☐
19	Confirm the scan completed and log every gap	Scanning	☐
20	Remove false positives by hand	Validation	☐
21	Confirm exploitability of the top findings	Validation	☐
22	Deduplicate across hosts and scans	Validation	☐
23	Add exposure and data context the scanner lacks	Validation	☐
24	Rank by KEV and EPSS, not CVSS alone	Prioritization	☐
25	Weight findings by asset criticality	Prioritization	☐
26	Group findings into remediation projects	Prioritization	☐
27	Assign an owner and a due date to each	Prioritization	☐
28	Rescan after remediation and compare	Remediation	☐
29	Record risk acceptances with a review date	Remediation	☐
30	Write the executive summary and the technical detail	Reporting	☐

Before the scan: scoping

1. Define the assessment’s purpose. A quarterly PCI scan, a baseline before a penetration test, and a post-incident sweep have different scopes and different reporting needs. Write the purpose at the top of the plan.
2. Enumerate every network range in scope. Corporate LAN, server VLANs, DMZ, remote sites, VPN pools, and every cloud VPC or virtual network. The ranges nobody listed are where the findings hide.
3. Include cloud and hosted assets. Public IP addresses assigned to cloud load balancers, storage endpoints, and managed databases belong in the external scope even when no server “owns” them.
4. Decide internal, external, or both. External scans show what the internet sees; internal scans show what a foothold sees. Most compliance frameworks expect both, and the findings barely overlap.
5. Arrange credentials for authenticated scanning. A domain account with local read access, SSH keys for Linux hosts, and read-only credentials for network devices. Unauthenticated scans see open ports and banners; authenticated scans see missing patches and configuration, and typically report several times more real findings.
6. Flag fragile systems. Operational technology (our page on OT and ICS penetration testing covers how plant networks are tested safely), medical devices, legacy servers, and anything that has crashed under a scan before. These get a passive or reduced-intensity profile, or a maintenance window.
7. Set scanning windows and notify the right people. Security monitoring should know the scanner’s source addresses so alerts can be triaged rather than escalated, and system owners should know when their hosts will be probed.
8. Agree the exclusions in writing. Anything out of scope is documented as out of scope, with a reason, so the report can say what was not assessed.

Discovery: finding what is actually there

9. Run host discovery across the entire range, not just known hosts. Ping sweeps are blocked more often than they used to be; use TCP and UDP probes and ARP on local segments.
10. Reconcile the discovered hosts against the asset inventory. Every unknown host is a finding in its own right before any vulnerability is counted. Shadow IT, forgotten test boxes, and unmanaged devices surface here.
11. Map the external footprint independently. Subdomain enumeration, certificate transparency logs, and internet-wide scan data find assets the IP list missed. Our guide to external attack surface management covers the method.
12. Record what each host is. Operating system, role, owner, and criticality, so prioritization later can use business context rather than CVSS alone.

Scanning: coverage over speed

13. Scan all TCP ports, not the default top thousand. Services on unusual ports are exactly what an attacker looks for.
14. Include UDP for the services that matter. DNS, SNMP, NTP, and TFTP misconfigurations are missed entirely by TCP-only scans.
15. Run authenticated scans wherever credentials were arranged. This is the single largest coverage improvement available, and the step most often skipped because “the scanner found plenty already.”
16. Scan web applications with a web scanner, separately. A network scanner identifies that a web server exists; it does not test the application. Application findings need their own tool and, for anything important, a web application penetration test.
17. Scan cloud configuration with a cloud tool. IAM, storage permissions, and security groups are not visible to a network scanner. A cloud security assessment reviews them against the CIS benchmark for your provider, and a cloud penetration test chains them.
18. Keep the scanner’s plugins and CVE feeds current. A scan run with a month-old feed misses a month of disclosures, which at recent rates is several thousand CVEs.
19. Confirm the scan completed. Hosts that timed out, credentials that failed, and ranges that were unreachable are listed in the raw results and are easy to overlook. Each one is a coverage gap to fix or document.

Validation: turning output into findings

20. Remove false positives by hand. Version-based detections flag patched-and-backported packages, disabled services, and mitigations the scanner cannot see. On a typical first scan a meaningful share of the critical and high findings do not survive validation.
21. Confirm exploitability for the top findings. Is the vulnerable service reachable from where an attacker would sit? Does a working exploit exist? Is the vulnerable code path actually enabled? Ten minutes of checking per critical finding changes the remediation order completely.
22. Deduplicate across hosts and scans. One vulnerable library on forty hosts is one remediation task, not forty findings.
23. Add the context the scanner lacks. Which findings sit on internet-facing hosts, on systems that hold regulated data, or on the path to the domain controllers. This is where the asset inventory from step 12 earns its keep.

Prioritization: what to fix first

24. Rank by exploitability and exposure, not by CVSS alone. Use CISA’s Known Exploited Vulnerabilities catalog and EPSS scores to separate the vulnerabilities being exploited in the wild from the ones that merely score high.
25. Weight by asset criticality. A medium on the payment gateway outranks a high on a lab machine.
26. Group findings into remediation projects. Patch cycles, configuration baselines, decommissioning, and segmentation each fix whole classes of findings; a list sorted by score hides that structure.
27. Assign owners and dates. A finding without an owner is a finding that will appear again next quarter. Our guide to vulnerability remediation covers how to set fix deadlines you can defend and run the workflow to closure.

Remediation and retest

28. Rescan after remediation and compare. The retest confirms the fix, catches regressions, and produces the closure evidence auditors ask for. Trend the results quarter over quarter.
29. Handle exceptions formally. Findings that cannot be fixed get a documented risk acceptance with a compensating control and a review date, not silence.

Reporting: what the document needs to contain

30. Write for two readers. An executive summary with the exposure trend, the top risks, and the remediation plan, followed by the technical detail: scope, method, credentials used, coverage gaps, validated findings with evidence, and the retest results. Our vulnerability assessment report template lays out each section with a filled-in example finding.

For compliance, the report also needs to map to the requirement it evidences:

Framework	What the assessment evidences
PCI DSS	Internal vulnerability scans at least every three months and after significant change (Requirement 11.3.1); external scans by an Approved Scanning Vendor (11.3.2), which the assessment prepares you for but does not replace. We deliver both. See our PCI DSS penetration testing page.
SOC 2	Ongoing identification and monitoring of vulnerabilities (CC7.1) and the remediation process behind it. See SOC 2 penetration testing.
NYDFS 23 NYCRR 500	Automated scans and manual review at a risk-based frequency and after material changes (§500.5(a)(2)). See NYDFS penetration testing.
ISO 27001	Management of technical vulnerabilities (Annex A 8.8). See ISO 27001 penetration testing.
CMMC / NIST SP 800-171	Periodic vulnerability scanning and remediation (RA.L2-3.11.2 and 3.11.3). See CMMC Level 2 penetration testing.
HIPAA	Technical evaluation of safeguards under the current rule, and the six-month scanning cadence the proposed Security Rule update would require. See HIPAA penetration testing.

Vulnerability assessment vs penetration test

The assessment finds and validates known weaknesses across many systems. A penetration test takes the most important of them and proves what an attacker can do by chaining them, and finds the logic and configuration flaws no scanner detects. Both belong in a program: the assessment on a quarterly or monthly cadence, the penetration test annually and after significant change. Our overview of the types of network security assessment sets out which one answers which question, from a validated scan to a full attack test. For the internet-facing ranges, that means an external penetration test. Our guides to penetration testing vs vulnerability scanning and to vulnerability assessment and penetration testing explain how the two combine, and a penetration testing as a service program puts both on one calendar.

The steps most teams skip

If you run only part of this list, run these: authenticated scanning (step 15), reconciling discovery against the inventory (step 10), manual validation of the top findings (steps 20 and 21), and prioritizing by exploitation evidence rather than score (step 24). Together they turn a scanner export into an assessment, and they are the steps that separate a $1,500 validated scan from a free tool run.

Need the scan run, validated, and reported by analysts? Our vulnerability assessment and scanning service is $1,500 per scan for up to 250 devices, and a vulnerability management program runs it on a quarterly or monthly cadence. Scope an assessment and we will confirm ranges, credentials, and cadence.