A vulnerability scan tells you which known weaknesses might be present. A penetration test tells you which ones an attacker could actually use and how far they’d get. This guide compares the two, walks one office network through both, and gives you a decision table.
TL;DR
- You usually need both. A vulnerability scan is automated, broad and run regularly to catch known weaknesses as they appear. A penetration test is a person proving which weaknesses can actually be used, and how far they lead, at set points.
- Scans are good at breadth and speed but produce false positives and miss logic flaws and chains of small issues. Penetration tests go deep on a defined scope but are a snapshot in time.
- Start with scanning if you’ve never done either and have many systems; start with a penetration test if a customer, insurer or auditor wants evidence, or you’re about to launch something.
- The worked example below shows one 30-person office network through both, and why each found things the other missed.
What is a vulnerability scan?
A vulnerability scanner is software that checks your systems against a database of known weaknesses: missing patches, outdated software versions, weak settings, expired certificates and services that shouldn’t be exposed.
NIST SP 800-115, a widely used US government guide to security testing, sums up what scanning does well and badly. Scanners identify hosts, open ports and known vulnerabilities, and often suggest fixes. But they "rely on a repository of signatures", can have "a high false positive error rate (i.e., reporting vulnerabilities when none exist)", and the results need someone with networking and operating system expertise to interpret them.
Scans come in a few forms:
- External scans look at what the internet can see.
- Internal, authenticated scans log in to devices with a scanning account and read installed software versions directly. These are far more accurate than unauthenticated scans.
- Agent-based scans run on laptops and servers, so devices away from the office are still covered.
Speed matters more than it used to. ASD’s Annual Cyber Threat Report 2025-26 says it has previously observed most vulnerability exploitation within two weeks, some within 48 hours of a patch or advice being released, and expects AI-driven tools to shorten that further. Its advice is to accelerate patching, and it notes that "regularly scanning for missing patches" helps organisations close the gap between a new vulnerability and its fix.
A scan on its own is a list. Vulnerability management is the process around it: finding your assets, scanning, ranking findings by real risk, getting them fixed and confirming the fix.
What is a penetration test?
A penetration test is a person (or small team) attacking your systems with your written permission, within an agreed scope and rules. NIST puts the key difference in one line: "While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence."
Testers use scanners too, but as a starting point. The value is in what the tool can’t do: judging context, testing business logic, and chaining several minor issues into a serious one. Our guide to what happens in a penetration test covers the full process.
How do they compare?
| Vulnerability scan | Penetration test | |
|---|---|---|
| The question it answers | Which known weaknesses might be present across our systems? | Could an attacker actually get in, and what could they reach? |
| Who runs it | Software, configured and reviewed by IT or a security provider | A skilled tester, using tools plus manual techniques |
| Breadth | Wide: every device and address it can reach | Narrow: the agreed scope |
| Depth | Shallow: checks for signs of known issues | Deep: proves issues, follows them as far as the rules allow |
| False positives | Common; findings need checking | Rare; findings are confirmed with evidence |
| What it misses | Logic flaws, access-control errors, chains of low-rated issues, weak processes | Anything outside the scope, and anything that changes after the test |
| Frequency | Regularly, and ideally continuously, because new vulnerabilities are published every day | At set points: before a launch, after major change, or when a contract or auditor asks |
| Disruption | Low when tuned; agents add almost no network load | Low with good controls, but can’t be ruled out entirely |
| Output | A list of findings with severity scores (often CVSS) and suggested fixes | A report with an executive summary, risk-rated findings, evidence, attack paths and specific fixes |
| Most useful for | Keeping day-to-day exposure low and proving patching happens | Confirming your defences hold, and prioritising what really matters |
What do the severity scores mean?
Both scans and penetration test reports often use the Common Vulnerability Scoring System (CVSS) from FIRST. The CVSS v4.0 specification maps scores to ratings: None (0.0), Low (0.1 to 3.9), Medium (4.0 to 6.9), High (7.0 to 8.9) and Critical (9.0 to 10.0).
The catch is that a scanner usually reports the base score, which describes the vulnerability in general, not in your environment. NIST gives a good example: a scanner may rate a cleartext-password FTP server as a moderate risk, but if it’s an anonymous public server that doesn’t use passwords, the real risk "might be considerably lower". NIST’s advice is to determine the right risk level for each vulnerability "and not simply accept the risk levels assigned by vulnerability scanners".
A penetration tester does that judgement for the systems in scope. A good vulnerability management service does it across everything, adding whether a vulnerability is being actively exploited and how important the affected system is.
One network, both ways: a worked example
Example scenario. This is an illustration, not a real client, and it describes a common set-up. The findings are typical of what each method turns up, not results from a real engagement.
The network. A 30-person professional services office. Microsoft 365 for email and files. One firewall with a VPN for remote staff. A Windows file server and a line-of-business application server in a small server cupboard. Thirty laptops, three printers, a network storage box used for backups, and guest Wi-Fi. Everything inside sits on one flat network.
What the vulnerability scan finds
An external scan plus an authenticated internal scan, run the same week, might report:
- Firewall VPN portal: a firmware version with a published critical vulnerability. CVSS Critical.
- Several laptops: a browser and a PDF reader several versions behind. High.
- Application server: an operating system version that is out of vendor support. High.
- File server: SMB signing not required. Medium.
- Printers: default admin passwords and old protocols enabled. Medium.
- Backup storage box: web interface using a self-signed certificate. Low.
- A long tail of other findings, mostly Low or informational, plus a handful that turn out to be false positives (for example, a vulnerability reported against a software version that was backported with the fix).
What you get: breadth. Every device was checked, including the laptops that had quietly stopped updating. The list is long, and without context the team might start with the Lows because they’re quick.
What the penetration test finds
An external test of the firewall, plus an internal test that begins on one staff laptop (simulating a successful phishing email) with the Microsoft 365 tenant and guest Wi-Fi also in scope, might report:
- External: the VPN portal vulnerability is real and exploitable. Confirmed, Critical. (The scanner was right; the test proves it.)
- Internal attack path, Critical: from the one laptop, the tester finds the same local administrator password is used on every laptop. That gives access to a second laptop where an IT support account is signed in. That account has admin rights on the file server and the backup storage box. Result: the tester can reach client files and could delete the backups.
- Microsoft 365, High: an old sign-in method is still allowed for some accounts, letting a stolen password bypass MFA.
- Network, Medium: guest Wi-Fi can reach the printers and the backup storage box because the network is flat.
Notice what happened. The scanner reported nothing like "shared local admin password" or "IT account signed in on a staff laptop", because those aren’t software vulnerabilities. Individually, each issue looks minor or is invisible. Together they make the most serious finding of the engagement. That chaining is what NIST means when it says penetration tests look for "combinations of vulnerabilities".
The test also didn’t look at the out-of-date laptops individually. It didn’t need to, and they weren’t in its scope.
What the office does next
- Fix the chain first: unique local admin passwords on every device, separate admin accounts for IT, protect and isolate the backups.
- Patch the VPN portal at once and confirm with a rescan.
- Turn off the old Microsoft 365 sign-in method.
- Segment the network so guests, printers and backups sit apart from staff devices. Our guide to small business VLANs shows a plan for an office this size.
- Keep scanning regularly so the laptops and the new application server don’t drift out of date again, and retest the critical findings.
Each method found something the other missed, and each made the other’s results more useful.
Know what needs patching before attackers do. Our vulnerability management finds, prioritises and tracks the fixes across your devices, servers and internet-facing systems.
Which do you need first? A decision table
| Your situation | Start with | Then |
|---|---|---|
| You’ve never done either, and have more than a handful of devices and servers | Vulnerability scanning, to find and fix the obvious gaps | A penetration test once the basics are under control |
| A customer, insurer, auditor or government buyer has asked for "independent security testing" | A penetration test scoped to what they care about | Regular scanning to show the issues stay fixed |
| You’re about to launch a website, portal, app or new cloud environment | A penetration test of the new system before launch | Add it to regular scanning |
| You’ve had a security incident or near miss | A penetration test focused on how it happened and where else it could | Scanning to catch the same class of issue elsewhere |
| You run regular scans but findings never seem to shrink | A review of how findings are prioritised and fixed | A penetration test to find what the scanner can’t see |
| You scan regularly and have tested in the past, but your systems have changed significantly since | A new penetration test of what changed | Keep scanning |
| You’re working towards ASD Essentials or ISO/IEC 27001 | Scanning, because patching controls need ongoing evidence | A penetration test to check the controls hold |
Five questions to ask before you buy either
- For scanning: are internal scans authenticated, and are laptops covered when they’re away from the office? Unauthenticated scans miss a lot and guess more. Check: the provider can show you a sample report from an authenticated scan.
- Who reviews the results before they reach you? A raw scanner export of hundreds of lines is rarely acted on. Check: findings arrive ranked by real risk to your systems, with false positives removed.
- For a penetration test: is the testing manual, and which methodology is followed? References such as NIST SP 800-115 and the OWASP Web Security Testing Guide are good signs. Check: the proposal describes how testing is done, not just which tools are run.
- What does the report include? Check: a sample report has an executive summary, evidence for each finding and specific fixes.
- How are fixes confirmed? Check: a rescan or retest is part of the plan, and closed findings are shown as closed.
Want to know what an attacker could actually do? Our penetration testing finds the weaknesses that matter in your network, cloud and applications, and shows you how to fix them.
Key takeaways
- A vulnerability scan finds possible known weaknesses across everything; a penetration test proves which ones matter on a defined scope.
- Scanners are fast and broad but produce false positives and can’t see logic flaws or chains of small issues.
- Penetration tests are deep but are a snapshot, so scanning keeps exposure low in between.
- Don’t take scanner severity at face value: judge each finding in the context of your systems.
- Use the decision table above to pick a starting point, and plan for both.
Sources
- NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment (September 2008), sections 4.3 Vulnerability Scanning and 5.2 Penetration Testing
- FIRST, CVSS v4.0 Specification Document, Table 22: Qualitative severity rating scale
- ASD’s ACSC, Annual Cyber Threat Report 2025-26, sections on patching and vulnerability discovery
- OWASP, Web Security Testing Guide
Want a second pair of eyes?
Catharsis Cyber Security is a Sydney cyber security company, certified to ISO/IEC 27001:2022. We help organisations protect, test and run their technology, and explain it in plain English.
