Penetration testing methodology

What is a penetration testing methodology?

It is the written plan for how a test is run: which phases happen in which order, what gets checked in each, and what each phase produces. A methodology is what makes two tests of the same system comparable, and what lets a reviewer check that nothing important was skipped.

Most firms build theirs on one or more public standards. PCI DSS v4.0.1 requirement 11.4.1 makes this formal for card data environments: the entity must define, document and implement a penetration testing methodology that includes "industry-accepted penetration testing approaches."

What are the phases of a penetration test?

The usual sequence has eight phases, and the middle ones loop. NIST SP 800-115 draws four (planning, discovery, attack, reporting) and notes in a footnote that there are many acceptable ways to group the work. The Penetration Testing Execution Standard (PTES, at pentest-standard.org) splits it into seven sections. The table below follows PTES and adds the retest, which PCI DSS 11.4.4 requires.

The loop matters. NIST describes a feedback path from attack back to discovery: new access reveals new systems, which get their own reconnaissance and analysis. A test that runs the phases once, in a straight line, stops at the first layer.

What does one finding look like as it moves through the phases?

Here is a single invented example from a gray-box test of a multi-tenant SaaS app at app.example.

1. Pre-engagement. The RoE lists app.example and api.example, two tenants, and an admin and a member account in each.
2. Reconnaissance. The JavaScript bundle references /api/v2/exports, which appears nowhere in the published API spec.
3. Threat modeling. Exports contain tenant data, so cross-tenant access to them is a top scenario.
4. Vulnerability analysis. The endpoint takes an export_id that looks sequential (export_3301, export_3302).
5. Exploitation. A member of tenant B requests export_3301, created by tenant A, and receives it. The finding is confirmed.
6. Post-exploitation. The tester checks whether the same flaw allows deletion, and whether an export includes session tokens or API keys. It allows neither, which caps the impact.
7. Reporting. One finding, with both requests, the missing tenant check named, and a fix in the shared authorization layer.
8. Retest. The original request now returns 404. The tester also tries the v1 path and a job ID from a different endpoint, both blocked.

Steps 2 and 6 are where methodologies differ most in practice. A checklist-only test would not have found the undocumented endpoint, and a test without post-exploitation would have reported the impact as unknown.

Which standards define penetration testing methodology?

Five are cited most often. They overlap but are not interchangeable: two are end-to-end processes, one is a web testing catalog, one is a security measurement method, and one is a model of attacker behavior.

A few details are worth knowing:

• PTES states that the standard itself gives no technical guidance on executing a test; that lives in a companion technical guide.
• The OWASP WSTG gives each test an ID such as WSTG-ATHZ-02 (bypassing authorization schema). Reports that cite these IDs show exactly which checks ran. Its 12 categories run from 4.1 Information Gathering to 4.12 API Testing.
• NIST SP 800-115 has not been revised since 2008, so its tool references are dated. Its phase model and Appendix B RoE template are still widely used; see rules of engagement.
• OSSTMM 3 replaced risk scoring with an attack surface metric (the "rav") and a Security Test Audit Report (STAR).
• MITRE ATT&CK describes itself as a knowledge base of adversary tactics and techniques based on real-world observations. It is not a test procedure. Testers use it to choose realistic scenarios and to label what they did, such as Initial Access, Privilege Escalation and Lateral Movement. FedRAMP's Penetration Test Guidance lists ATT&CK tactics as goals a test should attempt to attain.

For a web product, a common combination is PTES for the engagement structure, the WSTG and the OWASP API Security Top 10 for coverage, and ATT&CK for post-exploitation scenarios.

What does PCI DSS require a methodology to include?

Requirement 11.4.1 lists what the documented methodology must cover. In summary: industry-accepted approaches; the entire CDE perimeter and critical systems; testing from inside and outside the network; validation of segmentation and scope-reduction controls; application-layer testing for at least the vulnerabilities in requirement 6.2.4; network-layer testing of components that support network functions and operating systems; review of threats and vulnerabilities from the last 12 months; a documented approach to assessing the risk of what is found; and retention of results and remediation for at least 12 months.

That list is a reasonable test of any vendor's methodology, PCI or not. See internal vs external penetration testing for the inside and outside requirement.

Common mistakes

• Naming a standard in the proposal without saying which parts apply to this test.
• Skipping threat modeling, so effort spreads evenly across low-value and high-value features.
• Stopping at the first exploit with no post-exploitation, which understates impact.
• A retest that replays only the original request. Fixes often block one path and leave its neighbors open; see pentest retest.

Written by Parameter · Last reviewed September 27, 2026