PTES, NIST SP 800-115, and OSSTMM: Penetration Testing Standards Compared

Why Standards Matter in Penetration Testing

A penetration test without a methodology is just someone running tools against your systems. The methodology is what transforms a collection of tool outputs into a structured, repeatable, and defensible assessment of your security posture.

Standards matter for three reasons. First, they ensure comprehensive coverage. Without a framework guiding the engagement, testers tend to focus on the areas they are most comfortable with and skip areas they are less familiar with. A standard forces systematic coverage of the entire attack surface. Second, standards provide a common language between the tester, the client, and the auditor. When your compliance framework requires penetration testing, the auditor needs to verify that the testing was thorough. A recognized standard provides that verification. Third, standards enable comparison. If two different firms test the same application using the same standard, the results should be comparable in scope even if the findings differ based on tester expertise.

The three most widely referenced penetration testing standards are PTES (Penetration Testing Execution Standard), NIST SP 800-115, and OSSTMM (Open Source Security Testing Methodology Manual). Each serves a different audience and purpose. Understanding their differences helps you select the right standard for your compliance requirements and evaluate whether your testing provider is following a rigorous methodology.

For web application-specific testing, the OWASP Testing Guide is the dominant standard and is covered in detail in our OWASP testing methodology deep dive. This article focuses on the broader penetration testing standards that encompass network, infrastructure, and application testing.

PTES: The Penetration Testing Execution Standard

Overview

PTES is an industry-driven standard created by penetration testers for penetration testers. It was developed by a consortium of security professionals to define what a thorough penetration test looks like from scoping through reporting. PTES is the most practitioner-oriented of the three standards and is widely adopted by commercial penetration testing firms.

The Seven Phases

PTES organizes a penetration test into seven sequential phases:

1. Pre-engagement Interactions

This phase covers everything that happens before testing begins: scope definition, rules of engagement, authorization documentation, communication plans, emergency contacts, and legal protections for both parties. PTES is unusually thorough here, recognizing that most engagement failures are caused by poor scoping rather than poor testing.

Key elements include:

• Defining target IP ranges, domains, and applications explicitly
• Establishing testing windows and blackout periods
• Agreeing on communication channels for critical findings
• Documenting what actions are authorized (exploitation, social engineering, physical access)
• Setting the testing type (black-box, gray-box, white-box)

2. Intelligence Gathering

PTES distinguishes between passive and active intelligence gathering. Passive intelligence uses publicly available information -- OSINT, WHOIS records, DNS enumeration, social media, job postings, leaked credentials -- without directly interacting with the target's systems. Active intelligence gathering involves direct interaction: port scanning, service fingerprinting, web application crawling.

The standard emphasizes that intelligence gathering should inform the testing strategy. A target that runs a modern cloud-native architecture requires different testing techniques than a target running legacy on-premises infrastructure. The intelligence gathering phase determines which tools, techniques, and attack vectors are most likely to yield results.

3. Threat Modeling

PTES includes a formal threat modeling phase where the tester identifies the most likely attack paths based on the intelligence gathered. This is where the tester thinks strategically rather than tactically: given what we know about this target, what would a real attacker pursue? What are the high-value assets, and what are the most probable paths to reach them?

This phase prevents the common mistake of testing everything equally. A well-executed threat model focuses the engagement on the attack paths that represent the highest risk to the organization, ensuring that the most impactful testing happens regardless of time constraints.

4. Vulnerability Analysis

The vulnerability analysis phase systematically identifies weaknesses in the target environment. PTES distinguishes between active vulnerability scanning (running tools against the target) and passive analysis (reviewing configuration files, source code, or architecture documentation provided by the client).

This phase also includes correlation -- combining multiple low-severity findings to identify whether they create a higher-severity attack path. A misconfigured firewall rule that allows internal network access from the DMZ, combined with a default credential on an internal management interface, represents a critical finding even though each individual issue might be rated medium severity.

5. Exploitation

