The Penetration Testing Execution Standard (PTES) Explained

What is the Penetration Testing Execution Standard (PTES)?

The Penetration Testing Execution Standard, or PTES, is a community-developed methodology that defines what a professional penetration test should involve. It divides an engagement into seven phases, from pre-engagement scoping through intelligence gathering, threat modelling, vulnerability analysis, exploitation and post exploitation to reporting, so that tests following it are comparably rigorous.

PTES is maintained as an open project by penetration testers rather than by a government body or a standards institute, and its reference material lives on the project wiki at pentest-standard.org. It is a methodology rather than an accreditation: nobody issues a PTES certificate, and no auditor signs off against it.

Why PTES exists

PTES was written to answer a simple but surprisingly common problem: two different penetration tests, both sold under the same name, could involve wildly different levels of depth, planning and rigour. One tester might run a vulnerability scanner, confirm a handful of findings by hand, and call it a penetration test. Another might spend weeks on reconnaissance, build a threat model specific to the organisation, chain several weaknesses into a real compromise, and assess exactly what an attacker could reach as a result.

The standard closes that gap by defining what a thorough test actually involves, phase by phase. It deliberately does not prescribe specific tools or a rigid script to follow. It prescribes phases and the depth of thinking expected within each one, so that two firms following it in good faith produce comparably rigorous work, even though the technical detail of any two engagements will always differ. That makes it as useful as a buyer's checklist as it is a practitioner's methodology: if you know what each phase is supposed to cover, you can ask a provider pointed questions about how deep they actually go.

The seven PTES phases in practice

PTES organises a penetration test into seven phases that run roughly in sequence, though experienced testers move back and forth between them as new information surfaces. Here is what each phase means in practice, not just in name, with the public references a tester would typically work against at each step.

1. Pre-Engagement Interactions

Before any technical work starts, the scope, rules of engagement, objectives and success criteria are agreed in writing. This is where in-scope and out-of-scope assets are listed, legal authorisation is obtained, emergency contacts are exchanged, and the organisation and the tester agree on what a meaningful result looks like. Skipping or rushing this phase is the single biggest source of disputes later in an engagement, because it is where expectations get set.

A usable scope artefact is specific rather than descriptive. It names address ranges (for example 203.0.113.0/24), the hostnames in scope (for example portal.example.com.au), explicit exclusions, an agreed test window such as 22:00 to 04:00 AEST, and a named contact who can halt the test on the spot.

2. Intelligence Gathering

The tester builds a picture of the target organisation using passive and active reconnaissance: domain and subdomain enumeration, exposed services, employee and email footprinting, and general attack-surface mapping. Good intelligence gathering is what separates a targeted, informed test from a generic scan run against a list of IP addresses.

This phase corresponds closely to the Reconnaissance tactic in MITRE ATT&CK, where the active side of the work is catalogued as Active Scanning (T1595) and the service-mapping that follows a foothold as Network Service Discovery (T1046).

3. Threat Modelling

The tester steps back from raw technical data and asks who would realistically target this organisation, what they would be after, and which assets matter most to the business. This phase is what focuses effort on the exposures that carry real consequence rather than spreading attention evenly across every discovered service. It is also the phase most often skipped by lower-effort providers, because it takes judgement rather than tooling.

Threat modelling is where a public behaviour catalogue earns its keep. Working from the technique groupings in MITRE ATT&CK keeps the exercise anchored to what attackers are observed doing rather than to what a tester finds interesting, and it gives the resulting report a vocabulary a defensive team already uses.

4. Vulnerability Analysis

Discovered services and software are correlated against known vulnerability classes using a mix of active and passive scanning, then validated rather than taken at face value. A raw scanner output full of unconfirmed findings is not vulnerability analysis under PTES; the standard expects the tester to work out which findings are real, which are false positives, and which matter given the threat model from the previous phase.

Three public references do most of the heavy lifting here: the weakness taxonomy in CWE for describing the class of defect, CVSS for severity, and the CISA Known Exploited Vulnerabilities catalogue for whether a weakness is being exploited in the wild right now. A severity claim should travel with its vector string, for example CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, not just the word critical.

5. Exploitation

With validated vulnerabilities in hand and the rules of engagement agreed in phase one, the tester attempts to gain access by exploiting them under controlled conditions. This is the phase most people picture when they hear 'penetration test', but PTES treats it as one step among seven, not the whole exercise. Careful evidence capture at this stage is what turns a claimed vulnerability into a demonstrated one.

