The Penetration Testing Execution Standard (PTES), Explained

Ask five penetration testing vendors what methodology they follow and you will hear “industry standard” five times. Ask which standard, and the answers get vague. The Penetration Testing Execution Standard (PTES) is the one that most rigorous firms actually build their process on, and understanding it is the fastest way to tell a real penetration test from an automated scan with a cover page. This guide explains what PTES is, walks through its seven phases, compares it to the other frameworks you will hear named, and shows what to ask a vendor.

What is the Penetration Testing Execution Standard?

PTES is an open, community-written standard that defines what a penetration test should include from the first scoping conversation to the final report. It was created by a group of security practitioners who were frustrated that “penetration test” meant wildly different things from one vendor to the next, and it is published freely at pentest-standard.org.

Its purpose is not to prescribe specific tools or commands. It defines the phases every engagement should pass through, the minimum expectations for each phase, and the outputs a client should receive. That makes it as useful to buyers as to testers: if a proposal cannot be mapped to the PTES phases, something is missing.

PTES also publishes technical guidelines that go deeper into the how of each phase, but the seven-phase structure is the part that matters for evaluating an engagement.

The seven phases of PTES

1. Pre-engagement interactions

Everything that happens before testing starts: scope definition, rules of engagement, testing windows, emergency contacts, what is explicitly out of bounds, how findings will be communicated, and legal authorization. This phase is where most bad engagements go wrong. A vendor that quotes without asking about your application count, user roles, IP ranges, or environment has skipped it. At Invadel this phase produces a written, fixed scope and a fixed price before any testing begins.

2. Intelligence gathering

Reconnaissance. The tester builds a picture of the target the way an attacker would: public footprint, exposed services, subdomains, employee information, technology stack, third-party integrations. For an external network test this often reveals assets the client did not know were exposed; that discovery alone is frequently worth the engagement.

3. Threat modeling

Using what was gathered to decide what an attacker would actually go after and how. Which assets matter most, which attack paths are plausible, and where effort should concentrate. Threat modeling is what separates a targeted test from a spray of generic checks, and it is the phase that automated tools cannot perform at all.

4. Vulnerability analysis

Identifying weaknesses in the in-scope systems: misconfigurations, outdated software, weak authentication, logic flaws, and known vulnerabilities. Automation is genuinely useful here for coverage, but PTES expects the tester to validate and prioritize results rather than hand you the raw scanner output. This is the phase where penetration testing and vulnerability scanning diverge most visibly.

5. Exploitation

Proving that identified weaknesses are actually exploitable, safely and within the rules of engagement. The goal is evidence, not damage: a working demonstration that an attacker could gain access, escalate privileges, or reach data. Exploitation is where chained findings appear, three medium weaknesses combining into one critical path, which is the single strongest signal that a human ran the test.

6. Post-exploitation

What an attacker could do after gaining a foothold: lateral movement, privilege escalation, persistence, data access, and how far the compromise could spread. In an internal network test this is the phase that answers the question that matters, which is not “can they get in” but “how bad does it get once they are in.” It also covers cleanup, so nothing the tester introduced is left behind.

7. Reporting

The deliverable. PTES expects a report with two audiences: an executive summary that a non-technical decision-maker can act on, and a technical section with reproduction steps, evidence, severity ratings, business impact, and specific remediation guidance for each finding. A report that is only tool output fails this phase regardless of how good the testing was. We cover exactly what belongs in the deliverable in our guide to what a penetration testing report should contain.

PTES vs NIST SP 800-115 vs OWASP vs OSSTMM

You will hear other frameworks named in proposals. They are not competitors so much as different lenses, and a good firm draws on several.

Framework	Maintained by	Scope	Best for
PTES	Community (pentest-standard.org)	Full engagement lifecycle, all environment types	The overall structure of any penetration test
NIST SP 800-115	US National Institute of Standards and Technology	Technical guide to security testing and assessment; four phases (planning, discovery, attack, reporting)	Government, defense supply chain, and organizations that need a US federal reference point
OWASP Testing Guide (WSTG)	OWASP Foundation	Web application testing, control by control	Depth on web application and API engagements
OWASP MASVS / MASTG	OWASP Foundation	Mobile application security requirements and test cases	Mobile application engagements
OSSTMM	ISECOM	Operational security testing across channels, with a metrics-driven scoring model	Organizations wanting quantified, repeatable security measurement
MITRE ATT&CK	MITRE	Taxonomy of real adversary tactics and techniques	Mapping red team and internal findings to how attackers actually operate; not a test methodology by itself

The practical pattern: PTES provides the skeleton of the engagement, OWASP provides the checklist depth for application layers, NIST SP 800-115 provides the federal-recognizable reference where auditors want one, and MITRE ATT&CK provides the vocabulary for describing what the attack path looked like. That combination is what Invadel’s methodology is built on.

Why PTES matters to buyers, not just testers

Three reasons to care about this even if you never read the standard yourself.

It makes vendors comparable. When two proposals both claim to be a “penetration test,” asking each to map its process to the seven PTES phases exposes which one is skipping threat modeling and post-exploitation, the two phases that require the most human skill and are most often quietly dropped.

It makes coverage visible. A PTES-aligned report can show you which phases and areas were covered, including where nothing was found. That coverage evidence is what auditors for SOC 2, PCI DSS, and ISO 27001 increasingly want, and it is what separates evidence from a document you have to explain.

It protects you from scan-and-report vendors. The cheapest “penetration tests” on the market are vulnerability scans reformatted as reports. Those vendors cannot honestly claim PTES alignment because they perform none of phases three, five, or six. Simply asking “which PTES phases does your engagement include, and how is each one evidenced in the report” ends most of those conversations.

Questions to ask a vendor about methodology

• Which standard is your engagement built on, and can you map your proposal to its phases?
• Who performs the threat modeling and exploitation phases, and what are their certifications?
• Will the report show coverage by phase and area, including where nothing was found?
• How is exploitation kept safe, and what are the rules of engagement for fragile systems?
• Does post-exploitation include cleanup, and is it documented?
• Is the retest of remediated findings part of the engagement?

Any vendor worth hiring answers all six without hesitation. The fuller checklist is in how to choose a penetration testing company.

Frequently asked questions

Is PTES a certification? No. It is a methodology standard, not a certification for testers or firms. Tester credentials (OSCP, OSCE, CREST, GIAC) certify individual skill; PTES describes how an engagement should be structured. Ask about both.

Is PTES still current? The seven-phase structure remains the accepted skeleton of a penetration test, and it maps cleanly onto how modern engagements run. Firms layer newer references on top of it, notably OWASP’s current web and mobile guides and MITRE ATT&CK, rather than replacing it.

Does PTES apply to cloud and API testing? Yes. The phases are environment-agnostic. Cloud and API engagements follow the same lifecycle, with provider-specific and OWASP API Security Top 10 checks supplying the technical depth in the vulnerability analysis and exploitation phases.

What is the difference between PTES and a penetration testing checklist? A checklist enumerates things to test; PTES defines the process the test runs through. You need both: the process guarantees the engagement is complete end to end, the checklist guarantees depth within each phase. Our penetration testing checklist covers the latter.

The short version

PTES is the seven-phase standard that defines what a real penetration test includes: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. Ask every vendor to map their engagement to it. The ones who can are running penetration tests; the ones who cannot are selling scans.

Invadel’s engagements follow PTES end to end, with OWASP and MITRE ATT&CK layered in for depth, fixed prices agreed in pre-engagement, and a free retest after reporting. Scope your assessment to see the number, or read how we work first.