Breadth over depth is the bargain every vulnerability scan makes.

A scanner probes each target, notes software versions and settings, and compares them with known vulnerabilities. It covers many systems quickly and can run on a schedule. Its output is a list of likely problems, some of which turn out to be false alarms.

Scanning is the cheapest way to keep watch over a growing estate, and most frameworks expect it in some form: ISO 27001's control on technical vulnerabilities, SOC 2 monitoring criteria, and payment-card rules that set scan frequency. But a scan only knows what is in its database. It cannot tell that a valid user can read another user's records, and it cannot judge whether a finding matters in your setup. An authenticated scan, logged in to the host, sees far more than an unauthenticated one looking from outside. Reading results well, and removing false positives, is where the real work sits.

Vulnerability management procedure

The scan schedule, the targets, and the fix-by times for each severity.

PCI DSS Requirement 11

Internal scans, and external scans by an Approved Scanning Vendor, at set intervals.

Audit evidence

Dated scan reports and tickets that show findings were followed up.

Penetration testing

A scan reports likely weaknesses automatically. A penetration test has a person exploit them to show real impact.

VAPT

Uses scanning as one input, then adds manual validation and exploitation. A scan export is not a VAPT report.

CVSS score

The severity rating a scanner often attaches to a finding. The score is not the scan, and it ignores your own context.

• Keep an asset inventory so the scanner covers everything you own, including cloud resources.
• Run authenticated scans on internal hosts where you can, and external scans of every internet-facing address.
• Triage results: confirm, rank by real exposure, and mark false positives with a reason.
• Feed confirmed findings into remediation with owners and dates, then rescan.

• GuideVulnerability managementScanning, ranking and tracking weaknesses until they are fixed.
• GuideTechnical vulnerability managementFinding, ranking and fixing weaknesses on a schedule.
• GuideThe HIPAA security risk analysisThe required analysis, how to run it, and what to keep.

Sources: NIST SP 800-115 (target identification and analysis techniques, vulnerability scanning); PCI DSS v4.0.1, requirement 11.3, and PCI SSC Approved Scanning Vendor program guide; ISO/IEC 27001:2022 Annex A control 8.8 (described, not quoted).