What is a penetration testing methodology?

A penetration testing methodology is the documented, repeatable procedure a testing firm follows to scope, execute, evidence and report a security test. It normally adopts public standards such as PTES, the OWASP WSTG and MASTG or NIST SP 800-115 and adds the firm's own quality gates and report format, so that coverage is explicit and results are comparable and auditable.

Which penetration testing methodology is best?

No single standard covers every target. PTES is the usual backbone for the engagement process, the OWASP WSTG supplies web and API test cases, the OWASP MASTG covers mobile, and NIST SP 800-115 provides the phase model US regulators reference. A mature vendor methodology combines them and states which standard supplies the checklist for each asset type.

What are the phases of a penetration test?

Most methodologies define seven phases: pre-engagement and scoping, threat modelling, intelligence gathering, vulnerability analysis, exploitation, post-exploitation and reporting with retest. NIST SP 800-115 compresses the same work into planning, discovery, attack and reporting. The names matter less than the inputs, outputs and evidence each phase produces.

Is PTES still relevant in 2026?

Yes. PTES has not changed substantially in years, but its seven-section structure remains the most widely adopted description of how an engagement should run. Firms pair it with actively maintained test-case standards such as the OWASP WSTG v4.2 and MASTG so the process stays stable while the test cases keep up with technology.

How can I tell whether a penetration test followed a methodology?

Read the report for a methodology statement with named standards and versions, a coverage matrix showing which test categories were executed and which were not applicable, standard identifiers on findings, CVSS vector strings, evidence per finding, a limitations section and named testers. A report with findings but no coverage statement cannot tell you what was not tested.

What is the difference between a penetration testing methodology and a vulnerability scan?

A vulnerability scan is one technique inside the vulnerability analysis phase; a methodology is the full procedure around it, including scoping, manual verification, exploitation, attack path analysis and reporting. A scan lists candidate weaknesses by signature; a methodology-driven test verifies them, chains them and states coverage.

2 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Penetration testing methodology: the standards, the phases, and how to verify your vendor actually followed one

Q: Does PCI DSS require a specific penetration testing methodology?

No. PCI DSS v4.0.1 Requirement 11.4.1 requires a documented methodology based on industry-accepted approaches without naming one, but it specifies what the methodology must cover: the cardholder data environment perimeter and critical systems, internal and external testing, segmentation validation, application and network layers, the previous twelve months' threats, and retention of results and remediation.

A penetration testing methodology is the documented, repeatable procedure a tester follows from scoping to retest, normally built on public standards such as PTES, the OWASP testing guides or NIST SP 800-115. This guide compares those standards, sets out the inputs, outputs and evidence of each phase, and shows how to tell a methodology-driven report from a scanner export.

Talk to a penetration tester

What a penetration testing methodology is, and why buyers should care

A penetration testing methodology is the structured set of phases, test cases, decision rules and reporting requirements that governs how a security test is scoped, executed and documented. It fixes in advance what will be examined and to what depth, how the tester decides a weakness is real and how far to take it, and what evidence ends up in the report. Without one, a penetration test is a talented person probing a system for a week. With one, it becomes a repeatable assessment whose coverage can be stated, compared with last year's test and defended in front of an auditor.

Three terms are used interchangeably and should not be. A standard is a public document maintained by an outside body (PTES, the OWASP Web Security Testing Guide, NIST SP 800-115, OSSTMM). A methodology is the testing firm's own procedure, which adopts one or more standards and adds scoping rules, quality gates and a report format. A checklist is what the tester works from on the day: the test cases of a standard mapped to the assets in scope. For US buyers the distinction has teeth. PCI DSS v4.0.1 Requirement 11.4.1 requires a documented methodology based on industry-accepted approaches, FedRAMP prescribes attack vectors, and an examiner under NYDFS Part 500 or the GLBA Safeguards Rule who asks how the test was performed expects a methodology statement, not a tool name. The definition of penetration testing and the plain-language overview of its seven phases live in our explainer, linked below; this page goes one level deeper.

The penetration testing standards that matter in 2026

Six public documents underpin most professional methodologies. Each was written for a different target and reader, which is why mature vendors combine them rather than pick one.

