If you are buying security testing for the first time, the two terms you will hear most are penetration testing and vulnerability scanning. They sound interchangeable. They are not, and treating them as the same thing is how budgets get wasted and audits get failed.
A vulnerability scan is an automated tool that checks your systems against a database of known weaknesses and hands you a list. A penetration test is a person who tries to break in, proves what an attacker could actually do, and tells you what it means for your business. One is a smoke detector. The other is a fire drill run by someone who has set a lot of fires.
This guide explains exactly how they differ, when you need each, what each costs you in time and money, and what your compliance framework actually requires. By the end you will know which one to buy, or whether you need both.
The short version
A vulnerability scan is automated breadth: it sweeps your environment quickly and flags potential weaknesses by matching software versions and configurations against known issues. You run it often, it is inexpensive, and it produces a long list that still needs human triage.
A penetration test is manual depth: a tester uses tools and skill to exploit vulnerabilities, chain them together, and reach something that matters, then writes up the real risk with proof and fixes. You run it periodically, it costs more, and it tells you which of those weaknesses an attacker could truly use.
Most organizations need both, doing different jobs at different cadences. The mistake is buying one and believing it does the work of the other.
1. What each one actually does
A vulnerability scanner is software. You point it at an IP range, a web application, or a host, and it probes for known issues using automated scanning: out-of-date software, missing patches, weak configurations, default credentials, exposed services. It compares what it finds against a constantly updated database of known vulnerabilities, often referenced by their CVE identifiers, and returns a report ranked by severity.
The scanner does not break in. It infers that a weakness is probably present, usually from a version number or a response signature. That is fast and useful, but it means vulnerability scanning reports what might be exploitable, not what is.
A penetration test starts where the scan ends. A tester reviews the findings, discards the noise, and then attempts to exploit the weaknesses by hand: bypassing a login, escalating privileges, chaining a low-risk misconfiguration into a full account takeover, reasoning about your business logic in a way no automated tool can. The goal is not a list. It is an answer to the question that actually matters: if a capable attacker targeted us, what could they reach, and how?
Not sure which your compliance programme requires?
Tell us your framework and environment and we will scope the right testing on a short call.
2. Automated breadth vs manual depth
This is the core distinction, and every other difference flows from it.
A scan is broad and shallow. It can check thousands of hosts overnight, every week, for a low price. It will not miss the obvious unpatched server. It will also flag findings that are not exploitable in your context, produce false positives, and never tell you that two medium-risk issues combine into a critical one.
A penetration test is narrow and deep. A human can only test so much in a week, so scope matters. But within that scope, a tester does what tools cannot: they exercise judgement, follow an attack path, and prove impact. They will tell you that the real risk is not the scanner's eighty "high" findings but the one chain that leads to your customer database.
You need breadth for hygiene and depth for assurance. Neither replaces the other.
3. False positives, proof, and prioritization
A vulnerability scan's biggest practical problem is signal-to-noise. A scanner that flags two hundred issues has handed you a triage job, not an answer. Some findings will be false positives. Many will be real but unreachable, low impact, or already mitigated by a control the scanner cannot see. Your team still has to work out which ones matter.
A penetration test inverts this. Because the tester attempts exploitation, a finding in a good pen-test report is proven: here is the weakness, here is how we exploited it, here is the evidence, here is the attack path, and here is the business impact, rated with a CVSS-aligned score. That proof is what lets you prioritize honestly and what makes the report credible to an auditor or an enterprise customer.
4. Cadence: how often you run each
A vulnerability scan is something you do continuously. Good practice is to scan on a regular schedule, monthly or quarterly at a minimum, and after any significant change, because new vulnerabilities are disclosed every day and your environment keeps moving.
A penetration test is point-in-time. You commission one when you need assurance: before a product launch, after a major architecture change, on an annual basis for a compliance programme, or when a customer's security review demands it.
A simple way to hold both in your head: scan continuously to keep your environment clean, test periodically to prove it is actually secure.
5. Cost and what you get for it
A vulnerability scan is inexpensive, often delivered as a recurring subscription or as part of a managed service, because the work is largely automated. What you pay for is the tooling, the scheduling, and, ideally, a human to triage the results so you are not drowning in raw output.
A penetration test costs more because you are paying for skilled human time. The price scales with scope: the number and type of targets, the depth of testing, and whether a retest is included. What you get is not a list. It is an executive summary a non-technical stakeholder can read, technical detail an engineer can act on, proof for each finding, prioritized remediation, and, from a good provider, a retest to confirm the fixes worked.
6. What your compliance framework requires
This is where buyers most often get caught out, because the frameworks are specific and they are not the same.
| Framework | Vulnerability scanning | Penetration testing |
|---|---|---|
| PCI DSS | Quarterly, via Approved Scanning Vendor (external) | Annual + after significant changes |
| SOC 2 | Ongoing vulnerability management expected | Not mandated by name; commonly expected by auditors |
| ISO/IEC 27001 | Ongoing vulnerability management is a control requirement (ISO/IEC 27001:2022, control A.8.8) | Frequently expected as evidence of active control testing |
| HIPAA | Risk analysis requires identifying vulnerabilities | Supports the required technical safeguard evaluation |
PCI DSS is the clearest example: it requires both. You must run vulnerability scans at least quarterly through an Approved Scanning Vendor for external scans, and you must also perform penetration testing at least annually and after significant changes. A scan does not satisfy the pen-test requirement, and a pen test does not satisfy the scan requirement.
If a framework is driving your testing, confirm exactly what it asks for before you buy, because buying the wrong one means paying twice.
7. A credible test follows a methodology
One more thing separates a real penetration test from a glorified scan: methodology. A credible provider follows a published, repeatable approach and can name it, such as OWASP for web and API work, the Penetration Testing Execution Standard, or NIST SP 800-115. Methodology is what makes a test defensible to an auditor and consistent across engagements.
Ask any prospective provider what is automated and what is done by hand. If the sample report reads like exported scanner output, you are being sold a scan at pen-test prices. The manual exploitation a tool cannot perform is the whole point.
How Onyx helps
Onyx delivers manual-led penetration testing anchored in OWASP, PTES, and NIST SP 800-115, with CREST-accredited testing available through our CREST-member partner. We scope before quoting, agree the rules of engagement in writing, and deliver a report with proven findings, CVSS-aligned ratings, and a retest to confirm remediation. We scope each engagement to the evidence your specific framework and auditor expect, whether that is PCI DSS, SOC 2, or ISO 27001.
Need the right testing scoped for your framework?
We map your compliance requirement to the right combination of testing on a 30-minute call. No obligation.
See also: what is a penetration test, how to choose a penetration testing company, and our penetration testing service. Or start with the free security self-assessment.
FAQ
Is a vulnerability scan the same as a penetration test?
No. A vulnerability scan is an automated tool that lists potential weaknesses by matching your systems against a database of known issues. A penetration test is a manual, human-led engagement that attempts to exploit those weaknesses, proves which are real, and shows the business impact. A scan is a useful input to a test; it is not a substitute for one.
Do I need both a scan and a penetration test?
Usually, yes. They do different jobs: scanning gives you continuous, affordable coverage of known issues, and penetration testing gives you periodic, in-depth assurance with proof. Some compliance frameworks, PCI DSS in particular, explicitly require both. A maturing security programme runs regular scans and at least annual penetration tests.
How often should I run each?
Run vulnerability scans on a regular schedule, monthly or quarterly at a minimum, and after any significant change, because new vulnerabilities appear constantly. Commission a penetration test periodically: annually for most compliance programmes, before a major launch, after a significant architecture change, or when a customer's security review requires one.
Does PCI DSS require penetration testing or vulnerability scanning?
Both. PCI DSS requires external vulnerability scans at least quarterly through an Approved Scanning Vendor, and penetration testing at least annually and after significant changes. Meeting one does not satisfy the other, so a PCI programme needs a plan for each.
Why is a penetration test more expensive than a scan?
Because you are paying for skilled human time rather than automated tooling. A tester manually exploits weaknesses, chains them into attack paths, reasons about your business logic, and produces a report with proof, CVSS-aligned ratings, prioritized fixes, and often a retest. That depth is what a scanner cannot provide, and it is what makes the result credible to an auditor or customer.
Can a vulnerability scan replace a penetration test for compliance?
Generally no. Where a framework expects penetration testing, an automated scan does not meet that requirement, because it does not demonstrate that a person attempted to exploit your controls. Confirm what your specific framework and auditor require before you buy, and scope the testing to produce that evidence.