A vulnerability scan is an automated check that lists known weaknesses across your systems. A penetration test is a person trying to exploit those weaknesses, and the ones a scanner can't see, to show what an attacker could actually reach. The PCI Security Standards Council puts it in one line each: a scan aims to "identify, rank, and report vulnerabilities", while a penetration test aims to "identify ways to exploit vulnerabilities to circumvent or defeat the security features of system components" [1].
Most organisations need both, at different intervals. The scan runs every month or quarter and keeps the obvious gaps closed. The pen test runs once a year or after a big change and tells you whether the scanning, patching and design are holding up.
The one-line difference
A scanner asks "is anything here on the list of known problems?" A tester asks "what can I do with what I find?"
That second question is why the UK government's Service Manual says penetration tests "proactively attack your systems to find weaknesses and help you understand how easy they are to exploit", and tells teams to run both kinds of testing "frequently as you build, not as a one-off check" [2].
What a vulnerability scan does (and what it misses)
A scanner compares what it can see (open ports, service banners, software versions, web responses) against a database of known vulnerabilities, then ranks each match, usually by CVSS score. It's fast. PCI guidance describes a scan as taking "several seconds to several minutes per scanned host" [1]. That speed is the point: you can scan your whole estate every week and catch a forgotten test server or an unpatched VPN appliance before someone else does.
The limits come from the same design. NIST's testing guide says network scanning "generally covers surface vulnerabilities, and is unable to address the overall risk level of a scanned network", and that scanners rely on signatures, so they only recognise problems someone has already written a check for [3].
Authenticated vs unauthenticated scans
An unauthenticated scan looks at a system from outside, with no login. It shows roughly what an anonymous attacker would see, and it misses everything behind the login.
An authenticated (credentialed) scan logs in with an account you provide. Tenable, which makes the Nessus scanner, says credentialed scans "can perform a wider variety of checks than non-credentialed scans, which can result in more accurate scan results", and recommends running them whenever possible [4]. Logged in, the scanner can read installed software versions and missing patches directly instead of guessing from a banner.
If a vendor quotes you for a scan, ask which kind. An unauthenticated external scan of a web app with user accounts covers the login page and very little else.
False positives and noise
NIST warns that vulnerability scanners "can have a high false positive error rate (i.e., reporting vulnerabilities when none exist)" and that someone with networking and OS expertise should interpret the results [3]. Scanners also produce false negatives: they miss real problems that no signature matches [3].
In practice that means a raw scan report is a to-do list someone still has to triage. A 200-line PDF full of "medium" findings on TLS settings can bury the one outdated plugin that matters. NIST also says assessors should "not simply accept the risk levels assigned by vulnerability scanners", because the real risk depends on how the system is used [3]. Its example: a cleartext-password FTP flag matters much less on an anonymous public download server that has no passwords at all.
What a penetration test does
The UK's National Cyber Security Centre (NCSC) defines penetration testing as "a method for gaining assurance in the security of an IT system by attempting to breach some or all of that system's security, using the same tools and techniques as an adversary might" [5].
Testers do use scanners. PCI guidance calls a pen test "a manual process that may include the use of vulnerability scanning or other automated tools, resulting in a comprehensive report" [1]. The scan is where a tester starts. Most of the effort goes into the parts a scanner can't do.
Manual exploitation and chaining
A tester confirms whether a flagged issue can really be exploited, which removes false positives. Then they combine findings. A low-severity information leak, a weak password reset flow and an over-permissive internal API might each score "low" or "medium" on their own. Chained, they can add up to account takeover. Scanners rate findings one at a time, so they don't see the chain.
PCI guidance lists the kind of detail a pen test report should give for each issue: the specific risk, "including specific methods how and to what extent it may be exploited", with examples such as SQL injection, privilege escalation and cross-site scripting [1].
Business-logic flaws scanners cannot see
OWASP's Web Security Testing Guide says automated tools "are built for applications in general, not for your custom code and business rules", and that "the most serious issues are frequently intertwined with business logic and custom design" [6].
Business logic means the rules of your own application. Can a user on the free plan call the paid-plan API endpoint? Can a customer change the order ID in a request and see someone else's invoice? Can a discount code be applied twice by sending two requests at once? To a scanner, each of those requests looks normal. You only spot the problem if you know what the application is supposed to allow, and that takes a person with the scope document open.
The UK government's Service Manual gives a non-technical example of the same idea: get a contact centre to change a user's email address, then use the forgotten-password function to take over the account [2]. No scanner tests your contact centre.
Side-by-side comparison
Vulnerability scan vs penetration test at a glance. Sources [1], [3] and [7].
Vulnerability scan | Penetration test | |
|---|---|---|
What it answers | Which known weaknesses are present? | What could an attacker actually do here? |
How it works | Automated tools matching signatures, with some manual verification [1] | Mostly manual testing, using automated tools as a starting point [1] |
Depth | Wide and shallow: every host, known issues only | Narrow and deep: agreed scope, exploits and chains findings |
Finds business-logic flaws | Rarely [6] | Yes, if they're in scope |
False positives | Common; results need triage [3] | Findings are confirmed by the tester |
Duration | Seconds to minutes per host [1] | Days or weeks, depending on scope [1] |
Main cost driver | Number of IPs, hosts or apps, and how often you scan | Tester-days needed for the scope |
Typical frequency | Monthly or at least quarterly; PCI DSS requires quarterly [1][7] | Yearly and after significant changes [1][7] |
Output | Ranked list of known issues with CVSS scores [1] | Report of verified issues, how they were exploited, business risk and fixes [1][5] |
Compliance fit | PCI DSS 11.3, Cyber Essentials Plus audits use scans [7][9] | PCI DSS 11.4, common audit evidence for ISO 27001 control 8.8 [7][8] |
For prices, our penetration testing cost guide collects published 2026 figures for both. In short, a scan costs hundreds, a manual test usually costs thousands, and any "pen test" priced like a scan is almost certainly a scan.
Vulnerability assessment: where it fits between the two
People use "vulnerability assessment" in two ways, and that causes a lot of the confusion when you compare quotes.
Sometimes it just means a scan with a nicer report. More usefully, it means a scan plus a person who removes the false positives, rates each finding against how the system is actually used, and writes a prioritised fix list. That is the triage step NIST says scans need [3]. A real assessment covers the full estate like a scan does. It still stops short of exploitation: nobody tries to break in, chain findings or test business logic.
The UK Service Manual treats assessments and pen tests as a pair: assessments "help you find potential weaknesses", pen tests show "how easy they are to exploit" [2]. When you get a quote for a "vulnerability assessment", ask one question: does a person review the results, and does anyone attempt exploitation? If yes to the first and no to the second, it's an assessment. If no to both, it's a scan.
Which one do you need? Five common situations
1. You're launching a SaaS product
Run an authenticated scan of the app and its hosting before launch and fix what it finds. Then get a manual pen test of the application before it handles real customer data. The UK Service Manual advises using a third party to test a service "before it moves into public beta or uses real user data" [2]. Enterprise buyers will also ask for a recent pen test report in their security questionnaires. A scan report won't satisfy that question.
Give the tester an account for each user role. Most serious SaaS bugs sit in the gap between what one role should see and what another can.
2. You take card payments (PCI DSS)
PCI DSS v4.0.1 requires both, on different clocks. Requirement 11.3 asks for internal vulnerability scans at least once every three months and external scans at least once every three months by a PCI SSC Approved Scanning Vendor (ASV) [7]. Requirement 11.4 asks for internal and external penetration tests at least once every 12 months and after any significant change, by a qualified, organisationally independent tester [7].
Internal and external scans are also required after any significant change, and if you use segmentation to reduce scope, it must be pen tested at least every 12 months and after any change to it (requirement 11.4.5) [7].
So a scan alone is not enough for PCI DSS, and neither is a yearly pen test alone. How much of this applies to you depends on how you take payments and which self-assessment questionnaire you file, so confirm the scope with your acquirer or QSA.
3. You're preparing for an ISO 27001 audit
ISO/IEC 27001:2022 does not require a penetration test. Annex A control 8.8 requires that information about technical vulnerabilities "shall be obtained", your exposure "evaluated" and "appropriate measures" taken [8]. Regular scanning covers the "obtained" part. The implementation guidance in ISO/IEC 27002 lists periodic, documented penetration tests as one way to meet the control [8], and auditors commonly expect to see one.
Our advice: keep twelve months of scan reports with evidence that you fixed what they found, plus at least one pen test report covering your main systems. Ask your certification body early what evidence it expects.
4. You've just shipped a major release
New features bring new logic, new endpoints and new roles. A scan will pick up a vulnerable library you added. It won't tell you whether the new team-sharing feature lets one customer read another's files. Scan after every release as part of your pipeline. Commission a pen test when a release changes authentication, permissions, payments or how data is shared between customers. PCI DSS calls this "significant change" and requires a fresh test after it [7]; outside PCI it's still a sensible rule.
5. You want quarterly security hygiene
This is scanning territory. Scan every month, or at least every quarter, inside and outside, and track how quickly you fix critical findings. Cyber Essentials Plus works on the same principle: the certification body audits your systems with internal and external vulnerability scans and checks on a sample of devices [9]. It doesn't include a pen test of your web applications, and a pen test won't get you the certificate [10].
How the two work together in a yearly plan
Yearly plan: monthly vulnerability scans, quarterly reviews, an annual pen test, a pen test after major releases, and fix and retest after each test. Months shown are an example.
The NCSC's view of the relationship is blunt. It says penetration testing "should be viewed as a method for gaining assurance in your organisation's vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities", and compares a pen test to a financial audit that checks the finance team's daily bookkeeping [5]. It also notes that a pen test only validates your systems "on the day of the test", and that a year or more often passes between tests [5].
That gives a simple plan for most small and mid-sized organisations:
- Continuously or monthly: authenticated vulnerability scans of internet-facing systems and internal hosts, with someone triaging the results.
- Quarterly: review fix times and rescan to confirm fixes (and run ASV scans if you're in PCI scope).
- Once a year: a manual penetration test of your most important application and network, scoped by risk. Share a current vulnerability assessment (your triaged scan results) with the tester, as the NCSC recommends, so they spend their days on what the scanner can't do [5].
- After significant changes: a targeted pen test of what changed.
- After every test: fix, retest, and ask why your scanning didn't catch anything the tester found. The NCSC says previously unknown vulnerabilities from a pen test deserve "special attention" for exactly this reason [5].
Scans and pen tests tell you what's exposed. Between them, security monitoring tells you when someone is trying it.
What we offer, and what we call it
We sell both, and we label them as what they are. On our pricing page, Lite ($250) is a basic vulnerability scan and summary report. It's a sensible first look, and it isn't a penetration test. Plus ($500) adds manual testing of common exploits. For a full manual penetration test, we scope and quote each engagement. We agree the scope in writing before we test, and the statement of work says what's covered.
Not sure which you need? Send us a short brief through our security audit and penetration testing page. Tell us what the system does, who uses it and why you're testing, and we'll tell you whether a vulnerability scan or a manual pen test fits, and how many days it needs.
FAQ
Is a vulnerability scan enough for PCI DSS?
No. PCI DSS v4.0.1 requires quarterly internal scans and quarterly external scans by an Approved Scanning Vendor (requirement 11.3), and separately requires internal and external penetration tests at least every 12 months and after significant changes (requirement 11.4) [7]. Your acquirer or QSA confirms exactly which requirements apply to your payment setup.
Is a vulnerability scan the same as a penetration test?
No. A scan is automated and reports known issues, often with false positives [3]. A penetration test is mostly manual: a tester confirms which issues are exploitable, chains them, and tests business logic that scanners can't see [1][6].
How often should I run each one?
Scan at least quarterly, and monthly or continuously if you can. Run a penetration test at least once a year and after significant changes to your systems. These intervals match PCI DSS [7] and the UK government's advice to test frequently as you build [2].
Can a penetration test replace vulnerability scanning?
No. The NCSC says a pen test only validates your systems on the day of the test and should check your vulnerability management process, not replace it [5]. New vulnerabilities are published between tests, and only regular scanning will catch them on your systems.
How this guide was made: Ramin Moradi researched and wrote it with AI assistance, using the official sources listed below. Every quote was checked against its source on 12 October 2026.
Sources
- PCI Security Standards Council, Information Supplement: Penetration Testing Guidance v1.1 (September 2017), section 2.1. https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf
- GOV.UK Service Manual, "Vulnerability and penetration testing" (last updated 23 October 2024). https://www.gov.uk/service-manual/technology/vulnerability-and-penetration-testing
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (2008), section 4.4. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
- Tenable documentation, "Vulnerability Assessment/Scanning" and "Scan Best Practices". https://docs.tenable.com/cyber-exposure-studies/vulnerability-management/Content/vuln-assessment-scanning.htm and https://docs.tenable.com/vulnerability-management/Content/Scans/ScanBestPractices.htm
- National Cyber Security Centre, "Penetration testing" (published 8 August 2017, reviewed 10 January 2022). https://www.ncsc.gov.uk/guidance/penetration-testing
- OWASP Web Security Testing Guide (latest), Foreword: "The Role of Automated Tools". https://owasp.org/www-project-web-security-testing-guide/latest/
- PCI Security Standards Council, PCI DSS v4.0.1 (June 2024), requirements 11.3.1, 11.3.2, 11.4.2, 11.4.3 and 11.4.5 (PCI SSC document library). https://www.pcisecuritystandards.org/document_library/
- ISO/IEC 27001:2022, Annex A control 8.8 "Management of technical vulnerabilities", https://www.iso.org/standard/27001 ; ISO/IEC 27002:2022, control 8.8 guidance, https://www.iso.org/standard/75652.html
- IASME, Cyber Essentials frequently asked questions. https://iasme.co.uk/cyber-essentials/frequently-asked-questions/
- Incursion Cyber Security, "Cyber Essentials Plus vs penetration testing" (updated 30 September 2026). https://incursion-security.co.uk/cyber-essentials-plus-vs-penetration-testing/
Comments