PTES (Penetration Testing Execution Standard)

Community-written, with seven sections: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. Target-agnostic, so it is the usual backbone for the engagement process; it says little about specific test cases for web or mobile.

OWASP Web Security Testing Guide (WSTG) v4.2

The reference for web application and API test cases. Version 4.2 organises more than ninety tests into categories from information gathering and authentication to business logic, client-side and API testing. Every test carries an identifier (for example WSTG-ATHZ-02) that a report can cite. Version 5 is in development.

OWASP MASTG and MASVS v2

The Mobile Application Security Testing Guide pairs with the Mobile Application Security Verification Standard, whose version 2 groups controls into storage, cryptography, authentication, network, platform interaction, code quality, resilience and privacy. The MASTG supplies the iOS and Android procedures that verify each control.

The NIST technical guide to security testing

NIST SP 800-115 is the US federal Technical Guide to Information Security Testing and Assessment (2008). Section 5.2 describes penetration testing as four phases: planning, discovery, attack and reporting, with attack looping back into discovery. Referenced by FedRAMP, CMMC assessors and US regulators, which is why US-facing reports cite it even when the test cases come from OWASP.

OSSTMM 3

ISECOM's Open Source Security Testing Methodology Manual takes a measurement-driven view: five channels (human, physical, wireless, telecommunications, data networks) and the RAV, a numeric expression of operational security that makes two tests of the same scope comparable. Version 3 dates from 2010 and no successor was finalised, but the channel model remains useful.

ISSAF and the PCI DSS Penetration Testing Guidance

The Information Systems Security Assessment Framework (OISSG) is unmaintained but still cited for linking each step to tooling and expected output. The PCI Security Standards Council's Penetration Testing Guidance supplement is not a methodology itself; it defines what a PCI test must cover (scope, segmentation, application and network layers, retest) and what the tester should be qualified to do.

Penetration testing methodologies compared

No single document covers scoping, test cases and reporting for every target type, which is why a vendor methodology normally layers two or three.

Standard	Maintained by and status	Scope it covers best	Role in a vendor methodology
PTES	Community; v1.0 plus technical guidelines, stable for years	The engagement process for any target	Backbone for phases, rules of engagement and report structure
OWASP WSTG v4.2	OWASP; actively maintained, v5 in progress	Web applications and web APIs	Test-case checklist and coverage matrix for application tests
OWASP MASTG / MASVS v2	OWASP; actively maintained	iOS and Android applications	Mobile test cases and verification levels (L1, L2, R)
NIST SP 800-115	NIST; 2008, still the referenced US federal guide	Network, system and application testing in a US regulatory context	Four-phase model cited for FedRAMP, CMMC, HIPAA and state regulators
OSSTMM 3	ISECOM; 2010, no successor finalised	Operational security across people, physical, wireless, telecom and networks	Channel model for scoping; comparable metrics between tests
ISSAF	OISSG; unmaintained	Infrastructure assessments	Historical reference and tooling map
PCI DSS Penetration Testing Guidance	PCI SSC supplement supporting Requirement 11.4	Cardholder data environment and segmentation	Mandatory coverage layered over PTES or NIST
CREST guidance and TIBER-EU	CREST member accreditation; ECB TIBER-EU, revised 2025 for DORA TLPT	Accredited programmes; intelligence-led red teaming of financial entities	Assurance layer for buyers; threat-led testing under DORA Articles 26 and 27

The engagement process, phase by phase

The plain-language walkthrough of the seven phases is in our explainer. Here the question is different: what must go into each phase, what should come out, and which artefact proves it happened. Use it as an acceptance checklist for the deliverables.

1. Pre-engagement and scoping

Inputs: the asset inventory in scope, the business purpose, compliance drivers that impose coverage (PCI DSS segmentation, FedRAMP vectors) and known fragile systems. Outputs: a signed scope and rules-of-engagement document with test windows, source IP addresses, escalation contacts and knowledge level (black, grey or white box). Evidence: the signed authorisation and scope referenced in the report.

2. Threat modelling

