Pentest or vulnerability scan?
What each one actually finds
Two different things, sometimes sold under the same name. Here is how to tell them apart, when you need each, and what auditors accept as evidence.
The confusion has a simple commercial cause: an automated scan report looks, at first glance, like a pentest report. It has findings, CVSS scores and recommendations. The difference shows up at the second question — "and what could an attacker do with this?" — which only one of the two documents can answer.
What a vulnerability scan actually is
A scanner compares what it sees — software versions, headers, open services, responses to standard requests — against a database of known vulnerabilities. It is fast, repeatable, cheap and can run automatically every week. It is the best existing tool for a single question: "have we fallen behind on patching somewhere?".
Its limit is not a quality problem but a matter of nature: a scanner recognises patterns. It does not understand what your application does, what a user role means in your business, or why a leftover test account with admin rights is worse than ten missing headers.
What a penetration test adds
A tester starts from the same data but asks questions a tool cannot: what happens if I swap the identifier in this request for another customer’s? Can I get from an ordinary user account to an administrator one? If I chain three "medium" findings, how far do I get? And above all: what does that mean in money or data for this particular company?
Side by side
| Criterion | Vulnerability scan | Penetration test |
|---|---|---|
| How it runs | Automated, signature-based | Manual, with tools as support |
| Duration | Minutes to hours | Days to weeks |
| Suitable frequency | Continuous, weekly or monthly | Annually and after major changes |
| Finds known vulnerabilities | Yes, that is its main role | Yes, but that is not where its value lies |
| Finds business logic flaws | No | Yes |
| Finds privilege escalation and chaining | Rarely and partially | Yes, that is the stated goal |
| False positive rate | High; requires manual triage | Low; every finding is verified |
| Audit evidence | Partial (continuous monitoring) | Full (effectiveness of measures) |
| Relative cost | Low, recurring | Higher, periodic |
What auditors accept
Compliance frameworks treat them differently, and it helps to know that before choosing. PCI DSS explicitly requires both: quarterly scanning (requirement 11.3) and an annual penetration test (11.4). ISO 27001 and SOC 2 do not name the method but require evaluating control effectiveness — which scanning alone rarely covers. NIS2 and the national legislation aligned to it require policies for assessing the effectiveness of measures, which is the same thing in other words.
How to use them together
The right question is not "which one" but "in what order". Automated scanning is the safety net that runs all the time and catches regressions cheaply. Manual testing is the periodic check on the things the net cannot catch. Anyone starting with a manual test on unpatched infrastructure is paying a specialist to read a scanner’s output.
- Recurring automated scanning across everything exposed, with triage and tracked remediation.
- A manual penetration test at least annually, on the systems holding data and revenue.
- An additional test after every major architecture change or significant release.
- A documented re-test after remediation — without it, neither scan nor pentest closes the loop.
Frequently asked questions
What is the difference between a pentest and a vulnerability scan?
A scan is automated and compares what it sees against a database of known vulnerabilities; it answers "what might be vulnerable?". A penetration test is manual and tries to actually exploit what it finds, chain findings and reach real data; it answers "what can an attacker do?". Scanning finds missing patches. A pentest additionally finds logic flaws, privilege escalation and access paths no tool recognises as a pattern.
Is an automated scan enough for compliance?
It depends on the framework. PCI DSS explicitly requires both quarterly scanning and an annual penetration test — one does not replace the other. ISO 27001 and SOC 2 do not mandate a method but require evaluating control effectiveness, which auditors rarely consider covered by scanning alone. For NIS2 and the national legislation aligned to it, the requirement to assess effectiveness leads to the same conclusion.
How do I spot a "pentest" that is really a scan?
Three signs are enough. Duration: a serious test on a real application does not end in a day. The report: if every finding has the same generic structure and the remediation text looks copied, it came from a tool. And the proof: a manual test shows reproducible exploitation steps and explains the impact on your business, not just a CVSS score and a CVE reference.
Where do I start on a limited budget?
With recurring automated scanning across everything exposed to the internet, plus fixing what it finds. It costs little, removes the obvious categories and prepares the ground. Then, with the remaining budget, commission a manual test focused on the system holding the data or the revenue — a small scope tested deeply says more than a large scope touched lightly.
How often should each be done?
Scanning runs continuously or at least monthly, and in regulated environments quarterly is the imposed minimum. A penetration test is run at least annually and after any major architecture change, migration or significant release. For service providers under PCI DSS, segmentation testing rises to every six months.
Related guides
- What a pentest costs — what drives the price, how effort is estimated, and what makes two quotes comparable.
- DORA & TLPT — digital operational resilience in finance and threat-led penetration testing.
- ISO 27001 & SOC 2 — which controls require technical testing and what evidence the auditor accepts.
- Moldova’s Law 48/2023 — the national cybersecurity framework: who is in scope and what obligations it brings.
- OWASP Top 10 — the ten web risk categories, explained with examples and what gets tested in each.
- PCI DSS 4.0 — requirements 11.3 and 11.4, segmentation testing, and what it means for payment processors.
- How to prepare for a pentest — scope, access, rules of engagement and everything settled before day one.
This material is informational. Exact testing requirements depend on the compliance framework applicable to your organisation.
Not sure which one you need?
Book a free consultation: we look at your scope and tell you what scanning solves and what needs a human.