Penetration testing methodology: PTES, OSSTMM, NIST SP 800-115 and OWASP WSTG

A penetration testing methodology is a written method for planning, running and reporting a pentest. Four are named most often: PTES, NIST SP 800-115, OSSTMM and the OWASP Web Security Testing Guide (WSTG). They differ in age, scope and purpose. This page compares them with their real status, as checked on 9 November 2026.

What is a penetration testing methodology, and what does it not give you?#

A methodology tells a tester what steps to follow and what to check. It does not tell you how good the tester is or how strong the evidence will be. Two providers can both say "we follow OWASP" and deliver very different reports.

No law or standard we read names one required method. PCI DSS 11.4.1 asks that the method is "defined, documented, and implemented" (PCI SSC Summary of Changes, May 2022). FedRAMP's v3 guidance asks that the rules of engagement follow NIST SP 800-115, Appendix B (as quoted in our 2026-11-08 research; we did not re-read the compressed PDF text). Beyond those, buyers and auditors set their own bar. Cobalt says its testers use OWASP lists for web, API, mobile, AI/LLM and cloud work, and OSSTMM for internal and external network tests (Cobalt, State of Pentesting 2025, p.31). That mix is normal.

Which phases do nearly all methods share?#

Almost every method moves through the same stages, with different names and detail. This table uses our five-stage wording and shows where each framework covers it.

NIST SP 800-115 describes four phases: planning, discovery, attack and reporting. PTES lists seven sections, from pre-engagement to reporting. Retest is missing from the main outline of all three, so ask for it in the scope. See after the pentest.

What does PTES cover, and what is its status?#

PTES is the Penetration Testing Execution Standard, a community outline with seven sections: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation and reporting. Its pre-engagement section covers scope, rules of engagement and permission.

Its status is weak. On 9 November 2026 the live PTES site refused our connection. The 2026-11-08 research read Internet Archive captures from December 2024 and January 2025 whose pages were last edited on 14 August 2014. We could not re-open the archive on 9 November. Call PTES "a community methodology last edited in 2014", not a current standard.

One PTES line has aged. It says the client's permission does not cover third-party providers. Cloud providers now publish their own testing policies. AWS says customers may test their own infrastructure for listed services "without prior approval", while testing that includes command and control needs prior approval (AWS Penetration Testing policy). Read the provider's policy, then put it in your rules of engagement. See rules of engagement.

What does NIST SP 800-115 cover, and how old is it?#

NIST SP 800-115 is the "Technical Guide to Information Security Testing and Assessment". NIST published it in September 2008 and still lists it as final, with no revision, draft or withdrawal notice on the page we checked. It covers more than pentesting: review techniques, target identification and analysis, target vulnerability validation (which includes penetration testing) and assessment planning.

Its Appendix B is the reason it appears in government work. It sets out rules of engagement and says the test team leader and senior management should sign the ROE (quoted in our 2026-11-08 research, not re-read). Say "published in 2008 and still listed as final". Do not call it a current NIST requirement, because we found no rule that makes it one for ordinary commercial buyers.

What do OSSTMM and OWASP WSTG cover?#

OSSTMM is the Open Source Security Testing Methodology Manual from ISECOM. ISECOM hosts a 213-page PDF named OSSTMM.3.pdf. The pages are scanned images with no readable text, and we could not confirm the publication year or author. It measures operational security and attack surface, which suits network and physical tests more than web apps.

The OWASP WSTG is a free list of web and API test cases, grouped by category. The stable release is v4.2. The OWASP project page says version 5.0 is under development, and the "latest" branch is not a release. For a web app, the WSTG is the most useful of the four because it gives concrete test cases that a client can check against a report. Pair it with the OWASP Top 10:2025 for risk categories and the OWASP API Security Top 10 for APIs.

How do the four compare?#

Which methodology should you ask a provider for?#

Match the method to the target and to who will read the report.

What does a framework leave out?#

No framework above sets an evidence standard, a stop rule, or safety limits for your production data. Those come from the provider. Ask three questions: what proves a finding, what happens when something outside scope looks relevant, and what controls run beside each exploit request.

Our own answers are on the methodology page: a finding needs evidence of a real effect, controls that held are reported as well, and destructive proofs use test-owned accounts and records. The sample report shows the layout. For the wider definition, read what is penetration testing. For how much the tester knows in advance, read black box, grey box and white box testing.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report