Exploitation is the phase that distinguishes a penetration test from a vulnerability assessment. The tester attempts to exploit identified vulnerabilities to demonstrate their real-world impact. PTES provides detailed guidance on exploitation techniques across multiple categories:

• Network service exploitation
• Web application attacks
• Wireless attacks
• Physical security testing
• Social engineering

The standard emphasizes precision in exploitation: the goal is to achieve specific objectives that demonstrate business impact (accessing sensitive data, escalating privileges, pivoting to internal networks), not to cause maximum disruption.

6. Post-Exploitation

Post-exploitation is one of PTES's most valuable contributions. After initial access is achieved, the tester determines the value of the compromised system and uses it as a platform for further testing:

• What sensitive data is accessible from this system?
• Can this access be used to reach other systems (lateral movement)?
• Can persistence be established that would survive a reboot or credential change?
• What is the actual business impact of this level of access?

Many testing standards stop at initial exploitation. PTES's post-exploitation phase ensures that the full impact of a vulnerability is demonstrated, giving the client an accurate picture of what an attacker could achieve rather than just what door they could open.

7. Reporting

PTES defines a detailed reporting structure with two distinct audiences: executive leadership and technical teams. The executive summary communicates business risk in language that non-technical stakeholders can act on. The technical report provides the detailed evidence, reproduction steps, and remediation guidance that the development and operations teams need.

When to Use PTES

PTES is the best choice when:

• You need a comprehensive methodology that covers the full engagement lifecycle
• The engagement includes network, infrastructure, and application testing (not just web apps)
• Your auditor or compliance framework requires evidence of a recognized testing methodology
• The engagement includes exploitation and post-exploitation phases
• You want a standard that is widely understood by commercial penetration testing firms

Limitations

PTES has not been formally updated since its initial release, though the community maintains supplementary technical guides. For web application testing specifically, PTES defers to OWASP as the more detailed standard. Organizations that need only web application testing may find PTES overly broad for their requirements.

NIST SP 800-115: Technical Guide to Information Security Testing and Assessment

Overview

NIST Special Publication 800-115 is published by the National Institute of Standards and Technology and provides guidance on the technical aspects of information security testing. Unlike PTES, which is a practitioner-driven standard, NIST SP 800-115 is a government publication designed to support federal agencies and organizations that must comply with NIST frameworks (NIST 800-53, NIST CSF, FedRAMP, CMMC).

Structure

NIST SP 800-115 organizes security testing into three categories:

Review Techniques

Documentation review, log review, ruleset review, and system configuration review. These are passive activities that examine the security posture through existing artifacts rather than active testing. NIST gives significant weight to review techniques because government environments often have extensive documentation and policy requirements.

Target Identification and Analysis Techniques

This category covers the active discovery phase: network scanning, port scanning, vulnerability scanning, and wireless scanning. NIST SP 800-115 is less prescriptive than PTES about specific tools and techniques, focusing instead on the objectives and risk management considerations for each testing activity.

Target Vulnerability Validation Techniques

This is where NIST addresses actual penetration testing, password cracking, social engineering, and exploitation. The standard uses the term "target vulnerability validation" rather than "penetration testing" to emphasize that the purpose is validating whether identified vulnerabilities are exploitable, not conducting an open-ended attack simulation.

Key Characteristics

Risk-focused approach. NIST SP 800-115 emphasizes risk management throughout the testing process. Every testing activity should be evaluated against its potential to disrupt operations or compromise data. The standard provides detailed guidance on managing testing risks, including pre-test planning, coordination with operational staff, and incident response procedures for testing-related issues.

Integration with NIST frameworks. SP 800-115 is designed to support the broader NIST ecosystem. Testing results map directly to NIST 800-53 security controls and NIST Cybersecurity Framework categories. This mapping is valuable for organizations that use NIST as their primary compliance framework.

Government and regulated industry focus. The language, structure, and recommendations in SP 800-115 are tailored to government agencies and regulated industries. The standard acknowledges the need for formal authorization, chain-of-custody documentation, and evidence preservation that government environments require.

When to Use NIST SP 800-115

NIST SP 800-115 is the right reference when:

