A vulnerability scan is an automated check that sweeps many systems for known weaknesses, such as missing patches, outdated software and weak settings, and it runs often. A penetration test is a time-boxed exercise in which a skilled person tries to exploit weaknesses, chain them together and show what an attacker could actually reach. Scanning gives you breadth and frequency. Penetration testing gives you depth and proof. Most organizations need both, on different schedules and for different reasons.
We see the two confused all the time. A scan report arrives with "penetration test" on the cover, or a quote for a penetration test turns out to describe a scan. This post sets out the differences, when each one makes sense and how they fit together.
What is vulnerability scanning?
A vulnerability scanner is software that probes your systems and compares what it finds with a large library of known vulnerabilities and misconfigurations. It identifies hosts, open ports, running services and software versions, then flags anything that matches a known issue. Findings usually carry a CVE identifier and a CVSS severity score.
Scans come in a few forms:
- External scans run from the internet against your public IP addresses and domains.
- Internal scans run from inside the network against servers, workstations and network devices.
- Authenticated (credentialed) scans log in to each system and read installed packages and configuration directly, which is far more accurate than guessing from the outside.
- Web application scans crawl a site and test for common flaws such as injection and cross-site scripting.
The strength of scanning is coverage. A scanner can check thousands of hosts overnight and do it again next week. The weakness is that it only finds what it has been taught to look for. It can't judge business context, and it produces false positives that someone has to sort through.
What is penetration testing?
A penetration test is a manual, goal-driven assessment carried out by a tester or small team within an agreed scope, set of rules and time window. Testers usually run scanners early on. The value comes from what happens next: confirming which findings are real, exploiting them safely, combining several low-severity issues into a serious attack path, and finding flaws that no scanner has a check for.
Common types of penetration test include:
- External network testing of internet-facing systems
- Internal network testing, which starts from an assumed foothold such as a compromised workstation or a rogue insider
- Web application and API testing
- Cloud environment testing, covering identity permissions, storage and network exposure
- Wireless network testing
Business logic flaws show why the human element matters. Picture an API that lets a logged-in customer view someone else's invoice by changing a number in the request. A scanner sees a normal, successful response. A tester sees a data exposure affecting every customer.
The output is a written report with a narrative of what the tester did, evidence for each finding, risk ratings in the context of your business and specific remediation advice. A good engagement includes a retest to confirm your fixes worked. Recognized methodologies include NIST SP 800-115, the OWASP Web Security Testing Guide and the Penetration Testing Execution Standard (PTES).
Vulnerability scanning vs. penetration testing at a glance
| Vulnerability scanning | Penetration testing | |
|---|---|---|
| Purpose | Find known weaknesses across the whole environment | Show what an attacker could achieve, and how |
| Method | Automated checks against a library of known issues | Manual work by a tester using tools and judgment |
| Depth | Broad and shallow; detects but rarely exploits | Narrow and deep; exploits, pivots and chains findings |
| Frequency | Continuous, weekly or monthly, and at least quarterly | Typically annually and after significant change |
| Who performs it | Your own IT or security team, or a managed service | A qualified tester, independent of the systems under test |
| Output | A list of findings with severity scores, often hundreds of lines | A narrative report with attack paths, evidence and business impact |
| Cost | Low per scan once tooling is in place; the main cost is staff time for triage | Higher per engagement; priced by scope and tester days |
When do you need vulnerability scanning?
In short, all the time. Scanning is the routine hygiene that keeps known problems from piling up between changes. It belongs in your program if you want to:
- Catch missing patches and configuration drift between maintenance windows
- Check new systems before and after they go live
- Measure whether patching is keeping pace, using numbers you can trend
- Produce evidence for auditors, customers and insurers
How often depends on how fast your environment changes. Quarterly is the floor that several standards set, not a target. Internet-facing systems deserve at least monthly scanning, and busy environments benefit from weekly or continuous scans. Credentialed internal scans should be the default wherever you can arrange the access.
When do you need a penetration test?
A penetration test answers a different question: given everything in place, how far could someone actually get? Typical triggers are:
- An annual baseline assessment
- Launching a new application, customer portal or API
- Significant infrastructure change, such as a new cloud environment, a network redesign or an acquisition
- A contractual, regulatory or insurance requirement
- A need to confirm that specific controls work, such as network segmentation or multi-factor authentication
Timing matters. If you haven't been scanning and patching, a penetration test is poor value. You end up paying a tester by the day to find missing patches that a scanner would have reported for a fraction of the cost. Get your scan results under control first, then bring in a tester to find what's left.
How do scanning and penetration testing work together?
The two feed each other. Scanning keeps the known issues down, so testers spend their time on the things only a person can find. Penetration test results then show you where scanning falls short.
A healthy cycle looks like this:
- Keep an accurate asset inventory, because you can only scan and test what you know about.
- Scan on a schedule, triage the results and fix them within agreed timeframes.
- Commission a penetration test annually and after major changes.
- Fix the test findings and have the tester confirm the fixes.
- Feed what you learned back into scanning scope, scanner configuration and your build standards.
The feedback in step 5 is where many organizations miss value. If a tester finds hosts your scanner never saw, your inventory has gaps. If a tester exploits a weakness your scanner rated as low, your prioritization needs work. And if the same class of flaw keeps appearing in every web application test, the fix belongs in your development standards rather than in another round of tickets.
Does PCI DSS require both?
Yes. If you store, process or transmit payment card data, PCI DSS requires both scanning and penetration testing. Under PCI DSS v3.2.1, Requirement 11.2 calls for internal and external vulnerability scans at least quarterly and after any significant change. The quarterly external scans must be performed by a PCI SSC Approved Scanning Vendor (ASV). Requirement 11.3 calls for internal and external penetration testing at least annually and after any significant infrastructure or application upgrade or modification. It also requires a defined methodology and testing of segmentation controls if you use segmentation to reduce scope.
PCI DSS v4.0 was published on 31 March 2022. The same core obligations carry forward, but the numbering changes: vulnerability scanning moves to Requirement 11.3 and penetration testing to Requirement 11.4. Version 3.2.1 remains active until it is retired on 31 March 2024, which gives organizations time to plan the move. If your team talks about "11.3", make sure everyone knows which version they mean.
Frequently asked questions
Can a vulnerability scan replace a penetration test?
No. A scan tells you which known issues are present. It won't tell you whether they can be combined into a path to your most sensitive data, and it won't find logic flaws in your applications. Treat a scan labeled as a penetration test with suspicion, and ask to see the methodology and the tester's manual work.
How often should you do a penetration test?
At least once a year, and after any significant change to your infrastructure or key applications. Organizations that release major application changes frequently often test those applications more often, or test each major release before it goes live.
Should the same team handle scanning and penetration testing?
Scanning is usually best run in-house or through a managed service, because it has to happen continuously. Penetration testing needs independence. The tester should not be the person who built or runs the systems being tested, whether that means an internal team kept separate from operations or an outside firm.
Is a vulnerability assessment the same as a vulnerability scan?
Not quite. A vulnerability assessment usually means scanning plus analysis: validating findings, removing false positives and prioritizing the results for your environment. It sits between a raw scan and a penetration test, but it still stops short of exploitation.
Key takeaways
- Scanning is automated, frequent and broad. Penetration testing is manual, periodic and deep.
- Run scans at least quarterly, and far more often for internet-facing and fast-changing systems. Plan penetration tests annually and after significant change.
- Fix what the scanner finds before paying for a penetration test, so the tester's time goes on problems only a person can uncover.
- Use penetration test results to improve your scanning scope, asset inventory and build standards.
- If PCI DSS applies to you, you need both. Note the requirement numbering change between v3.2.1 and v4.0 as you plan your transition.