Penetration Testing Methodology OWASP WSTG & PTES Explained

Penva Security uses OWASP WSTG v4.2 for web application and API testing (91 distinct test cases across 12 categories), and PTES (Penetration Testing Execution Standard) as the overall engagement framework (7 phases from pre-engagement through reporting). For mobile app testing we use OWASP MASVS; for LLM and AI testing we use the OWASP LLM Top 10. This combination is the standard CREST-aligned methodology Australian pentest firms use.

OWASP Web Security Testing Guide v4.2 is the de facto standard methodology for web application penetration testing. It defines 91 distinct test cases across 12 categories (authentication, authorisation, input validation, business logic, API testing and more). Every test maps to specific vulnerability classes and CWE identifiers, so findings produced under WSTG translate directly into auditor-recognised severity language. WSTG is what makes a pentest ‘real’ rather than a scanner output.

PTES (Penetration Testing Execution Standard) is the practitioner-authored framework that defines how an engagement actually unfolds – 7 phases from pre-engagement scoping through final reporting. Where OWASP WSTG defines *what to test* in web applications (the checklist), PTES defines *how the engagement runs* (the workflow). Both are used together: PTES is the engagement skeleton, OWASP WSTG is the testing flesh during the exploitation and analysis phases.

Yes. WSTG v4.2 is the current stable release, defining 91 test cases. OWASP maintains both a ‘stable’ release (v4.2) and an actively-developed ‘latest’ branch. Penva Security tests against v4.2 because it’s the version most auditors recognise. When WSTG v5 reaches stable release, we’ll transition – but for now, v4.2 is the auditor-accepted standard.

Yes, for specific scope. OWASP MASVS for mobile application testing. OWASP API Security Top 10 for API-specific testing. OWASP LLM Top 10 for AI and LLM-powered applications. NIST SP 800-115 as supporting documentation for US-regulated or US-adjacent engagements. MITRE ATT&CK for mapping findings to real-world adversary tactics in red team or threat-led engagements. OWASP WSTG and PTES are the spine; the others slot in based on what’s being tested.

AI accelerates the early phases – intelligence gathering (PTES Section 2) and parts of vulnerability analysis (Section 4) – at machine speed. Mapping the attack surface, fingerprinting technologies, identifying known-CVE matches, running thousands of payload variations. This frees CREST-certified human testers to spend their time on threat modelling, exploitation, post-exploitation and reporting – the phases where human judgment determines findings quality. AI handles breadth; humans handle depth.

Because compliance auditors specifically look for it. ISO 27001 Annex A.8.8 (vulnerability management), SOC 2 Trust Services CC7.1, PCI DSS v4.0.1 Requirement 11.4, and APRA CPS 234 paragraphs 27-28 all expect documented penetration testing methodology to be cited in the report. A pentest report without methodology citation is significantly less defensible at audit – and an increasingly common reason audits flag findings as inadequately validated.

Ask for a sample report. Real OWASP WSTG citations appear as ‘WSTG-IDNT-04’ or similar test-case IDs against findings. Real PTES citations describe engagement phases explicitly. A provider whose sample report doesn’t reference either is almost certainly running scanner output, not real testing. Penva Security’s reports cite WSTG test case IDs directly against each finding and structure the engagement narrative around PTES phases.