Often skipped, and the first thing a methodology-driven vendor adds back. Inputs: the business functions behind the assets, data classifications, trust boundaries and the attacker profiles that matter to you. Outputs: a prioritised list of what the tester will try hardest to reach, which decides where the consultant-days go. Evidence: a threat-model summary or attack-surface map that explains why effort went where it did.

3. Intelligence gathering and discovery

Inputs: the scope plus, for grey and white box tests, documentation, credentials and architecture diagrams. Outputs: an enumerated attack surface (hosts, services, technologies, roles, endpoints, third-party components) and a list of assets found outside the scope document. Evidence: an inventory appendix and a coverage matrix mapping WSTG or MASTG categories to each component. Without an inventory you cannot tell what was not tested.

4. Vulnerability analysis

Inputs: the enumerated surface and the applicable test cases. Outputs: candidate weaknesses, each verified by hand, with false positives removed and scanner output reconciled against manual work. Evidence: the methodology section states which scanners were used, which categories were executed manually and which were not applicable and why. A report that lists only tool output stopped here.

5. Exploitation

Inputs: verified weaknesses and the rules of engagement, in particular the exclusions (denial of service, destructive actions, production data changes). Outputs: demonstrated impact per finding, taken to proof of concept and no further. Evidence: request and response pairs, screenshots or command output, plus the CVSS v4.0 vector string behind each severity. Where exploitation was unsafe, the report should say so rather than inflate the score.

6. Post-exploitation and attack path analysis

Inputs: the footholds gained. Outputs: the chains that connect individual findings into business impact, privilege-escalation paths, and what sensitive data or systems were reachable. Evidence: the attack narrative, mapped to MITRE ATT&CK technique identifiers so your detection team can check which steps were visible in logs. This is where separate medium findings are correctly re-rated as one critical path.

7. Reporting, readout and retest

Inputs: everything above plus the audience list (board, engineering, auditor). Outputs: executive summary, findings with severity, evidence and remediation, the methodology and coverage statement, limitations and a retest plan. Evidence: the report, the readout and a retest letter confirming which findings were verified closed. PCI DSS 11.4.4 expects exploitable vulnerabilities to be corrected and retested; HackersHub includes a verification retest of medium and higher findings within 90 days.

Why the test cases change with the target: web, mobile, network, cloud, API and AI

The engagement process stays constant across targets; the test cases do not. A web application test draws its checklist from the OWASP WSTG and the OWASP Top 10. A mobile test replaces it with MASTG procedures and an agreed MASVS verification level. A network or Active Directory test leans on PTES and NIST SP 800-115 for structure and on MITRE ATT&CK for the technique catalogue, because no OWASP-style test list exists for infrastructure. Cloud testing has no single public standard: a credible methodology combines the provider's own rules (the AWS customer penetration testing policy, Microsoft's rules of engagement for Azure, Google Cloud's terms), the CIS Benchmarks for configuration review and the WSTG or PTES for the workloads on top. API testing adds the OWASP API Security Top 10 (2023); applications that embed large language models add the OWASP Top 10 for LLM Applications (2025). A vendor quoting one methodology for all six targets has described a process, not test cases. Ask which standard supplies the checklist for each asset type.

How a methodology shows up in the penetration test report

You rarely watch the test. The report is where the methodology appears or does not. A methodology-driven report contains these elements; a scanner export contains the first and the fifth at best.

A methodology statement naming the standards and versions used (for example 'OWASP WSTG v4.2, PTES, NIST SP 800-115'), the knowledge level and the test window
The signed scope with in-scope and out-of-scope assets listed explicitly, plus any assets discovered outside scope
A coverage matrix showing which standard categories were executed, which were not applicable and which could not be completed, with reasons
Findings that cite a standard identifier where one exists (WSTG-ATHN-04, MASVS-STORAGE-1) alongside a CWE or CVE reference
A CVSS v4.0 base score with the full vector string per finding, so severity can be independently recalculated
Evidence per finding and an attack narrative that links findings into chains, mapped to MITRE ATT&CK where relevant
A limitations section stating plainly which time, access or environmental constraints reduced coverage
Named testers with certifications, a documented peer review before release, and a retest section with closure criteria per severity

