What is the difference between a vulnerability scan and a penetration test?
A vulnerability scan is an automated comparison of your systems against a database of known weaknesses; a penetration test is a manual, goal-driven attempt by people to break in and prove impact. The scan answers "which known CVEs and misconfigurations exist?", the pentest answers "what can an attacker actually do with them?". Both are useful; they are not interchangeable, and a scan sold as a pentest leaves exactly the class of bugs that cause breaches untested: broken authorisation, business-logic abuse and chained weaknesses that no signature describes.
A scan (Nessus, Nuclei, OpenVAS, cloud-native scanners) compares versions, configurations and signatures against a database and produces a list. It is fast, repeatable and cheap — and it also produces false positives and misses anything that requires understanding the application.
A penetration test is run by people with a goal — customer data, admin access, the internal network — who combine findings, abuse business logic and prove impact. It is slower and costs more, and it finds the things that make the news: an IDOR that exposes every invoice, a password reset that can be hijacked, a role check missing on one endpoint. Exploitation of vulnerabilities as the initial way into a breach almost tripled year on year in the Verizon DBIR 2024 — precisely the path a scan lists but only a test proves.
Pentest vs vulnerability scan: which do you need?
The short answer: you need both, at different frequencies. Scans are hygiene — cheap, automated, monthly or continuous. A penetration test is an event — manual, scoped, annual or before a milestone. The table shows where they differ; the schedule section below turns it into a calendar. PCI DSS v4.0 makes the same split explicit, requiring recurring vulnerability scans and a separate periodic penetration test (PCI SSC, 2022).
| Criterion | Vulnerability scan | Penetration test |
|---|---|---|
| Who does it | A tool; a person reviews the output | Security engineers with a goal |
| What it finds | Known CVEs, missing patches, misconfigurations | Logic flaws, broken access control, chained attacks, plus known issues |
| Depth | Signature matching, no exploitation | Manual exploitation with proof of impact |
| Duration | Minutes to hours | One to three weeks for a typical web application |
| False positives | Common; need triage | Rare; every finding is reproduced |
| Frequency | Continuous or monthly | Annually and after major releases |
| Output | List with CVSS scores | Report with reproduction steps, business severity, fixes, retest |
What does a real pentest report contain?
A real penetration test report proves each finding and tells your engineers how to fix it in your framework. It states the scope, dates and methodology, lists every finding with reproduction steps and evidence, rates severity for your business rather than by CVSS alone, and ends with a retest. If a proposal has no manual phase, no reproduction steps and takes two days for a large application, it is a scan with a cover page. Methodology matters because it defines coverage: the OWASP Web Security Testing Guide v4.2 alone lists well over a hundred test cases across identity, authorisation, session, input and business logic (OWASP, 2020).
- Scope, dates, methodology (OWASP WSTG, PTES) and what was not tested.
- Each finding with steps to reproduce, evidence (requests, screenshots), CVSS score and a business-adjusted severity.
- A fix that names your framework, not generic advice.
- An executive summary that a CTO or a customer can read in five minutes.
- A retest and a letter of attestation once fixes are verified.
How often should you scan and how often should you test?
Scan continuously and monthly; test manually once a year and after every major release or before a milestone such as a launch, a large customer questionnaire or a compliance audit. For a product team of ten to fifty engineers this is a few days of scanning hygiene per month and one focused test per year. The cost of skipping it is not abstract: the global average cost of a data breach reached USD 4.88 million in 2024, and breaches took 258 days on average to identify and contain (IBM, 2024).
- Continuous: dependency, container and secret scanning in CI; DAST on staging — see DevSecOps.
- Monthly: a vulnerability scan of the external perimeter and cloud configuration, reviewed by a person.
- Annually and after major releases: a manual penetration test of the application, its APIs and — if you have one — its AI features.
- Before a milestone: a launch, a large customer questionnaire, a compliance audit.
The alternative is learning about the IDOR from a customer. How we run penetration tests.
Who needs a penetration test and who is fine with scans?
You need a manual penetration test if your application handles other people's money, personal data or credentials, exposes an API to third parties, or has to answer a customer or regulator questionnaire. Scans alone are acceptable for internal tools with no sensitive data and for early prototypes that nobody outside the team can reach. Two external drivers make the decision for most companies: the human element was present in 68% of breaches in the DBIR 2024, so authorisation and workflow bugs matter as much as patches (Verizon, 2024); and under GDPR Article 32 controllers must regularly test and evaluate the effectiveness of their security measures, which auditors read as more than an automated scan (EU, 2016).