Customer-required testing
Clarify what a customer or prospect actually requested.
Read nextDecision guide
A vulnerability scan automatically checks configured systems for possible weaknesses. In a penetration test, a tester investigates the authorized systems to determine whether weaknesses, application behavior, roles, or connected issues can be exploited in practice.
Scanning can support discovery and coverage inside a penetration test, but a scan is not automatically a substitute for a pentest. Some requirements specifically name one activity.
Primary references: NIST SP 800-115
Published by Trespass Security
Comparison
| Consideration | Vulnerability scan | Penetration test |
|---|---|---|
| Purpose | Identify potential weaknesses across the configured scan target using a scanning system. | Exercise an authorized attack surface to investigate exploitable behavior, control failure, and relevant attack paths. |
| Automation | Automation is the primary discovery mechanism. | Tools may support discovery and evidence collection, while the tester directs investigation and judgment. |
| Human investigation | Review may tune or interpret scanner output. | Investigation adapts to system behavior, application context, roles, workflows, and observed conditions. |
| Validation | Potential issues may remain based on signatures, versions, or responses. | Findings are investigated within the authorized scope to establish observed behavior and relevant impact. |
| Attack paths | Typically evaluates individual detectable conditions. | May combine conditions or traverse application and privilege paths where authorized. |
| Business logic | Limited ability to reason about intended workflows and abuse cases. | Can examine application-specific workflows, role boundaries, state changes, and misuse cases. |
| Authorization | Still requires ownership, permission, target control, and safe configuration. | Requires explicit scope, written authorization, Rules of Engagement, permitted techniques, contacts, and stop conditions. |
| Output | Scanner results and remediation-oriented issue data, depending on the service. | Engagement scope, methodology, limitations, investigated findings, evidence, risk explanation, and remediation direction. |
| Retesting | Targets may be rescanned to observe whether detectable conditions remain. | Remediated findings may be reassessed within a defined retest path and recorded with relevant context. |
| Common situation | Routine vulnerability management, broad discovery, or a requirement that explicitly names scanning. | Customer, assurance, contract, or PCI DSS requirements that call for authorized adversarial testing and investigated findings. |
Where scanning helps
Scanners can check many systems repeatedly, find known issues, review configurations, and support an ongoing vulnerability-management program.
Penetration testers also use tools. The difference is the purpose of the work, the tester’s investigation, the required authorization, and the final report.
Named requirements matter
If the request names a penetration test, scan, ASV scan, vulnerability assessment, or another activity, preserve that language. Ask what systems, evidence, timing, and standard-specific conditions apply.
Review the PCI DSS pathPCI distinction: external vulnerability scanning by a PCI SSC Approved Scanning Vendor is a specific activity separate from PCI DSS penetration testing. Do not assume one satisfies the other.
If the wording is vague
Next step
Tell us who asked, what systems may be involved, what evidence they named, and whether there is a deadline. We’ll help you work out what to do next.