Penetration Testing Methodology Explained: Frameworks, Phases, and Why It Matters

Why Methodology Is Not Just Process Theater

When a penetration testing provider says they follow a methodology, most buyers nod and move on. It sounds like a formality -- a box to check on the proposal. In practice, methodology is what separates a thorough, repeatable assessment from an ad-hoc exercise where the tester runs their favorite tools and writes up whatever they find.

A defined methodology ensures coverage -- every relevant attack surface is tested, not just the ones the tester happens to think of. It ensures consistency -- two engagements of the same scope produce comparable results regardless of which tester is assigned. And it ensures auditability -- when a compliance auditor asks "how was this test conducted," there is a documented answer that maps to a recognized framework.

For buyers, understanding the major methodologies helps you evaluate whether a provider's approach is rigorous and whether it aligns with your compliance requirements.

The Major Frameworks

Four penetration testing methodologies dominate the industry. Each has a different focus, level of detail, and community behind it.

OWASP Testing Guide

Focus: Web application security testing.

The Open Worldwide Application Security Project (OWASP) maintains the most widely referenced web application testing methodology in the industry. The OWASP Testing Guide (currently version 4.2, with version 5 in development) provides a comprehensive catalog of tests organized into functional categories.

The guide covers 11 categories of testing:

• Information gathering -- Technology fingerprinting, application mapping, identifying entry points and data flows.
• Configuration and deployment management -- Testing infrastructure configuration, file handling, HTTP methods, and administrative interfaces.
• Identity management -- User registration, account provisioning, account enumeration, and account policies.
• Authentication -- Credential transport, default credentials, lockout mechanisms, authentication bypass, MFA implementation, and password recovery.
• Authorization -- Directory traversal, privilege escalation, insecure direct object references, and access control bypass.
• Session management -- Session token analysis, cookie attributes, session fixation, CSRF, and session timeout.
• Input validation -- XSS, SQL injection, LDAP injection, XML injection, SSI injection, command injection, buffer overflow, and HTTP parameter pollution.
• Error handling -- Error code analysis, stack trace exposure, and information leakage through error messages.
• Cryptography -- Weak transport layer security, padding oracle vulnerabilities, and sensitive data exposure.
• Business logic -- Workflow bypass, data validation, integrity checks, timing attacks, and upload functionality abuse.
• Client-side -- DOM-based XSS, JavaScript execution, HTML injection, CSS injection, client-side URL redirect, and resource manipulation.

Strengths: Extremely detailed test cases with specific procedures for each test. Free and openly available. Maintained by a large community of security professionals. The de facto standard for web application testing.

Limitations: Focused exclusively on web applications. Does not cover network, infrastructure, or Active Directory testing. The sheer number of test cases (over 90) means that applying the full guide to every engagement is impractical -- testers must prioritize based on the application's risk profile and technology stack.

For a deeper exploration of how we apply the OWASP Testing Guide in practice, see our OWASP testing methodology deep dive.

PTES (Penetration Testing Execution Standard)

Focus: End-to-end penetration testing process.

PTES defines the complete penetration testing engagement lifecycle, from pre-engagement interactions through reporting. Unlike OWASP, which focuses on what to test, PTES focuses on how to run a penetration testing engagement from start to finish.

PTES defines seven phases:

1. Pre-engagement interactions -- Scoping, rules of engagement, authorization, communication plans, and legal considerations.
2. Intelligence gathering -- OSINT, active reconnaissance, and target profiling across multiple layers (infrastructure, organizational, and human).
3. Threat modeling -- Identifying high-value assets, mapping threat agents, and prioritizing attack vectors based on the target's specific risk profile.
4. Vulnerability analysis -- Active and passive vulnerability identification, including automated scanning and manual review, with a focus on validation and false positive elimination.
5. Exploitation -- Attempting to exploit identified vulnerabilities using precision targeting, custom exploit development, and evasion techniques appropriate to the engagement scope.
6. Post-exploitation -- Assessing the value of compromised systems, identifying sensitive data, establishing persistence, and pivoting to additional targets to demonstrate the full impact of a breach.
7. Reporting -- Executive and technical reporting with findings, evidence, risk ratings, and remediation recommendations.

Strengths: Comprehensive coverage of the entire engagement process, not just the technical testing. The threat modeling phase is particularly valuable -- it forces the tester to think strategically about what matters most to the target organization. PTES is methodology-agnostic regarding specific test cases, so it works across web, network, wireless, and social engineering engagements.

