Contents
In 30 seconds
- A scan compares what it sees with known vulnerabilities; a penetration test tries to exploit them and reach data — it is a method of assurance, not primarily of finding vulnerabilities 2.
- Business logic flaws cannot be detected by a vulnerability scanner — OWASP’s testing guide says so 1.
- PCI DSS requires both: scans every three months (11.3) and a pentest every 12 months (11.4) 3.
- DORA, the NIS2 regulation for digital providers and the NBM also name both methods 679.
- PCI scans
- every 3 months 3
- PCI pentest
- every 12 months 3
- Business logic
- manual only 1
- NBM pentest
- at least every 3 years 9
What a vulnerability scan actually is
A scanner compares what it sees — software versions, headers, open services, responses to standard requests — with a database of known vulnerabilities. It is fast, repeatable and can run automatically every week. It is the best tool for one question: “have we fallen behind on updates anywhere?”.
Its limit is not one of quality but of nature: a scanner recognises patterns. It does not know what your application does, what a user role means in your business or who owns an invoice. That is why PCI DSS judges an external scan by a simple threshold: it passes if no component has vulnerabilities with a CVSS score of 4.0 or higher 4.
What a penetration test adds
The PCI SSC guidance describes a penetration test as “a manual process” that may also use scans or other automated tools 5. The tester starts from the same data but asks the questions a tool cannot: what happens if I swap the identifier in the request for another customer’s? Can I get from an ordinary account to an administrator? If I chain three “medium” findings, how far do I get?
The NCSC, the UK’s cyber security agency, says a test should be seen as a way of gaining assurance that the system holds, not as the primary method of finding vulnerabilities 2. In other words: the scan finds, the test proves.
Side by side
| Criterion | Scan | Penetration test |
|---|---|---|
| How it runs | Automatically, on signatures | Manually, with tools in support 5 |
| Required frequency | PCI: every 3 months and after changes 3 | PCI: every 12 months and after changes 3 |
| Known vulnerabilities | Yes — its main job | Yes, but that is not where its value lies |
| Business logic, access between users | No 1 | Yes — its stated purpose |
| Chaining findings | No | Yes |
| False positives (from our practice) | Frequent; need triage | Rare; every finding is verified |
| What it proves | That you monitor continuously | That your controls actually work 2 |
What regulations require
Compliance frameworks treat them differently, but none of those below is satisfied by scanning alone:
| Framework | Scanning | Penetration testing |
|---|---|---|
| PCI DSS v4.0.1 | Internal and external ASV, every 3 months (11.3) 3 | Internal and external, every 12 months (11.4) 3 |
| NIS2, Reg. 2024/2690 | At planned intervals (6.10.2(b)) 6 | Security tests based on risk (6.5); recital 15 names penetration tests 6 |
| DORA | In the Art. 25 list of tests 7 | In the same list; yearly on critical systems (Art. 24(6)) 7 |
| SOC 2 | Periodically and after changes (CC7.1) 8 | One of the evaluations named under CC4.1 8 |
| NBM ICT regulation | Proportionate to risk (point 33.1) 9 | On critical systems, at least every 3 years (point 33.2) 9 |
Scan, pentest or both?
Choose your goal and your framework; the tool combines what the goal needs with what the regulation requires 36789.
What do you need? Answer two questions
Indicative, based on the requirements cited in this guide. Your answers stay in the browser.
Recurring scanning
Penetration test
Both: scanning and a penetration test
- Recurring scans of everything exposed, at least monthly, with triage and remediation tracked: the cheapest way to catch a missing patch.
- Manual penetration test with an account per role: access control (A01) and business logic (A06) are not found by scanning.
- Penetration test before launch, then recurring scans after it as a safety net for regressions.
- A targeted test of the attack path used, showing the breach is closed, plus a scan of the whole exposed perimeter.
- From our practice: without a specific framework, auditors ask for proof that controls work — a test report with scope, method and retest, plus the scan history.
- PCI DSS: internal and ASV scans every three months (11.3), internal and external pentests every 12 months (11.4). Neither replaces the other.
- NIS2: assessing the effectiveness of measures (Art. 21(2)(f)); for digital providers, Reg. 2024/2690 requires scans at planned intervals (6.10.2(b)) and security tests based on risk assessment (6.5).
- DORA: a testing programme with scans and penetration tests (Art. 25), at least yearly on systems supporting critical functions (Art. 24(6)).
- SOC 2: periodic scans and after changes (point of focus under CC7.1); the pentest is one of the evaluations named under CC4.1. ISO 27001 leaves the choice to your risk assessment.
- NBM: vulnerability scans and penetration tests proportionate to risk (point 33.1); on critical systems, a pentest at least every 3 years (point 33.2).
How to use them together
The right question is not “which one” but “in what order”. Scanning is the net that runs all the time and catches regressions cheaply; the manual test periodically checks what the net cannot catch. From our practice: whoever starts with a manual test on unpatched infrastructure pays a specialist to read a scanner’s output.
- Recurring scans
Of everything exposed, with triage and remediation tracked.
- Periodic penetration test
At least yearly, on the systems holding data and revenue, and after major changes.
- Documented retest
Without it, neither scan nor test closes the loop; PCI DSS requires it explicitly (11.4.4) 3.
How to spot a “pentest” that is really a scan
From our practice, three signs are enough:
- Duration: a serious test of a real application does not finish in a day.
- The report: if every finding has the same generic structure and the fix looks copied, it came from a tool.
- The evidence: a manual test shows reproducible exploitation steps and the impact on your business, not just a CVSS score.
Frequently asked questions
What is the difference between a pentest and a vulnerability scan?
Is a scan enough for compliance?
How often should each be done?
Where do I start on a limited budget?
What does it mean for an ASV scan to “pass”?
Sources
Every statement about a law or standard links to its official source. Consulted on the date shown.
- OWASP WSTG — introduction to business logic testingowasp.org · accessed 23 October 2026
- NCSC (UK) — Penetration testingncsc.gov.uk · accessed 23 October 2026
- PCI DSS v4.0.1 — SAQ D for Service Providers, r2 (text of requirements 11.3 and 11.4)pcisecuritystandards.org · accessed 23 October 2026
- ASV Program Guide v4.0 r2pcisecuritystandards.org · accessed 23 October 2026
- PCI SSC — Penetration Testing Guidance v1.1 (2017)pcisecuritystandards.org · accessed 23 October 2026
- Implementing Regulation (EU) 2024/2690 (NIS2, technical requirements)eur-lex.europa.eu · accessed 23 October 2026
- Regulation (EU) 2022/2554 (DORA)eur-lex.europa.eu · accessed 23 October 2026
- AICPA — 2017 Trust Services Criteria (revised points of focus, 2022)aicpa-cima.com · accessed 23 October 2026
- NBM — Regulation on minimum requirements for ICT risk management (Decision No. 29/2025)bnm.md · accessed 23 October 2026
- OWASP Top 10:2025owasp.org · accessed 23 October 2026
- A01:2025 Broken Access Controlowasp.org · accessed 23 October 2026
About the authors
The guides are written by the team that does the testing, not a marketing department. We update them when the law, the standard or what we see in testing changes.