The term "VAPT" (vulnerability assessment and penetration testing) is common across ANZ vendor quotes, but the two services it references answer different questions, require different methodologies, and produce different compliance evidence. A vulnerability assessment is automated and broad. It scans your environment and returns a prioritised list of potential known weaknesses scored with CVSS, but it reports possibilities and carries a high false-positive rate. A penetration test is manual and deep. It actively exploits and chains weaknesses on a defined scope to prove real business impact, returning a smaller set of confirmed findings each with a working proof of concept.
The confusion costs ANZ organisations in three specific ways.
Mistake One: Submitting a VA Report to an Auditor as Penetration Test Evidence
This is the most common and most expensive mistake. Compliance audits verify whether controls are documented. Penetration testing verifies whether those controls actually work. An organisation can be fully compliant on paper and still have exploitable weaknesses.
SOC 2 service auditors, APRA supervisors, and ISO 27001 certification bodies do not accept vulnerability assessment output as penetration test evidence. The distinction is not bureaucratic. A vulnerability assessment tells an auditor which CVEs were detected in your environment. A penetration test tells an auditor which of those CVEs were confirmed exploitable, what access they produced, and whether the controls that should have prevented exploitation actually did.
The tell is in the report: findings phrased as "the target may be vulnerable to CVE-XXXX," a wall of CVSS scores with no exploitation narrative, no proof of concept, no chaining, and no account of what an attacker reached. If the report reads like a scanner output with a cover page, it is a vulnerability assessment. If it reads like an attack narrative with reproduction steps, proof-of-concept screenshots, and a confirmed impact statement, it is a penetration test.
For what compliance auditors specifically look for in a penetration test report and why the remediation evidence matters as much as the findings, the guide to continuous penetration testing for SOC 2 and ISO 27001 compliance covers the evidence structure that satisfies auditors across both frameworks.
Mistake Two: Using a CVSS Score to Prioritise Remediation
A CVSS score describes severity characteristics and can incorporate threat and environmental context, but a score does not prove that a specific vulnerability can be successfully exploited in a particular environment.
An organisation that remediates vulnerabilities by CVSS score order is patching what looks worst on a spreadsheet, not what is actually reachable and exploitable in its specific environment. A CVSS 9.8 critical in a library your application imports but does not call is lower actual risk than a CVSS 6.5 medium in a public-facing authentication endpoint that a tester confirmed is exploitable from an unauthenticated starting position.
Scanners cannot think like an attacker. They cannot find business logic flaws, chain vulnerabilities together, or tell you which findings actually put customer data at risk. The vulnerability assessment identifies the CVSS 9.8. The penetration test confirms whether it is exploitable in your environment and what an attacker can do with it. Both are necessary. Using only the VA score to prioritise remediation means engineering effort goes to the wrong findings first.
For ANZ organisations running remediation programmes under budget constraint, the guide to what happens after a penetration test covers how penetration test findings produce a prioritised remediation sequence based on confirmed exploitability rather than theoretical severity scores.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Mistake Three: Purchasing What Was Sold as a Pentest That Was Actually a VA
This mistake is harder to catch because both services can produce a report with similar headings. Penetration testing validates exploitability and demonstrates business impact: what an attacker achieves once a vulnerability is exploited. Vulnerability assessment gives a technical score without demonstrating real-world consequences.
A legitimate penetration test report contains: a defined scope with rules of engagement, a description of the testing methodology used (OWASP, NIST SP 800-115, PTES, or equivalent), individual findings with proof-of-concept evidence showing the vulnerability was exploited rather than merely detected, an attack chain narrative where relevant showing how multiple findings were combined, and an executive summary that describes the impact in business terms, not CVE identifiers.
A penetration test does not just say an issue exists. It shows whether the issue can be abused and what the realistic impact would be.
If the report you received lists CVE numbers and CVSS scores but contains no screenshots, no reproduction steps, no payload examples, and no description of what the tester reached after exploitation, ask the provider directly: was this a manual penetration test or an automated scan with analyst review?
The provider's answer will tell you whether you purchased the right service for your compliance requirement. CREST-accredited penetration testing providers operate under methodology standards that require proof-of-concept evidence for every confirmed finding. A report from a CREST-accredited firm that contains only scanner output and CVSS scores has not met those standards.
When to Use Each and How They Work Together
A vulnerability assessment is affordable, scalable, and repeatable. Most compliance frameworks require it quarterly at minimum. A penetration test is more resource-intensive because it involves manual analysis, exploitation attempts, attack path validation, and evidence-based reporting.
The two work together rather than substituting for each other. Continuous vulnerability scanning identifies the widest possible surface area of known weaknesses on a regular cadence. Annual or more frequent penetration testing validates which of those weaknesses an attacker can actually use and what they can reach. For ANZ organisations under APRA CPS 234, Essential Eight, SOC 2, or ISO 27001, both are components of a mature security testing programme. Neither replaces the other.
Book a scoping consultation to confirm whether your current testing programme produces the evidence your specific compliance framework requires.
Plan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Frequently Asked Questions
What is the difference between a vulnerability assessment and a penetration test in ANZ?
A vulnerability assessment scans your environment using automated tools and returns a prioritised list of potential known weaknesses scored with CVSS. It reports possibilities and carries a high false-positive rate. A penetration test manually exploits and chains weaknesses on a defined scope to prove real business impact, producing a smaller set of confirmed findings each with a working proof of concept. The assessment answers what might be wrong. The penetration test answers what an attacker can actually do. Most ANZ compliance frameworks require penetration testing evidence, not vulnerability assessment output, for annual testing obligations.
Will a vulnerability assessment satisfy SOC 2 or APRA CPS 234 auditors?
No. SOC 2 service auditors and APRA supervisors require penetration test evidence, not vulnerability assessment output. The distinction is that a vulnerability assessment tells an auditor which CVEs were detected. A penetration test tells an auditor which were confirmed exploitable, what access they produced, and whether controls that should have prevented exploitation actually did. The tell is in the report: findings phrased as "the target may be vulnerable" with CVSS scores but no exploitation narrative or proof of concept indicate a vulnerability assessment, not a penetration test.
How do I know if I received a vulnerability assessment or a penetration test?
Check the report for three things. First, does each finding include a proof of concept showing the vulnerability was exploited rather than merely detected? Second, does the report include an attack chain narrative showing how multiple findings were combined? Third, does the executive summary describe impact in business terms or in CVE identifiers? A legitimate penetration test report contains exploitation evidence and a confirmed impact statement. A vulnerability assessment report contains CVE numbers and CVSS scores. Ask your provider directly: was this a manual penetration test or an automated scan with analyst review?
Is a CVSS score the same as proof that a vulnerability is exploitable?
No. A CVSS score describes severity characteristics but does not prove a specific vulnerability can be successfully exploited in a particular environment. A CVSS 9.8 critical in a library your application imports but does not call may be lower actual risk than a CVSS 6.5 medium in a public-facing authentication endpoint that is confirmed exploitable from an unauthenticated position. Penetration testing provides exploit validation that shows which findings in your specific environment are reachable and exploitable. Using CVSS scores alone to prioritise remediation sends engineering effort to the wrong findings first.
Does a vulnerability assessment count as penetration testing for Australian compliance requirements?
No, for frameworks that specifically require penetration testing evidence. APRA CPS 234, SOC 2, PCI DSS Requirement 11.3, and ISO 27001 all require testing that validates control effectiveness through active exploitation testing, not automated scanning. A vulnerability assessment satisfies frameworks that require continuous vulnerability management, such as PCI DSS quarterly scanning requirements. It does not satisfy annual penetration testing obligations under the same framework or under APRA, SOC 2, or ISO 27001. Both are required and neither substitutes for the other.
