Vulnerability Scanning vs. Penetration Testing: What Each Finds and How Often

Start with the answer: run vulnerability scans often, because they find known weaknesses quickly and cheaply, and commission penetration tests periodically, because only a person can show whether those weaknesses combine into real access. They are different tools. Buying one and calling it the other leaves a gap, and auditors, insurers and clients usually notice.

What a vulnerability scan does

A vulnerability scanner compares your systems with a database of known issues. It checks software versions, missing patches, insecure configurations, exposed services, weak protocols and default settings. Scans can be run from outside your network to see what an internet attacker sees, and from inside, often with credentials, to see missing patches and misconfigurations that outside scans cannot reach.

Scans are good at breadth and consistency. They cover thousands of assets, repeat on a schedule, and give you a trend. They are weaker at depth. A scanner reports a finding, but it does not usually tell you whether the finding is reachable, whether the data behind it matters or whether two small findings together open a path. Expect false positives that need triage, and false negatives for anything the tool does not know about, such as custom application logic.

What a penetration test does

A penetration test is a planned exercise in which skilled testers, with written authorization, try to achieve defined goals, such as reaching customer records, taking over an administrator account or moving from a phished workstation to a server. NIST SP 800-115, the federal technical guide to security testing, describes penetration testing as security testing in which assessors mimic real-world attacks to find ways to circumvent the security features of an application, system or network, and it treats vulnerability scanning as a separate technique that often feeds the test.

Testers find what scanners miss: broken access control, flawed business logic, chained weaknesses, weak passwords and reused credentials, exposed secrets and trust relationships between systems. They also show impact in terms a business can act on, and they test people and process: whether your logging notices, whether your team responds and whether segmentation holds. The price of that depth is time and a narrower scope.

Side by side

• Method: scanning is automated and repeatable; testing is manual, guided by tools and judgment.
• Scope: scans cover many assets thinly; tests cover chosen targets deeply.
• Output: scans give a long list ranked by severity; tests give a story of how an attacker gets in, with evidence and fixes.
• Skill: scans need someone to configure and triage them; tests need experienced testers and written authorization.
• Risk: scans are usually safe but can disrupt fragile systems; tests need rules of engagement and stop conditions.

How often

No single schedule fits everyone. Your regulations, contracts, insurer and risk decide. A defensible starting point for most organizations follows.

• Scanning: continuous or at least monthly for internet-facing assets, and at least monthly or quarterly for internal ones, plus a scan after significant changes. Patch on a schedule based on severity and exposure, and rescan to confirm the fix.
• Penetration testing: at least once a year for important systems, and after major changes such as a new application, a network redesign or a merger. Test sooner if you handle sensitive data or have had an incident.
• Authenticated and unauthenticated scans both. They answer different questions.

PCI DSS v4.0, the payment card industry standard, shows how a formal framework handles it. Requirement 11, Test Security of Systems and Networks Regularly, includes internal and external vulnerability scans at least once every three months with rescans until issues are resolved, external scans by an approved scanning vendor, and penetration testing at least once every twelve months and after significant changes, covering both the network and application layers and including segmentation checks where segmentation is used to reduce scope. Read the current text from the PCI Security Standards Council for the exact wording and for how it applies to your merchant or service-provider level. Other frameworks, including HIPAA risk analysis expectations, SOC 2 and bank examination guidance, set their own expectations.

Common mistakes

• Treating a scan report as a penetration test. A relabeled scan misses chained and logic flaws.
• Testing once a year and never fixing the findings. Track remediation with owners and dates, then retest.
• Scanning only the assets you remember. Keep an asset inventory, including cloud accounts and forgotten domains.
• Scoping the test so narrowly that it proves nothing, or so broadly that it cannot be done.
• Skipping written authorization. Always have it, and confirm cloud and hosting providers allow the planned activity.

Making both useful

Set severity targets, such as critical findings fixed within a stated number of days, and report against them. Feed penetration-test findings into your scanning rules so the same flaw is caught next time. Share results with leadership in business terms. And choose testers on method and reporting quality, not on the length of the tool list.

A short checklist

Asset inventory, authenticated and external scans on a schedule, remediation with deadlines, rescans, an annual penetration test and one after major change, written authorization and scope, a retest after fixes, and evidence kept for your auditor. Our cybersecurity team can help you put this in place. Start with our Cybersecurity service.

Sources

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment
• PCI Security Standards Council, Document Library (PCI DSS v4.0, Requirement 11)

This article is general information, not legal or compliance advice. Rules and product behavior differ by sector, contract and version; confirm details with your counsel, auditor and vendor documentation. Last reviewed November 9, 2026.

Keep reading

Next · SecurityVendor Risk for Small Medical Groups: Business Associates and SOC 2 ReportsYour billing company, cloud host, answering service and software vendors may all handle patient information. HIPAA treats many of them as business associates. A signed agreement is required, and a SOC 2 report can show how a vendor runs its controls, if you know how to read it.7 min read

• What a Code and Endpoint Security Review Finds in the First 24 Hours7 min
• Before Anyone Scans Your Website: Verification and Written Authorization7 min