PTES: Penetration Testing Execution Standard
The Penetration Testing Execution Standard (PTES) is a community-developed technical framework that defines the phases, processes, and minimum requirements for conducting a penetration test. It establishes a consistent methodology across the profession, applicable to network, application, and physical security engagements. Understanding PTES is essential for service seekers evaluating provider rigor, procurement teams specifying deliverables, and practitioners benchmarking their methodology against an industry baseline.
Definition and scope
PTES is a structured, seven-phase methodology published by a working group of security professionals to standardize how penetration tests are scoped, executed, and reported. Unlike certification-based frameworks tied to a single credentialing body, PTES is an open-community standard, publicly accessible at ptes.org, and is not administered by a government agency or standards body. Its scope extends across external and internal network assessments, web application testing, social engineering engagements, and physical intrusion testing — making it one of the broader methodological references in the field.
PTES operates alongside, not in competition with, regulatory mandates. Frameworks such as PCI DSS v4.0, Requirement 11.4 and NIST SP 800-115, Technical Guide to Information Security Testing and Assessment require periodic penetration testing but do not prescribe a specific execution methodology. PTES fills that procedural gap, providing testers and clients with a shared vocabulary and a repeatable process that supports compliance documentation. The Penetration Testing Providers resource on this site reflects providers whose engagements are typically conducted under named methodologies including PTES, OWASP Testing Guide, and OSSTMM.
PTES is not a certification pathway, an accreditation program, or a regulatory requirement. Its authority derives from professional adoption rather than statutory mandate.
How it works
PTES divides a penetration test into 7 discrete phases, each with defined inputs, activities, and outputs:
- Pre-engagement interactions — Scope definition, rules of engagement, authorization documentation, and statement of work. This phase produces the legal foundation for the engagement and establishes what systems, networks, and techniques are in scope.
- Intelligence gathering — Open-source intelligence (OSINT) collection, network reconnaissance, organizational research, and technical enumeration of exposed assets. This mirrors the reconnaissance phase of a real-world adversary.
- Threat modeling — Mapping collected intelligence to threat actor profiles, attack surfaces, and business-impact scenarios. Testers prioritize attack vectors based on likelihood and consequence.
- Vulnerability analysis — Identification of technical weaknesses through active scanning, manual inspection, and service enumeration. This phase classifies findings by exploitability, not just existence.
- Exploitation — Controlled, authorized attempts to exploit identified vulnerabilities. PTES distinguishes exploitation from vulnerability scanning by requiring that testers confirm actual exploitability, not just theoretical exposure — consistent with NIST SP 800-115's definition of penetration testing as actively circumventing security controls.
- Post-exploitation — Assessment of the impact achievable after successful compromise, including lateral movement, privilege escalation, data access analysis, and persistence evaluation. This phase quantifies business risk.
- Reporting — Documentation of findings, evidence, risk ratings, and remediation guidance. PTES specifies that reports address both executive audiences and technical remediation teams, with findings mapped to business impact.
The Penetration Testing Provider Network Purpose and Scope page provides additional context on how methodology adherence factors into provider classification within this reference.
Common scenarios
PTES is applied across 4 primary engagement categories:
External network penetration tests use PTES phases 1 through 7 against internet-facing infrastructure — web servers, VPN endpoints, email gateways, and firewall perimeters. This is the most common engagement type for organizations entering compliance programs under PCI DSS or HIPAA Security Rule (45 CFR § 164.306).
Internal network penetration tests simulate a threat actor already inside the network perimeter — modeling insider threats, compromised endpoints, or post-phishing scenarios. PTES post-exploitation guidance is particularly relevant here, directing testers to enumerate Active Provider Network structures, credential stores, and lateral movement paths.
Web application tests combine PTES intelligence gathering and exploitation phases with application-specific techniques from the OWASP Testing Guide. PTES does not replace OWASP for application-layer testing but provides the engagement scaffolding within which OWASP techniques operate.
Social engineering engagements — phishing, vishing, and physical intrusion — fall within PTES scope under the intelligence gathering and exploitation phases. CISA references social engineering as a recognized attack vector in critical infrastructure assessments, making PTES-framed social engineering tests relevant to sectors including energy, water, and healthcare.
Decision boundaries
PTES is the appropriate methodological reference when an engagement requires a documented, phase-structured process that supports compliance reporting, client deliverables, and scope management. It is less suited — or must be supplemented — in 3 specific circumstances:
Application-only engagements benefit from OWASP Testing Guide or OWASP WSTG as the primary technical reference, with PTES providing pre-engagement and reporting structure. PTES does not enumerate application vulnerability classes at the depth OWASP does.
Red team operations, which involve extended simulation of advanced persistent threat (APT) actor behavior, often use PTES as a baseline but extend it with adversary emulation frameworks such as MITRE ATT&CK. PTES is a penetration testing standard, not an adversary simulation framework — the distinction matters for scope documentation.
Regulated federal environments subject to NIST Risk Management Framework (SP 800-37) or FedRAMP may require testing against controls enumerated in NIST SP 800-53, which PTES does not directly map. Practitioners operating in these environments must cross-reference PTES phases against NIST control families.
The How to Use This Penetration Testing Resource page covers how methodology references including PTES are applied within this network's provider classification criteria.
PTES and OSSTMM (Open Source Security Testing Methodology Manual) represent the two most widely cited open methodologies in the field. OSSTMM emphasizes measurement and quantification of security posture, while PTES emphasizes operational process and phase sequencing — making PTES the more common reference for client-facing engagement documentation.