Definitions: vulnerability assessment and penetration testing
NIST's glossary gives useful anchors. Citing CNSSI 4009-2022, it defines a vulnerability assessment as a systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data to predict how well proposed measures will work, and confirm that measures are adequate after implementation. Citing NIST SP 800-115, it defines penetration testing as security testing in which evaluators mimic real-world attacks to identify ways to circumvent the security features of an application, system or network.
In practice, a vulnerability scan is the automated part of a vulnerability assessment: a tool compares what it finds with known vulnerabilities and misconfigurations. A penetration test uses tools too, but a person decides what to try next, confirms which findings are real, and shows what an attacker could reach.
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment (September 2008), helps organizations plan and conduct technical security tests and examinations, analyze findings and develop mitigation strategies.
Penetration testing vs vulnerability scanning, side by side
The differences show up in purpose, method, depth and what you receive at the end.
| Aspect | Vulnerability scanning | Penetration testing |
|---|---|---|
| Goal | Find known weaknesses across as many systems as possible | Show whether and how security can be defeated within a defined scope |
| Method | Automated tools, run on a schedule or continuously | People using tools and judgment under agreed rules of engagement |
| Depth | Broad: one check for each known issue | Deep: follows promising paths and chains findings together |
| False positives | Possible, so findings need triage | Fewer, because testers try to confirm each finding |
| Cadence under PCI DSS | At least every three months, and after significant changes | At least every 12 months, and after significant changes |
| Output | A list of findings with severity ratings | A report with attack paths, evidence and specific fixes |
| Who performs it | Your team or a provider; for PCI DSS external scans every three months, a listed ASV | Qualified internal or external testers; PCI DSS also requires organizational independence |
What vulnerability scans do well
Scans are the right tool for breadth and frequency. They check the systems in scope on a schedule, catch regressions after a change, and confirm that a fix worked. That makes them the backbone of vulnerability management between penetration tests.
Authenticated scans see more than unauthenticated ones, because the scanner logs in and inspects installed software and settings. PCI DSS requirement 11.3.1.2 calls for internal scans to use authenticated scanning: systems that can't accept credentials are documented, scanner accounts have sufficient privileges, and scanner accounts that allow interactive login are managed under requirement 8.2.2.
Scanning has limits. A scanner checks for issues it already knows about. It can't judge whether one customer can read another customer's data, or whether a business workflow can be abused in ways its designers never intended.
What penetration tests add
A penetration test answers questions a scan can't. Testers look at how an application behaves, not only at which versions it runs, so they find business logic flaws and broken authorization.
Authorization flaws are a good example. The OWASP API Security Top 10 (2023) lists Broken Object Level Authorization first, as API1:2023, and notes that object-level authorization checks should be considered in every function that accesses a data source using an ID from the user. Confirming that usually takes a tester with two accounts trying to reach each other's data.
Testers also chain findings. Several low-severity issues can combine into a path to sensitive data, and a good report shows that path so you can break it at the cheapest point.
For card data environments, PCI DSS requirement 11.4.1 expects a defined penetration testing methodology that covers the whole cardholder data environment perimeter and critical systems, tests from inside and outside the network, validates segmentation and scope-reduction controls, and includes both application-layer and network-layer testing.
What frameworks ask for
Frameworks treat scanning and penetration testing as separate activities with separate expectations. Here is what each one says.
PCI DSS v4.0.1
Requirement 11.3.1 calls for internal vulnerability scans at least once every three months, with high-risk and critical vulnerabilities resolved and rescans that confirm it, performed by qualified personnel with organizational independence. Requirement 11.3.1.3 adds internal scans after any significant change.
Requirement 11.3.2 calls for external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, with rescans as needed until the ASV Program Guide's requirements for a passing scan are met. Requirement 11.3.2.1 adds external scans after significant changes, which qualified personnel can run without being an ASV.
Requirements 11.4.2 and 11.4.3 call for internal and external penetration tests at least once every 12 months and after any significant infrastructure or application upgrade or change, by a qualified internal resource or qualified external third party with organizational independence. The tester isn't required to be a QSA or an ASV.
SOC 2
The Trust Services Criteria set no fixed frequency for either activity. A point of focus under CC7.1 describes infrastructure and software vulnerability scans run periodically and after significant changes, with timely remediation. A point of focus under CC4.1 lists penetration testing and vulnerability scans among the evaluations management can use. Points of focus are guidance, so your risk assessment and your customers usually settle the schedule.
HIPAA Security Rule
The Security Rule in force doesn't name vulnerability scanning or penetration testing. It requires a risk analysis and a periodic technical and nontechnical evaluation of how well your security policies and procedures meet the rule (45 CFR 164.308).
HHS proposed changes in January 2025 that would require vulnerability scans at least once every six months and penetration testing at least once every 12 months, or more often if your risk analysis calls for it. As of September 27, 2026, the Federal Register lists only the proposed rule; it has not been finalized or withdrawn.
ASV scans are their own program
An Approved Scanning Vendor is an organization with a set of security services and tools, the ASV scan solution, that PCI SSC recognizes for the external vulnerability scans requirement 11.3.2 calls for. PCI SSC publishes the list of approved vendors on its website.
Approval means only that the vendor met PCI SSC's requirements to perform PCI scanning; PCI SSC says it doesn't endorse ASVs or their business practices. When you compare vendors, look at scan scheduling, support, and how each one handles findings you believe are false positives.
A scanner you run yourself, however capable, doesn't meet the requirement in 11.3.2 for ASV scans every three months, and an ASV scan isn't a penetration test. Plan and budget for both.
Free government scanning options
CISA offers its Cyber Hygiene services at no cost to eligible organizations: U.S.-based federal, state, local, tribal and territorial governments, and public and private sector critical infrastructure organizations. The vulnerability scanning service continuously assesses internet-accessible assets and sends weekly reports. The web application scanning service looks for vulnerabilities in publicly accessible web applications, with monthly reports.
Enrollment details are on CISA's Cyber Hygiene page. These services add useful outside visibility, but for PCI DSS, the external scans every three months still have to come from a PCI SSC-listed ASV, and neither kind of scan replaces a penetration test.
A program that uses both
The two activities reinforce each other. Scans run on a schedule and after changes, penetration tests go deeper at planned points, and any test finding a scanner could have caught becomes a new scanning check. These habits keep the loop working:
- Keep an inventory of internet-facing and internal assets, so both scans and tests work from a complete target list.
- Run authenticated internal scans and external scans at least as often as your strictest requirement, and after significant changes.
- Rank findings by risk, set remediation timelines you can meet, and confirm fixes with rescans.
- Time penetration tests around major releases, new integrations and infrastructure changes, not only a calendar date.
- Give testers the user roles and test accounts they need to find authorization flaws.
- Retest after fixes, and keep scan reports, test reports and retest results as evidence.