Penetration Testing Methodologies Compared: PTES, NIST and OWASP

The methodology named in a pentest report should match the work. PTES or NIST SP 800-115 describe how a test as a whole is run; the OWASP Web Security Testing Guide covers testing a web application; OWASP ASVS is for verifying an application against a level of requirements; OWASP MASVS and MASTG cover mobile; and OSSTMM suits work that measures operational security. Most good reports name two: one for the engagement and one for the technical testing.

What the methodology section is for

A methodology section tells the reader how the test was done, so they can judge its coverage, compare it with last year’s, and understand what a clean result does and does not mean. Auditors read it for a more specific reason: PCI DSS, for one, requires a penetration testing methodology that is defined, documented and based on industry-accepted approaches, and a report that names none invites the question. PCI DSS penetration testing requirements covers what else that requirement asks.

Naming a standard is the easy part. The section is only useful if it also says how the standard was applied to this scope, which parts of it were in play, and what was left out.

PTES: the engagement end to end

The Penetration Testing Execution Standard, begun by a group of practitioners in 2009, describes a test in seven sections: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. Its strength is breadth. It treats scoping, rules of engagement and the report as part of the test rather than paperwork around it, which makes it a natural standard to cite for how an engagement was run.

Its technical guidance has not kept pace with modern environments, so on its own it says little about how a cloud account or a single-page application was tested. Pair it with a technical standard for the work itself.

NIST SP 800-115: assessment as a programme

NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, was published in September 2008 and has not been revised since. It covers review techniques, target identification and analysis, vulnerability validation, and the planning, execution and follow-up of an assessment, and it describes penetration testing in four phases: planning, discovery, attack and reporting.

It is widely recognised, particularly by organisations that already work to NIST guidance, and its four phases map cleanly onto most engagements. Its examples of tools and techniques show their age, so it reads best as the framework for the assessment rather than as the source of the tests.

OWASP: the technical standards

For applications, OWASP’s guides are the standards most reports cite, and they do different jobs:

• The Web Security Testing Guide (WSTG). A test procedure for web applications, organised into categories with an identifier for every test, such as WSTG-ATHN-01 for credentials over an encrypted channel. Version 4.2 is the current stable release, with version 5.0 in development, and the guide suggests a versioned form, WSTG-v42-ATHN-01, for citing a test from a particular release. Citing tests by identifier lets a reader see exactly what was covered.
• The Application Security Verification Standard (ASVS). Not a test procedure but a set of requirements, in three levels of increasing rigour. Version 5.0, released in May 2025, reorganised the requirements into seventeen chapters, and a requirement is cited with its version, as in v5.0.0-1.2.5. Use it when the client wants to know whether the application meets a level, rather than what an attacker could do.
• MASVS and MASTG. The Mobile Application Security Verification Standard sets the controls, in groups such as storage, cryptography, authentication and network communication, and the Mobile Application Security Testing Guide gives the tests for Android and iOS. Since version 2, MASVS has no levels of its own; the depth of testing is set by testing profiles instead.

The OWASP Top 10 is not on this list on purpose. It is an awareness document naming the most significant categories of web application risk, not a methodology, and a report that claims to have tested “to the OWASP Top 10” has said very little about what was tested. Mapping findings to Top 10 categories is still useful for the reader; the OWASP Top 10 2025 changes covers the current edition.

OSSTMM: measuring operational security

The Open Source Security Testing Methodology Manual, from ISECOM, is in its third version, published in 2010. It takes a more formal approach than the others, testing every channel in scope, human, physical, wireless, telecommunications and data networks, and expressing the result as a measure of operational security. It is cited less often in commercial testing, but suits engagements where the client wants a quantified view across channels rather than a list of findings.

What CHECK and CREST expect

In the UK, the two schemes buyers ask about treat methodology differently. Companies in the NCSC’s CHECK scheme follow the NCSC’s own penetration testing methodology, which the NCSC assesses, and CHECK reports state each risk as high, medium, low or informational. CREST’s Defensible Penetration Test, by contrast, says plainly that it does not define a methodology: each accredited company tests to its own accredited methodology, and the report is expected to state the scope with its exclusions, a timeline, and a statement of how completely the defined scope was covered. CHECK vs CREST covers the schemes themselves.

Either way, a public standard is rarely the whole of a firm’s methodology. It is the backbone a firm’s own documented approach is built on, and the report should say which.

Which to cite for which test

Kind of test	For the engagement	For the technical testing
Web application	PTES or NIST SP 800-115	OWASP WSTG, with an ASVS level if the client asks
API	PTES or NIST SP 800-115	OWASP WSTG, with findings mapped to the OWASP API Security Top 10
Mobile application	PTES or NIST SP 800-115	OWASP MASVS and MASTG
Internal or external infrastructure	PTES or NIST SP 800-115	The same, with your own documented test plan
Physical or multi-channel	OSSTMM	OSSTMM

Writing the methodology section

1. Name each standard and its version. “OWASP WSTG version 4.2”, not “OWASP”.
2. Say how it was applied. Which sections or test categories were in scope for this engagement, and from which position the testing was done.
3. Say what was not covered, and why. Tests excluded by the client, parts of the scope that were unreachable, and time limits. This protects the client from over-reading the result and protects you from being quoted on something you never touched.
4. Map findings back to the standard. A finding that names the test or requirement it came from can be traced, compared across years and checked by anybody who knows the standard.

Do not list standards you did not follow. A methodology section that names five standards to look thorough reads as exactly that to anybody who has written one. How to write a penetration test report covers where the section sits in the whole report.

Turning a methodology into coverage

A methodology named in the report is a promise about how the test was done, and the way to keep it is a checklist worked through during the test, one item per test or requirement, ticked as each is covered or recorded as not applicable. When a client later asks whether something was tested, the answer is a record rather than a recollection; proving what you tested when a client asks covers that conversation.