Limitations: The standard has not been formally updated in several years, though its process framework remains sound. It is less prescriptive about specific tests than OWASP, which means a provider claiming to follow PTES could be doing anything from a thorough assessment to a minimal one.

For a comparison of PTES and NIST approaches, see our pentest standards comparison.

NIST SP 800-115

Focus: Technical security testing for federal and regulated environments.

NIST Special Publication 800-115, "Technical Guide to Information Security Testing and Assessment," provides the US government's guidance on security testing. While written for federal agencies, its influence extends across any organization that aligns with the NIST framework.

SP 800-115 categorizes technical security testing into three types:

• Review techniques -- Documentation review, log review, ruleset review, and system configuration review. These are non-invasive examinations of existing security controls.
• Target identification and analysis -- Network discovery, service identification, vulnerability scanning, and wireless scanning. This category maps roughly to the reconnaissance and vulnerability analysis phases of other frameworks.
• Target vulnerability validation -- Password cracking, penetration testing, social engineering, and application security testing. This is where active exploitation occurs.

The publication places penetration testing within a broader security assessment context rather than treating it as a standalone activity. It emphasizes that penetration testing should be informed by risk assessment results and should target the areas of highest risk.

Strengths: Carries the weight of NIST authority, which matters for federal agencies and organizations in regulated industries. Provides a clear framework for integrating penetration testing into a broader security assessment program. The planning and reporting guidance is thorough and well-structured.

Limitations: Less technically detailed than OWASP or PTES for specific attack techniques. The publication was last updated in 2008, and while the core process remains valid, many specific technical recommendations are outdated. Organizations following NIST typically supplement SP 800-115 with OWASP or PTES for technical depth.

OSSTMM (Open Source Security Testing Methodology Manual)

Focus: Security measurement and operational security testing.

The OSSTMM, maintained by ISECOM, takes a fundamentally different approach from the other frameworks. Rather than providing a list of attacks to try, OSSTMM focuses on measuring the security of a system through its operational characteristics. It defines security testing across five channels: human, physical, wireless, telecommunications, and data networks.

The methodology centers on the concept of "attack surface" -- quantifying the actual exposure of a target rather than simply listing vulnerabilities. OSSTMM introduces metrics for measuring security posture, including the "rav" (Risk Assessment Value) that attempts to produce a quantitative security score.

Strengths: The measurement-oriented approach provides more nuanced results than a simple vulnerability list. OSSTMM's emphasis on operational security testing (including physical and human channels) makes it relevant for comprehensive security assessments. The quantitative scoring model appeals to organizations that want to track security improvement over time.

Limitations: The methodology is complex and less intuitive than OWASP or PTES. Adoption is lower, which means fewer testers are trained in it and fewer compliance frameworks reference it. The quantitative scoring, while conceptually valuable, can be difficult to implement consistently.

How They Compare

Aspect	OWASP	PTES	NIST 800-115	OSSTMM
Scope	Web applications	Full engagement lifecycle	Security assessment	All security channels
Detail level	Very high (90+ tests)	Process-focused	Moderate	High (measurement)
Last major update	2022 (v4.2)	2014	2008	2010 (v3)
Best for	Web app testing	Engagement management	Regulated environments	Quantitative assessment
Compliance alignment	PCI DSS, SOC 2	General	NIST CSF, FedRAMP	General
Adoption	Very high	High	High (gov/regulated)	Moderate
Free/open	Yes	Yes	Yes	Version 3 paid

Phases of a Methodology-Driven Assessment

Regardless of which framework a provider follows, a competent penetration test moves through five distinct phases. The methodology determines how rigorously each phase is executed.

Phase 1: Reconnaissance

The tester maps the target environment to understand its attack surface. This includes DNS enumeration, network scanning, service identification, technology fingerprinting, and OSINT gathering. The quality of reconnaissance directly determines the quality of the subsequent testing -- a tester who skips thorough reconnaissance will miss attack surfaces entirely.

Methodology impact: PTES and OSSTMM provide the most structured guidance for reconnaissance. OWASP covers web-specific information gathering in detail. A provider following a methodology will document their reconnaissance findings systematically rather than just running nmap and moving on.

Phase 2: Enumeration

Building on reconnaissance, the tester deeply enumerates discovered services, applications, and infrastructure. This includes version detection, configuration analysis, user enumeration, and mapping of application functionality and data flows.