• Your organization must comply with NIST 800-53, FedRAMP, CMMC, or NIST CSF
• You operate in a government or government-adjacent environment
• Your compliance framework specifically references NIST testing guidance
• You need testing results that map directly to NIST security controls
• Your organization values the risk management and authorization procedures that NIST emphasizes

For organizations that need to map penetration testing findings to compliance frameworks beyond NIST, our article on compliance mapping across NIST, CIS, and ISO covers the cross-framework alignment.

Limitations

NIST SP 800-115 was published in 2008 and has not been revised. While the fundamental principles remain sound, the specific technical guidance does not reflect modern attack techniques, cloud environments, containerized infrastructure, or API-first architectures. Organizations that follow NIST SP 800-115 typically supplement it with more current standards like OWASP and PTES for specific testing areas.

The standard is also less prescriptive about exploitation and post-exploitation techniques than PTES, making it less useful as an operational guide for testers. It is better understood as a framework for planning and managing security testing programs than as a step-by-step testing methodology.

OSSTMM: Open Source Security Testing Methodology Manual

Overview

OSSTMM (currently version 3) takes a fundamentally different approach from PTES and NIST. Rather than prescribing specific testing techniques, OSSTMM defines a metrics-based methodology for measuring operational security. Its focus is on quantifying security rather than finding individual vulnerabilities.

The RAV Model

OSSTMM's defining contribution is the RAV (Risk Assessment Values) model, which attempts to quantify security posture using measurable metrics:

• Attack Surface: The total number of potential points of interaction between the target and an attacker
• Controls: The security measures in place (authentication, access control, encryption, etc.)
• Limitations: Factors that reduce the effectiveness of controls (vulnerabilities, misconfigurations, weak implementations)

The RAV score is calculated as the relationship between attack surface, controls, and limitations. A positive RAV indicates that controls exceed the attack surface -- the target is over-protected. A negative RAV indicates that the attack surface exceeds controls -- the target has security gaps.

Five Channels

OSSTMM organizes testing across five channels that represent the different ways information flows between the target and the outside world:

1. Human Security -- social engineering, policy compliance, security awareness
2. Physical Security -- physical access controls, environmental protections
3. Wireless Communications -- WiFi, Bluetooth, RFID, NFC
4. Telecommunications -- voice systems, PBX, voicemail, fax
5. Data Networks -- the traditional network and application testing that PTES and NIST focus on

This multi-channel approach is OSSTMM's strength for organizations that need to assess security holistically rather than focusing exclusively on technical controls.

When to Use OSSTMM

OSSTMM is appropriate when:

• You need a metrics-based approach to measuring security posture over time
• Your assessment must cover physical, human, and wireless security in addition to data networks
• You want quantifiable security measurements rather than qualitative finding lists
• Your organization values repeatability and consistency across assessments performed by different teams

Limitations

OSSTMM's metrics-based approach is its greatest strength and its greatest weakness. The RAV model provides a quantitative measurement of security posture, but the abstraction required to produce that measurement can obscure the specific, actionable findings that most organizations need. A RAV score tells you that your security posture has improved, but it does not tell you that your password reset flow is vulnerable to token prediction.

OSSTMM is also less widely adopted than PTES or OWASP in the commercial penetration testing market. Fewer firms use it, fewer auditors recognize it, and fewer clients request it. This does not diminish its technical merit, but it affects its practical utility for compliance purposes.

Comparing the Standards

Aspect	PTES	NIST SP 800-115	OSSTMM
Primary audience	Pentest practitioners	Government/regulated orgs	Security assessors
Approach	Phase-based methodology	Risk-managed testing guide	Metrics-based measurement
Scope	Network + app + social eng	IT infrastructure testing	All security channels
Exploitation depth	Deep (includes post-exploitation)	Moderate (validation focus)	Varies by channel
Reporting style	Exec summary + technical detail	NIST control mapping	RAV scores + findings
Web app testing	Defers to OWASP	General guidance	Data networks channel
Compliance mapping	General industry	NIST 800-53, FedRAMP, CMMC	ISO 27001, general
Last major update	2014 (community maintained)	2008	2010 (v3)
Adoption	Widely used commercially	Government standard	Niche adoption