How to verify a penetration testing vendor actually follows a methodology

Every proposal claims a methodology. Six checks separate a documented procedure from a slide, and the answers show how the firm will behave when something goes wrong mid-test.

Ask for the methodology document, not the brochure

A real methodology has phase definitions, entry and exit criteria, the standards adopted per target type, evidence requirements and a report template. A vendor should walk you through it under NDA. A one-page graphic with seven icons means the methodology lives in the tester's memory.

Request a redacted sample report and look for the coverage matrix

Check for the elements listed above, especially a statement of what was not tested. Firms that work from a methodology document gaps without embarrassment, because a gap is a scoping decision.

Ask how a non-applicable test category is recorded

A tester running the WSTG against an API with no browser client should mark the client-side category as not applicable and say why. A vendor who cannot describe this is not tracking coverage. For mobile, ask which MASVS level they test to and how it is agreed in scoping.

Ask who tests, who reviews, and whether both are named

Expect a named lead tester with current certifications (OSCP as a baseline; OSWE, OSEP or CREST registrations for specialist work) and a second person who reviews findings and severity before release. Reports signed only with a company name make accountability impossible.

Ask what happens when a critical finding appears on day two

A methodology defines the escalation: who is called, within what time, what is written down, and whether testing continues on that component. The answer should match the rules-of-engagement document they propose.

Ask how the methodology maps to the frameworks you report to

For PCI DSS, how scoping covers 11.4.1 through 11.4.7 including segmentation. For FedRAMP, how the required attack vectors are covered. For SOC 2 or ISO 27001, how the report lets the auditor trace control to evidence. A vendor who has done this before has the mapping ready.

Penetration testing standards and compliance: what each framework expects

US frameworks differ in how prescriptive they are. PCI DSS v4.0.1 is the most explicit: Requirement 11.4.1 requires a documented, industry-accepted methodology that covers the cardholder data environment perimeter and critical systems, tests from inside and outside, validates segmentation, addresses application-layer and network-layer weaknesses, reviews the previous twelve months' threats and retains results and remediation; 11.4.2 and 11.4.3 set the annual cadence and 11.4.5 and 11.4.6 govern segmentation testing. FedRAMP's penetration test guidance for Rev. 5 prescribes attack vectors and a report format under control CA-8. NYDFS 23 NYCRR 500.5 and the GLBA Safeguards Rule (16 CFR 314.4(d)(2)) require annual penetration testing and leave the method to professional judgement. HIPAA 45 CFR 164.308(a)(8) requires periodic technical evaluation, CMMC 2.0 Level 2 inherits NIST SP 800-171 control CA.L2-3.12.1, and SOC 2 evaluations under CC4.1 and CC7.1 rely on a test whose coverage is stated.

The EU pattern is similar. ISO 27001:2022 controls A.8.8 and A.8.29 are evidenced through testing whose scope and method the auditor can follow, NIS2 Article 21(2)(f) requires policies to assess the effectiveness of security measures, and DORA Article 25 names penetration testing while Articles 26 and 27 define threat-led testing under TIBER-EU. One well-documented methodology serves all of these if the scope statement maps assets to each framework.

How HackersHub applies its penetration testing methodology

Our methodology is aligned with PTES for the engagement process, the OWASP WSTG and MASTG for application and mobile test cases, and NIST SP 800-115 for the phase model US regulators reference. Every tester holds at least OSCP, with OSWE and CREST-certified testers on the team, and the lead tester is named in the report. Scoping is custom per engagement and fixed in writing before testing starts. Reports contain an executive summary, CVSS-scored findings with evidence, an attack narrative and prioritised remediation, written so your compliance team can trace each finding to the framework it reports under. A verification retest of medium and higher findings within 90 days is part of every engagement. We deliver for clients in the EU and the US from Amsterdam, remotely by default and on site where the scope needs it.

Frequently asked questions

Related guides and services

Want a penetration test whose methodology you can audit?

We scope every engagement in writing, test to PTES, OWASP and NIST SP 800-115, name the testers in the report and include a verification retest. Talk to a penetration tester about your scope.

Scope a penetration test Schedule a call