PTES: Penetration Testing Execution Standard

The Penetration Testing Execution Standard (PTES) is a community-developed framework that defines a structured, phase-based methodology for conducting professional penetration tests. It establishes consistent baseline expectations across the full lifecycle of an engagement — from pre-engagement authorization through final reporting — and is referenced alongside NIST guidelines for penetration testing and the OWASP Testing Guide as one of three widely recognized methodological anchors in the US penetration testing sector.

Definition and scope

PTES emerged from collaboration among penetration testing practitioners who identified the absence of a unified execution standard as a systemic gap in professional practice. Unlike ISO/IEC 27001, which governs information security management systems, or PCI DSS penetration testing requirements, which mandate testing outcomes, PTES addresses the operational mechanics of how a test is conducted. Its scope is practitioner-facing: it defines what a qualified tester must do at each phase, not what an organization must achieve for compliance purposes.

The standard covers 7 discrete phases:

Pre-Engagement Interactions — scope definition, authorization documentation, rules of engagement
Intelligence Gathering — open-source and technical reconnaissance
Threat Modeling — adversary profiling and asset prioritization
Vulnerability Analysis — identification of exploitable weaknesses
Exploitation — active attack simulation against confirmed vulnerabilities
Post-Exploitation — pivot actions, persistence establishment, data access evaluation
Reporting — documentation of findings, risk ratings, and remediation guidance

PTES is maintained as a public-access resource at pentest-standard.org and carries no formal certification body or regulatory mandate. Its authority derives from practitioner adoption and alignment with how security firms structure client engagements. The penetration testing methodology page covers broader methodological comparisons across competing frameworks.

How it works

A PTES-aligned engagement begins before any technical activity with the Pre-Engagement Interactions phase, which establishes the legal and operational foundation. This phase produces the authorization agreement, defines target scope (IP ranges, application URLs, physical locations), specifies time windows, and identifies emergency escalation contacts. Without this documentation, subsequent phases lack legal grounding under 18 U.S.C. § 1030 (the Computer Fraud and Abuse Act), which criminalizes unauthorized computer access regardless of intent (DOJ guidance on the CFAA).

Intelligence Gathering under PTES maps to passive and active reconnaissance in penetration testing — OSINT collection, DNS enumeration, service fingerprinting, and employee profiling where social engineering is in scope. The Threat Modeling phase distinguishes PTES from simpler frameworks by requiring the tester to construct an adversary model: what class of attacker is being simulated, what their likely objectives are, and which assets represent the highest-value targets.

Vulnerability Analysis feeds directly into exploitation techniques, where PTES explicitly requires demonstrated exploitation rather than theoretical identification. This is the defining boundary between a penetration test and a vulnerability assessment — a distinction formalized in NIST SP 800-115, which separates "examination" and "testing" as methodologically distinct activities.

Post-exploitation techniques under PTES assess what an attacker can achieve after initial access: credential harvesting, lateral movement, privilege escalation, and data exfiltration simulation. The Reporting phase closes the engagement with two distinct deliverable tracks — an executive summary for non-technical stakeholders and a technical findings document with reproduction steps, evidence, and risk severity ratings aligned to CVSS scoring.

Common scenarios

PTES applies across engagement types, though its phase structure is most directly aligned with network and application-layer testing:

External network assessments — PTES governs the full attack chain from perimeter reconnaissance through internal pivot attempts, consistent with network penetration testing standards
Web application engagements — the exploitation and post-exploitation phases align with OWASP Top 10 attack categories; web application penetration testing practitioners frequently cross-reference both PTES and the OWASP Testing Guide within a single engagement
Red team operations — red team operations extend PTES by incorporating physical access, social engineering, and multi-vector campaigns; PTES provides the underlying phase structure even when the engagement scope exceeds its original design parameters
Compliance-driven assessments — organizations subject to HIPAA penetration testing requirements or FedRAMP authorization use PTES as an operational template while mapping outputs to regulatory control families

PTES is less commonly applied to specialized domains such as SCADA/ICS penetration testing or IoT penetration testing, where sector-specific guidance from bodies like ICS-CERT and ISA/IEC 62443 carries greater operational weight.

Decision boundaries

PTES vs. OWASP Testing Guide: PTES covers the full engagement lifecycle across all target types. The OWASP Testing Guide is scoped exclusively to web applications and provides granular test case procedures at the vulnerability category level. Practitioners conducting web application penetration testing routinely use both — PTES for engagement structure and OWASP for test case specificity.

PTES vs. NIST SP 800-115: NIST SP 800-115 is a federal government publication oriented toward assessors working within or for US federal agencies. PTES was designed for the commercial practitioner market with no sector restriction. For engagements under FedRAMP or FISMA scope, NIST SP 800-115 carries regulatory alignment that PTES does not.

PTES vs. OSSTMM: The Open Source Security Testing Methodology Manual (OSSTMM), published by ISECOM, applies a quantitative risk measurement model that produces a numeric security score. PTES does not produce a scored output; findings are rated by severity but not aggregated into a single metric. Organizations requiring audit-grade quantitative outputs may favor OSSTMM for that deliverable.

The absence of a certification body or formal auditing mechanism for PTES means that a firm claiming "PTES-aligned" methodology carries no third-party verification of compliance with the standard. Procurement teams reviewing penetration testing contracts should request phase-by-phase methodology descriptions rather than relying on framework name citations alone.

References

📜 2 regulatory citations referenced · 🔍 Monitored by ANA Regulatory Watch · View update log

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator