Introduction
Run three penetration tests with three different vendors and you'll likely get three different reports:
- One tester spends two weeks on network scanning and barely touches the application layer
- Another skips post-exploitation entirely because "the client didn't ask for it"
- A third delivers a 200-page report with no clear remediation priorities
This inconsistency isn't rare. It's the default when penetration testing has no shared methodology behind it.
The Penetration Testing Execution Standard (PTES) exists to fix that. It's a vendor-neutral, community-built framework that breaks a security assessment into seven defined phases, from initial scoping through final reporting.
This guide covers what PTES actually includes, how its seven phases work, and how it stacks up against OWASP, NIST, and OSSTMM. We'll also cover where it runs out of road, particularly for organizations testing AI systems.
Key Takeaways
- PTES is a vendor-neutral standard built since 2009 to standardize pentesting engagements
- Its seven phases span scoping, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting
- This framework offers more depth than NIST's baseline guidance and broader scope than niche standards like OWASP
- Built before the AI boom, PTES doesn't address AI-specific risks like prompt injection or RAG exploitation
What is the Penetration Testing Execution Standard (PTES)?
PTES is a seven-section, community-developed methodology that outlines the steps a penetration tester follows when researching, qualifying, and attacking a target system. Rather than a tool or a checklist to tick off in an afternoon, it's a structured process meant to standardize how engagements get scoped, executed, and reported.
This methodical structure didn't happen by accident. Work on PTES started early in 2009, when a group of information security practitioners recognized there was no complete, up-to-date penetration testing standard available. The effort grew from roughly six founders to nearly 20 practitioners at its first in-person meeting, representing financial institutions, service providers, and security vendors.
Contributors have included well-known names in the field like Chris Nickerson, Dave Kennedy, and Nick Percoco.
What makes PTES different from a simple outline:
- Maintained as an open, freely accessible resource under the GNU Free Documentation License
- Includes separate Technical Guidelines covering recommended tools, reconnaissance techniques, exploitation approaches, and reporting formats
- Functions as both a process framework (what to do, in what order) and a hands-on technical reference (how to do it)
That combination is why PTES gets adopted as a backbone methodology rather than just a reference document sitting in a compliance binder.
The Seven Phases of PTES: A Complete Breakdown
PTES splits every engagement into seven sequential phases. Each phase builds on the intelligence and access gained in the one before it, so skipping a step doesn't just create a gap in the report. It weakens everything that follows.
Phase 1: Pre-Engagement Interactions
This is where scope, timelines, and rules of engagement get locked down before anyone touches a keyboard. Testers and clients agree on:
- Testing boundaries and what's explicitly off-limits
- Communication protocols and incident escalation procedures
- Contracts, statements of work, and written permission to test
The goal is to define objectives clearly, prioritizing security outcomes over compliance checkboxes, so scope doesn't creep once testing begins.
Phase 2: Intelligence Gathering
Testers use OSINT and reconnaissance to map the client's infrastructure, people, and business relationships. This includes passive collection (public records, domain data) and active footprinting (network ranges, exposed services).
PTES distinguishes engagement types by how much information the tester starts with:
- Black box — little to no advance information, simulating an outside attacker
- White box — full infrastructure and application knowledge provided upfront
- Grey box — partial knowledge provided, the most common real-world approach though not formally defined in PTES documentation
Phase 3: Threat Modeling
Here, testers identify and categorize the assets worth attacking and the threat actors most likely to target them. Inputs include business policy, R&D data, and infrastructure design. The output is a prioritized map of where the simulated attack should actually focus, rather than a scattershot approach that treats every system as equally valuable.
Phase 4: Vulnerability Analysis
Testers actively and passively scan systems, ports, and applications to surface exploitable flaws, misconfigurations, insecure application design, and injection points among them. PTES emphasizes validation at this stage: confirming a finding is genuinely exploitable rather than a false positive before it moves to the next phase.
Phase 5: Exploitation
Validated vulnerabilities get actively attacked in a controlled manner. PTES is explicit that exploitation should connect directly to the engagement's objectives, using precision rather than indiscriminate attacks. Testers balance stealth, speed, and both depth and breadth of access gained.
Phase 6: Post-Exploitation
Once a system is compromised, testers assess its actual business value. What data lives there, what other systems it connects to, and how far an attacker could realistically move all matter here.
This phase covers pillaging, persistence, further penetration paths, and cleanup. Testers stay within pre-agreed boundaries throughout, so the assessment never crosses into real damage.
Phase 7: Reporting
The final phase compiles everything into a document built for two audiences at once. An executive summary translates technical findings into business risk for leadership.
A detailed technical report goes deeper for engineers, covering scope, attack narrative, findings, risk ratings, and a remediation roadmap they can act on.
Why Organizations Rely on PTES
PTES gets adopted because it solves a specific problem: inconsistency. A few reasons it sticks around as a backbone methodology:
- Full lifecycle coverage: Seven phases guide testers from business context through exploitation and reporting, reducing the risk of skipping critical steps under time pressure
- Comparability across engagements: CREST notes that PTES creates a common language and scope, making it easier to compare results across vendors and testing cycles
- Zero licensing cost: Being free and community-maintained means any organization or independent tester can adopt it without a procurement hurdle
PTES vs. Other Penetration Testing Standards
PTES works as a broad baseline applicable across most testing scenarios. Other frameworks trade that breadth for depth in a specific niche.
| Framework | Scope | Best used for |
|---|---|---|
| PTES | Full engagement lifecycle, general purpose | Backbone methodology for most pentest engagements |
| OWASP Testing Guide | Web applications, APIs, IoT (via a separate guide) | Deep, specialized web/API testing |
| NIST SP 800-115 | Federal technical guidance, published 2008 | Minimum regulatory baseline, especially government contexts |
| OSSTMM | Metrics-driven operational security, including physical and human channels | Organizations needing quantified security metrics beyond digital systems |
OWASP Testing Guide is purpose-built for web applications and APIs, with a separate IoT-specific guide. It goes deeper on those fronts than PTES does, but it skips network infrastructure and business context entirely.
NIST SP 800-115 is a technical guide finalized in 2008 for planning and conducting security assessments, primarily aimed at federal agencies. Regulators tend to accept it more readily than OSSTMM, though it's generally treated as a minimum baseline rather than a comprehensive methodology.
OSSTMM takes a scientific, metrics-driven approach, using its own Risk Assessment Value calculations across human, physical, wireless, and data network channels. It covers physical and social testing in ways PTES simply doesn't emphasize.
Most mature security programs use PTES as the backbone and layer in OWASP or industry-specific guides when testing a specialized system, rather than picking one framework and ignoring the others. Vynox Security's own engagements follow this same layered logic, pairing PTES's full-lifecycle structure with AI-specific testing for LLMs, RAG pipelines, and autonomous agents.
Where PTES Falls Short: The AI Security Gap
PTES was built for the infrastructure and application landscape of 2009: networks, web apps, servers. That's years before large language models, retrieval-augmented generation pipelines, and autonomous agents became part of the modern attack surface.
None of the seven phases account for AI-native risks such as:
- Prompt injection : where crafted inputs alter an LLM's intended behavior or output, potentially triggering unauthorized actions
- Jailbreaks : inputs designed to bypass a model's safety controls entirely
- Model data leakage : unintended disclosure of sensitive training or output data
- Insecure agent tool-calling : where an autonomous agent's access to external tools becomes an attack vector
Searches across PTES's official documentation turn up zero mentions of these terms. That's not a knock on PTES. It's simply a documentation gap created by timing. Organizations shipping AI products need testing that extends PTES-style rigor, structured phases, clear reporting, defined remediation, into the AI stack specifically.
This is the exact gap Vynox Security was built to close. Rather than treating AI testing as a bolt-on, Vynox runs a two-layer methodology. A primary layer covers LLMs, RAG pipelines, autonomous agents, and model inversion. A supporting layer covers web, mobile, cloud, network, and API infrastructure, so nothing in the stack goes unchecked.
Every AI engagement includes:
- Full OWASP LLM Top 10 coverage, with dedicated service lines mapped to categories like prompt injection (LLM-01), RAG data exfiltration (LLM-06), agent hijacking (LLM-08), and model inversion (LLM-10)
- 40+ prompt injection and jailbreak techniques, spanning direct injection, indirect injection via documents and tool outputs, role-play exploits, and multi-turn attack chains
- Developer-ready findings mapped to SOC 2, ISO 27001, ISO 42001, and EU AI Act Article 15 controls, similar in spirit to PTES's structured reporting phase but built for AI-specific compliance requirements
For teams shipping LLM features on a compliance deadline, or a board asking for adversarial assurance on a high-risk AI system, that gap between PTES's traditional scope and today's AI attack surface matters. It's exactly where a dedicated AI security testing program needs to sit.
Frequently Asked Questions
Who created PTES and when was it established?
PTES work began in early 2009, led by a group of information security practitioners who wanted a comprehensive, up-to-date penetration testing standard. The effort grew from about six founding contributors to nearly 20 practitioners at its first meeting.
Is PTES still relevant today?
Yes. While the standard was created in 2009, its seven-phase structure and Technical Guidelines remain widely referenced because they still apply cleanly to most traditional infrastructure and application testing.
What's the difference between PTES and the OWASP Testing Guide?
PTES is a broad, general-purpose methodology covering the entire engagement lifecycle. OWASP's guide focuses specifically on web application, API, and (via a separate guide) IoT security testing.
Do penetration testers have to follow all seven PTES phases exactly?
No. PTES offers a flexible baseline, and testers adjust the depth of each phase based on client scope, engagement goals, and system complexity.
How does PTES compare to NIST SP 800-115?
NIST SP 800-115 is generally treated as a minimum regulatory standard, especially in government contexts. PTES builds well beyond those basics, covering business context, threat modeling, and post-exploitation in more depth.
Does PTES cover AI, LLM, or RAG pipeline security testing?
No. PTES predates modern generative AI systems and doesn't address risks like prompt injection or agent exploitation. That gap is why Vynox Security runs a separate AI security testing methodology covering LLMs, RAG pipelines, and autonomous agents alongside traditional PTES-based infrastructure testing.