For web applications, enumeration means crawling every page, identifying all input vectors, mapping API endpoints, understanding authentication flows, and profiling each user role's capabilities. For networks, it means detailed service fingerprinting, SMB enumeration, SNMP walks, and Active Directory reconnaissance.

Phase 3: Exploitation

The tester attempts to exploit identified vulnerabilities to gain unauthorized access. This is where methodology matters most for quality. A methodology-driven tester follows a systematic approach -- testing each identified vulnerability rather than jumping to the first exploitable finding.

Exploitation in a professional pentest is controlled and documented. Every exploit attempt is logged. Successful exploitation produces evidence (screenshots, command output, data samples) that goes into the report. The tester avoids destructive actions and communicates immediately if testing causes unexpected impact.

For context on how professional testers handle exploitation evidence safely, see our guide on proof-of-concept evidence and safe red-teaming.

Phase 4: Post-Exploitation

After gaining initial access, the tester explores what an attacker could achieve from that foothold. This includes:

• Privilege escalation -- Moving from a standard user account to administrator or root access on the compromised system.
• Lateral movement -- Pivoting from the compromised system to other systems in the network.
• Data access -- Identifying and documenting sensitive data accessible from the achieved access level.
• Persistence -- Assessing whether an attacker could maintain access across reboots and password changes (typically demonstrated conceptually rather than actually implemented, to avoid leaving backdoors).

Post-exploitation is the phase that most clearly demonstrates business impact. Finding a SQL injection vulnerability is a technical finding. Using that SQL injection to extract the customer database, pivot to an internal application server, and escalate to domain admin is a business risk narrative that resonates with leadership.

Phase 5: Reporting

The final phase translates all testing activity into a documented deliverable. Methodology-driven reporting follows a consistent structure that serves both technical and non-technical audiences. The report should map findings to the methodology's framework, providing traceability between what was tested and what was found.

Every major methodology requires thorough documentation of findings with evidence, severity ratings, and remediation guidance. The difference between a methodology-driven report and an ad-hoc one is the systematic coverage -- the reader can see not just what was found, but what was tested and found to be secure.

For detailed guidance on evaluating report quality, see our guide on what a pentest report should include.

Why Methodology Matters for Compliance

Compliance frameworks increasingly require not just that penetration testing was performed, but that it followed a recognized methodology.

PCI DSS Requirement 11.4 explicitly requires that penetration testing methodology is documented and follows an industry-accepted approach. The PCI Council's Information Supplement on penetration testing references NIST SP 800-115, OWASP, and PTES as acceptable methodologies.

SOC 2 auditors evaluating CC7.1 will ask about the methodology used for security testing. A provider that cannot articulate their methodology or map their approach to a recognized framework raises questions about testing rigor.

ISO 27001 auditors assessing A.18.2.3 (technical compliance review) expect testing to follow a structured approach. The methodology documentation becomes part of the evidence package for the control.

FedRAMP and FISMA assessments require alignment with NIST SP 800-115 for penetration testing activities.

When evaluating providers, ask not just "what methodology do you follow?" but "how do you apply it to my specific scope, and what does coverage look like?" A provider that claims to follow OWASP but only tests half of the categories is not actually following the methodology.

Choosing the Right Methodology for Your Engagement

For most organizations, the methodology question resolves itself based on the engagement type:

• Web application testing -- OWASP Testing Guide as the primary framework, with PTES process structure for engagement management.
• Network and infrastructure testing -- PTES for overall methodology, supplemented with NIST SP 800-115 for regulated environments.
• Comprehensive security assessment -- PTES or OSSTMM for the overall framework, with OWASP for the web application components.
• Federal/government -- NIST SP 800-115 as the primary framework, supplemented with OWASP for application-layer testing.

The best providers do not rigidly follow a single methodology. They use recognized frameworks as their foundation and supplement with professional judgment, current threat intelligence, and deep expertise in the specific technologies they are testing.

Next Steps

Understanding methodology helps you evaluate providers and set expectations for your engagement. For a practical view of how these methodologies translate into an actual engagement, read what to expect from a penetration test.

If you are ready to define the scope for a penetration testing engagement, our PT Scoping Wizard helps you capture the details that providers need to produce accurate proposals based on the methodology appropriate for your environment.

Review our security assessment services to learn how CyberShield applies these methodologies in practice.