Where the entry point is an internet-facing service, the behaviour being demonstrated is Exploit Public-Facing Application (T1190). Where it is a credential that should never have worked, it is Valid Accounts (T1078), which is why a single reused password can matter more than a headline CVE.

6. Post Exploitation

Gaining initial access is rarely the end of the story. Post exploitation determines the real business value of a compromise: what data and systems are reachable from the foothold, whether privileges can be escalated, whether the access could move laterally to more sensitive systems, and how much of that an attacker would realistically be able to do before being noticed. This is the phase that turns 'we found a vulnerability' into 'here is what an attacker could actually reach because of it', which is usually the number that matters most to a board or a risk committee.

The two moves that decide the answer are escalation, catalogued as Exploitation for Privilege Escalation (T1068), and sideways movement, catalogued as Exploitation of Remote Services (T1210). A report that stops before either has been attempted has not answered the question the organisation is actually paying to have answered.

7. Reporting

The final phase translates everything found in the previous six into a document two very different audiences can both use: an executive summary that communicates business risk without requiring technical background, and a technical section detailed enough for an engineering team to reproduce and fix each finding. Under PTES, reporting also includes prioritised remediation guidance, not just a list of what went wrong.

What PTES means if you are buying a penetration test

Most buyers never read the standard itself, and they do not need to. What matters is knowing enough about the seven phases to ask a provider how much of each one they actually deliver, because 'we follow PTES' can mean very different things depending on how seriously a firm treats phases three and six in particular, threat modelling and post exploitation, which are the easiest to skip and the hardest to fake.

• Ask what happens before scanning starts. A provider that jumps straight to scanning without a documented scoping conversation is skipping pre-engagement interactions, which is where legal cover and shared expectations come from.
• Ask whether findings are validated or just listed. Vulnerability analysis under PTES means confirmed findings, not a raw automated scan output with false positives left in.
• Ask what 'exploitation' actually involved. A screenshot of a shell is not the same as a documented chain from initial access to business impact; ask to see how post exploitation was assessed, not just whether access was gained.
• Ask whether the report separates business risk from technical detail. A PTES-aligned report should work for both an executive audience and an engineering team, in two clearly readable sections.
• Ask whether threat modelling shaped the test, or whether every asset got the same shallow pass. A test informed by who would plausibly target the organisation looks different from a generic checklist run against every discovered host.
• Ask which public references the findings are anchored to. Findings carrying a CWE class, a CVSS vector and, where relevant, an ATT&CK technique ID are far easier to compare between providers and between years than prose severity labels.

How PTES relates to OWASP and NIST SP 800-115

PTES is not the only methodology in wide use, and it is not meant to compete with the others. Each was written for a different job, and mature programmes borrow from all three.

PTES and the OWASP testing material

The OWASP Top 10 is a risk taxonomy for web applications, and the OWASP Web Security Testing Guide is the matching catalogue of concrete web test cases. PTES has nothing that granular for any single technology, because it is designed to structure an entire engagement across any target type rather than to enumerate every web-specific check. In practice a tester uses PTES for the shape of the engagement and the WSTG for what to actually try against a web application. Our OWASP Top 10 explainer covers the taxonomy in detail.

PTES and NIST SP 800-115

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, takes a different angle again. It is a government technical guide originally written for United States federal agencies, organised around a four-stage model of planning, discovery, attack and reporting, with less emphasis on the business framing PTES puts around threat modelling and post exploitation. Its lasting contribution is a precise vocabulary for testing techniques that other standards reuse. See the NIST SP 800-115 explainer for the full breakdown.

Where compliance frameworks fit

None of these three is a compliance standard. Frameworks that require testing, such as the payment card standards published by the PCI Security Standards Council, point at recognised methodologies rather than defining their own, so PTES and NIST SP 800-115 are commonly named as acceptable approaches. The compliance work happens in how findings are reported against a framework's requirements, not in the testing methodology itself.

How PentestOps helps

PentestOps runs every engagement through a seven-phase methodology that combines PTES, OWASP and NIST rather than following any single standard in isolation, covering external perimeter, internal networks, web applications, APIs, cloud infrastructure and identity in one platform. Vulnerability analysis is prioritised by CVSS v3.1 severity, exploit availability and CISA KEV listing, and confirmed findings are validated with safe, RoE-gated exploitation rather than left as unverified scanner output, which is exactly the gap PTES was designed to close between phases four and six.

The table below maps the seven PTES phases against the seven PentestOps phases, including the one PentestOps adds that PTES does not call out separately.