A vulnerability scan identifies known weaknesses by matching your systems against a database of signatures. A penetration test has a skilled human attempt to exploit those weaknesses — and find the ones no scanner can see. They are complementary tools, not substitutes, but they are frequently confused. The confusion matters because organisations that buy scans believing they are getting pentests leave genuine risk undiscovered. That risk is not hypothetical: the ASD Annual Cyber Threat Report 2024–25 logged a cybercrime report every 6 minutes across Australia.
What Automated Vulnerability Scanning Does
Vulnerability scanners — tools like Nessus, Qualys, Rapid7, or AWS Inspector — work by comparing your system configurations, software versions, and network services against a continuously updated database of known vulnerabilities. When a match is found, it is flagged with a severity rating (typically using the CVSS scoring system).
What scanning does well:
- Coverage at scale. A scanner can assess hundreds of hosts and thousands of services in a matter of hours. No human tester can match that throughput at the infrastructure level.
- Known vulnerability detection. If your server is running a version of OpenSSL with a published CVE, a scanner will find it. Consistently.
- Continuous monitoring. Modern scanning tools run on schedules — daily, weekly — and alert when new vulnerabilities emerge in your environment as patches are released and configurations change.
- Low cost at scale. Scanning platforms are subscription-based. For the volume of systems they can assess, the cost is low.
What scanning cannot do:
- It cannot exploit vulnerabilities. A scanner identifies that something may be vulnerable. It does not attempt to confirm exploitability or demonstrate the actual impact of a successful attack.
- It cannot find business logic flaws. Scanners have no understanding of what your application is supposed to do. They cannot find a flaw where a user can manipulate prices, escalate privileges through application workflows, or access another user's data through a predictable ID — because those require understanding intent.
- It cannot chain vulnerabilities. Real attacks often work by combining multiple low-severity issues into a high-impact path. Scanners assess vulnerabilities in isolation.
- It generates false positives. A scanner flagging a vulnerability does not mean the vulnerability is actually present or exploitable in your specific configuration. Someone has to triage the output.
What Manual Penetration Testing Does
A manual penetration test is a structured attack simulation conducted by a qualified human tester. The tester uses the same techniques, tools, and creativity as a real attacker — within an agreed scope and rules of engagement — to demonstrate what is actually exploitable, not just what theoretically might be.
What manual testing does that scanning cannot:
- Business logic exploitation. A skilled tester will walk through your application the way a real attacker would — testing whether user roles can be bypassed, whether price or quantity fields can be manipulated, whether multi-step workflows have exploitable gaps in state management.
- Authentication and session testing. Token predictability, session fixation, OAuth misconfiguration, multi-factor authentication bypasses — these require human understanding and creative probing.
- Chained attack paths. The most impactful findings in penetration tests often come from combining multiple medium-severity issues into a single high-severity path. A tester who finds an information disclosure, an IDOR, and a weak session token will ask: can these three be combined? A scanner assesses each in isolation.
- Novel and zero-day adjacent vulnerabilities. If a vulnerability class is new enough that no scanner has a signature for it, only a human tester will find it.
- Contextual risk assessment. A tester who understands your business can tell you which findings matter most in your specific threat model. A scanner reports CVSS scores without context.
Head-to-Head Comparison
| Factor | Automated Scanning | Manual Penetration Test |
|---|---|---|
| What it finds | Known vulnerabilities with signatures | Known and unknown vulnerabilities, including business logic and chained attacks |
| Exploitability confirmation | No — flags theoretical issues | Yes — demonstrates actual exploitation |
| Business logic testing | None | Core capability |
| False positives | High — requires human triage | Low — tester confirms before reporting |
| Speed | Hours to days | Days to weeks depending on scope |
| Cost | Low — subscription-based | Higher — manual expert time |
| Frequency | Continuous / weekly | Annual or on significant change |
| Compliance value | Useful for hygiene; not a pentest substitute | Accepted by ISO 27001, SOC 2, CPS 234 auditors |
| Report quality | Volume-based, often noisy | Focused, contextual, actionable |
Why Manual Testing Is Superior for Compliance
Australian businesses pursuing ISO 27001 certification, SOC 2 Type 2 reports, or APRA compliance under CPS 234 cannot substitute automated scanning for manual penetration testing in their audit evidence.
ISO 27001 (specifically control A.8.8 — management of technical vulnerabilities, and the broader ISMS security testing requirements) distinguishes between vulnerability management processes (which can include automated scanning) and security testing (which requires human-led assessment of control effectiveness). An auditor reviewing your ISMS expects to see both.
SOC 2 auditors reviewing the Security and Availability Trust Service Criteria consistently look for penetration test reports as evidence that the organisation tests its security controls under conditions that simulate real attack scenarios. Automated scanner output is not an equivalent.
CPS 234, APRA's information security standard for regulated entities and their material service providers, explicitly requires penetration testing at a frequency proportional to the entity's risk profile. The standard uses the term "penetration testing" — not vulnerability scanning — and the distinction is intentional.
The practical rule: Use automated scanning continuously for hygiene — patching signals, configuration drift, new vulnerability alerts. Use manual penetration testing periodically for depth — annual external tests, tests on significant new features or infrastructure changes, and tests for compliance evidence. They are not alternatives; a mature security program uses both.
When You Need One vs the Other (or Both)
Run automated scanning when:
- You need continuous visibility into your infrastructure vulnerability state.
- You are managing a patching program and need to prioritise by severity.
- You want to detect new vulnerabilities as they are published against software you are running.
- You are maintaining compliance hygiene between annual penetration tests.
Run a manual penetration test when:
- You are pursuing ISO 27001, SOC 2, or CPS 234 compliance and need a testing report for your auditor.
- You have launched a new product, feature, or significant infrastructure change and want assurance it has been tested under attack conditions.
- You are going through enterprise procurement and a customer has asked for a recent penetration test report.
- You want to understand the actual impact of exploitation — not just a list of theoretical weaknesses.
- Your annual test cycle is due.
Logic Weave delivers manual penetration testing in Melbourne and across Australia for FinTech, HealthTech, and SaaS companies. Our tests are conducted by CREST-credentialled practitioners using grey-box methodology as standard, with full written reports and debrief sessions. If you want to discuss the right testing approach for your current stage, book a 30-minute call.
Frequently Asked Questions
What is the difference between a vulnerability scan and a penetration test?
A vulnerability scan is an automated process that identifies known vulnerabilities by comparing system configurations and software versions against a database of known issues. A penetration test is a manual, human-led exercise where a skilled tester attempts to exploit vulnerabilities — including chaining multiple weaknesses, abusing business logic, and finding issues that no scanner has a signature for. A scan tells you what might be vulnerable; a pentest demonstrates what is actually exploitable.
Can a vulnerability scan replace a penetration test for ISO 27001 or SOC 2?
No. ISO 27001 and SOC 2 auditors distinguish between automated scanning and manual penetration testing. A vulnerability scan report is not accepted as a substitute for a penetration test. Both can coexist in a security program — scanning for ongoing hygiene, manual testing for periodic deep assessments — but the two serve different purposes and neither replaces the other.
What can a penetration test find that a vulnerability scanner cannot?
Manual penetration testers can find: business logic flaws, authentication bypasses that require understanding the application's intended behaviour, chained attacks where no single vulnerability is critical but the combination is, session management issues, insecure direct object references, and any vulnerability that requires creativity, context, or exploitation novel enough not to have a scanner signature.
How often should Australian businesses run vulnerability scans?
Continuous or weekly scanning is increasingly standard for Australian tech companies with cloud infrastructure. The Essential Eight recommends vulnerability scanning at least fortnightly. Scanning frequency should increase with the criticality of the systems being monitored. Penetration testing is separate and typically conducted annually or on significant change events.