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.

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, 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 configuration assessment covers them, 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.

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.

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. 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 guides to penetration testing vs vulnerability scanning and to VAPT 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 flat per scan, with quarterly and monthly programs available. Scope an assessment and we will confirm ranges, credentials, and cadence.