Penetration Testing Methodology: PTES, OWASP and the Rest
- A named methodology is what makes a test auditable - it defines what should have been covered, so gaps become visible.
- PTES defines the shape of an engagement; OWASP WSTG defines what to actually test in a web application.
- OSSTMM and NIST SP 800-115 matter mostly when a specific auditor or contract names them.
- Ask which methodology a vendor follows, then ask which parts they skipped and why. The second answer is the informative one.
A penetration testing methodology is a published, ordered list of what a test should cover. Its real function is not to make testers better - it is to make a test auditable, because a methodology defines what SHOULD have been done, which is the only way anyone can tell what was left out. For the basic definition, see what is penetration testing.
Four are worth knowing. Two describe how an engagement runs, and two describe what to test.
PTES: the shape of an engagement
The Penetration Testing Execution Standard defines seven phases: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting.
Its contribution is that it treats the boring stages as part of the method. Pre-engagement - agreeing scope, rules of engagement, and what happens if the tester gains access to real data - is where most disappointing engagements actually go wrong, and PTES makes it a phase rather than an email thread.
Post-exploitation is the other phase worth noticing. It asks how far an initial foothold reaches, which is the difference between "this endpoint is vulnerable" and "this endpoint gives an attacker your customer database".
OWASP WSTG: what to test
The OWASP Web Security Testing Guide is the closest thing the field has to a checklist for web applications. It works through categories - configuration, identity management, authentication, authorisation, session management, input validation, error handling, cryptography, business logic, client-side - and lists specific tests within each.
This is the one to ask about for application testing, because it is granular enough to reveal gaps. "We follow OWASP" is a weak claim; "we cover the WSTG authorisation and business-logic sections, and here is what we do within them" is a real one.
A related note on the OWASP Top 10: it is an awareness document listing the most prevalent categories of risk. It is genuinely useful for prioritisation and it is not a test plan. A test that covers only the Top 10 has covered ten categories, not an application. OWASP also publishes OWASP ASVS, a separate verification standard some teams scope testing against.
OSSTMM and NIST SP 800-115
The Open Source Security Testing Methodology Manual is broader and more formal, covering physical and human channels alongside the technical ones, with its own metrics for operational security. It appears mostly where a contract or an auditor names it.
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, is the reference US federal work tends to point at. Same situation: you follow it because someone requires it, not because it will change what a good tester does.
| Methodology | Defines | Reach for it when |
|---|---|---|
| PTES | How an engagement runs, in seven phases | You want the process to be auditable end to end |
| OWASP WSTG | What to test in a web application | Application and API testing - the granular one |
| OSSTMM | Technical, physical and human channels | A contract or auditor names it |
| NIST SP 800-115 | Assessment planning and execution | US federal or NIST-aligned programmes |
What a methodology cannot do
It cannot supply judgment. Every one of these documents tells a tester where to look and none of them can tell whether what they found matters in your business. A checklist-complete test that missed the discount code you can apply twice has followed the method and failed the purpose.
The useful question is never "do you follow a methodology". It is "which methodology, and which parts did you skip on my engagement, and why". A vendor who cannot answer the second half is describing a marketing position rather than a process.
Where compliance comes in
Several frameworks expect penetration testing as evidence, and they vary in how prescriptive they are about method and about who performs the test. PCI DSS Requirement 11.4 is the clearest case, requiring testing outright and setting out tester qualification separately. Others treat it as expected practice without naming a methodology at all.
We keep that framework-by-framework position on the compliance hub rather than summarising it into a single claim, because the differences are the entire point.
Frequently asked questions
What is the most widely used penetration testing methodology?
For engagement structure, PTES - the Penetration Testing Execution Standard, with its seven phases. For deciding what to actually test in a web application, the OWASP Web Security Testing Guide. Most credible application engagements reference both.
Is the OWASP Top 10 a testing methodology?
No. The Top 10 is an awareness document listing the most prevalent risk categories. It is useful for prioritisation but it is not a test plan - a test covering only the Top 10 has covered ten categories, not an application. The OWASP WSTG is the testing document.
Why does a named methodology matter?
Because it makes the test auditable. A methodology defines what should have been covered, so anyone reading the report can see what was skipped. Without one, you are trusting a tester's instincts, which may be excellent but cannot be reviewed or compared.
Do compliance frameworks require a specific methodology?
Mostly no. Frameworks vary from requiring testing outright with separate rules on tester qualification, through to treating it as expected practice without naming a method. We set out the position per framework rather than generalising.