Which Standard Should Your Pentest Follow?

For PCI DSS Compliance

PCI DSS requires penetration testing that follows "an industry-accepted penetration testing methodology." PTES and NIST SP 800-115 are both explicitly recognized. For the web application testing component, PCI DSS Requirement 6.2 references OWASP. The combination of PTES for the overall engagement structure and OWASP for application-specific testing is the most common approach for PCI DSS compliance.

For SOC 2 Audits

SOC 2 does not mandate a specific methodology, but auditors expect to see evidence of a recognized standard. PTES is the most commonly referenced methodology in SOC 2 penetration test reports. The key is that the report demonstrates systematic coverage and maps findings to the Trust Services Criteria rather than presenting an unstructured list of tool outputs.

For Government and FedRAMP

NIST SP 800-115 is the baseline reference. Testing results must map to NIST 800-53 controls, and the engagement must follow NIST's risk management and authorization procedures. FedRAMP specifically requires annual penetration testing following NIST guidance, with results documented in the Plan of Action and Milestones (POA&M).

For DORA and NIS2

EU regulations reference "recognized international standards" without mandating a specific one. PTES is widely accepted in the European market. For DORA's threat-led penetration testing (TLPT) requirements, the ECB's TIBER-EU framework provides the most specific guidance, which builds on top of established standards like PTES.

For General Best Practice

If no specific compliance requirement dictates your choice, PTES provides the most comprehensive and practical engagement framework. Supplement it with OWASP for web application testing, and you have a methodology that covers the full engagement lifecycle with depth in the areas that matter most for modern applications.

How to Verify Your Pentester Follows a Standard

Knowing which standards exist is only half the equation. You also need to verify that your testing provider actually follows one rather than just claiming to. Here are the indicators to look for:

In the proposal:

• The methodology is named explicitly, not described vaguely as "industry best practices"
• The phases of the engagement map to the named standard's structure
• The scope definition follows the standard's pre-engagement requirements
• Testing activities are described in terms of the standard's categories, not just tool names

In the report:

• Findings reference specific test cases or categories from the named standard
• The report structure matches the standard's reporting requirements (PTES requires executive and technical sections; NIST requires control mapping)
• Evidence includes reproduction steps, not just scanner output
• Coverage notes indicate which categories were tested and which were out of scope, with justification

Red flags:

• The report is entirely automated scanner output with no manual testing evidence
• No methodology is referenced, or the methodology claim does not match the report structure
• All findings are rated by CVSS alone with no contextual risk assessment
• Business logic, authentication, and authorization testing are absent despite being in scope

For a deeper look at what a quality engagement looks like end-to-end, see our article on penetration testing methodology explained.

Building a Standards-Based Testing Program

The most effective testing programs do not rely on a single standard. They layer multiple standards to achieve comprehensive coverage:

1. PTES provides the engagement lifecycle framework -- from scoping through reporting
2. OWASP Testing Guide provides the detailed web application testing methodology within PTES's vulnerability analysis and exploitation phases
3. NIST SP 800-115 provides the risk management and authorization framework for organizations with government or regulatory requirements
4. OSSTMM provides the metrics framework for organizations that need to track security posture quantitatively over time

This layered approach ensures that testing is comprehensive, methodical, and aligned with whatever compliance requirements apply to your organization.

Next Steps

If you are evaluating penetration testing providers, the methodology question is one of the most important factors in your decision. A firm that follows a recognized standard and can demonstrate that adherence in their proposals and reports will deliver significantly more value than one that relies on tool-driven testing without a methodological foundation.

Our penetration testing engagements follow PTES for the overall engagement structure and OWASP for web application testing, with NIST control mapping available for organizations with government compliance requirements. To scope an engagement that follows these standards, start with our penetration testing scoping wizard or explore our services page to understand how our methodology-driven approach delivers higher-quality results.