Penetration test vs vulnerability scan: which do you need?
A vulnerability scan identifies potential weaknesses using automated checks. A penetration test examines whether weaknesses can be used within an agreed scope and interprets the resulting risk. Scanning can be part of a pentest; buying a scan report alone does not establish that the broader testing occurred.
What is the distinction based on?
NIST SP 800-115 distinguishes vulnerability scanning from penetration testing and describes how techniques can be combined. It is a foundational guide from 2008, used here for the distinction—not as a statement of current compliance requirements.
Source: NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008)
Choose the question you need answered
Use these as proposed procurement questions, rather than rigid rules about what every service must contain.
On a small screen, scroll the table sideways to see every column.
| Your question | What to ask a supplier for |
|---|---|
| Which known issues should we investigate across an inventory? | Scanning coverage, credentials where appropriate, validation and triage process |
| Could weaknesses combine into a meaningful impact? | A scoped assessment with validation, analysis and documented boundaries |
| Can engineering act on the result? | Clear affected assets, evidence and remediation guidance |
| Does a customer accept this deliverable? | Their written requirement and confirmation of the proposed report type |
Example: the same portal, different deliverables
A fictional buyer receives two offers. One covers recurring automated scans and an issue dashboard. The other covers an agreed assessment of the portal’s roles and workflows, with a report and a follow-up discussion. Neither is automatically the correct purchase: the buyer must match the output to the problem.
If the team wants a recurring view of potential issues, ask about scan operation and triage. If it wants an assessment of important application behavior, describe that behavior and ask how it is covered. Do not judge the work by page count in the final PDF.
Can a clean report prove the application is secure?
Do not use a report as a blanket guarantee. Read its scope, dates, environment and limitations before relying on a conclusion. A useful acceptance question is: “What did you examine, and what remains outside this engagement?”
For a buyer, the practical next step is to write the desired deliverable into the scope. Ask the provider to explain how automated checks, human analysis and validation contribute to that output. This guide does not rank automated and human services without examining their specific scope.