The Penetration Testing Execution Standard (PTES) is a framework developed by penetration testing professionals to define what a complete penetration test should encompass. It addresses a practical problem where, without a shared standard, the term "penetration test" can describe anything from an automated vulnerability scan to a multi-week manual assessment, and organisations commissioning tests have no reliable way to compare what different providers offer.

PTES establishes seven phases, each with specific activities and expected outputs. It covers not just technical testing but the surrounding process of scoping, legal authorisation, rules of engagement, reporting, and post-engagement activity. A provider following PTES will structure their engagement to address all of these, and not just the hands-on testing element.

The seven phases of PTES

The phases apply to most types of penetration test, including external and internal network testing and web application assessments . The extent to which each phase applies in full depends on scope and test type.

Phase 1: Pre-engagement interactions

Pre-engagement is where the parameters of the test are defined before any active testing begins. This phase produces the documentation that both the testing team and the commissioning organisation rely on throughout the engagement.

Key activities include:

Defining scope: which systems, applications, IP addresses, or domains are in scope, and what is explicitly excluded
Agreeing the rules of engagement : testing hours, approved techniques, emergency contact procedures, and how critical findings will be escalated during testing
Legal authorisation: written permission to conduct testing, NDA agreements where required, and documentation of liability limitations
Setting objectives: what the organisation wants to achieve, whether that is satisfying a compliance requirement, testing a specific concern, or assessing general security posture

This phase has the most impact on whether a test delivers actual value. A poorly defined pre-engagement leads to assessments that miss the systems that actually matter, findings that cannot be acted on because the scope was too narrow, or disagreements about what was in-scope.

Our guides to scoping a network penetration test and scoping a web application assessment cover the practical considerations for defining scope and objectives in more detail.

Phase 2: Intelligence gathering

Intelligence gathering builds a picture of the target environment before any exploitation begins. PTES distinguishes between passive and active reconnaissance.

Passive reconnaissance involves collecting information without directly interacting with target systems: reviewing DNS records, certificate transparency logs, WHOIS data, job postings (which often reveal the technology stack in use), and any other open source information relevant to the target.

Active reconnaissance involves directly probing in-scope systems: port scanning to identify exposed services, service fingerprinting to determine software versions, and banner grabbing. Active reconnaissance is still discovery activity, not exploitation.

Intelligence gathering determines what the rest of the test focuses on. An assessment that skips this phase and jumps straight to vulnerability scanning will miss context that affects which vulnerabilities matter and how they could be combined.

Phase 3: Threat modelling

Threat modelling takes the intelligence gathered and uses it to identify and prioritise realistic attack vectors. Rather than testing everything with equal weight, threat modelling asks: if a real attacker were targeting this organisation, what would they go after?

This involves a business impact analysis to understand which systems, data, or functions represent the highest-value targets, and mapping potential attack paths against those priorities. For example, a payment processing environment warrants different prioritisation than an internal wiki.

Threat modelling directs testing effort at key focus areas, rather than distributing it evenly across a broad scope regardless of risk.

Phase 4: Vulnerability analysis

Vulnerability analysis is the phase where specific weaknesses are identified and validated. This involves a combination of automated scanning and manual testing, applied to in-scope targets identified during intelligence gathering and shaped by the priorities established in threat modelling.

The key output is not just a list of potential vulnerabilities but a set of validated findings: weaknesses confirmed to exist in the specific target environment, not just theoretical matches from a CVE database. A service running a version of software with a known CVE is a potential vulnerability; a confirmed finding is one where a tester has verified that the vulnerability is present and not already mitigated by another control.

This distinction matters because automated scanners frequently flag vulnerabilities that are not exploitable in the specific environment, generating findings that waste remediation effort. Manual validation is what separates a penetration test from an automated scan report.

Phase 5: Exploitation

Exploitation is where confirmed vulnerabilities are actively tested to demonstrate real impact. The aim is not to cause harm but to prove exploitability and show what an attacker could achieve from the identified weaknesses.

In practice, this means attempting to gain access to systems, extract non-sensitive data to demonstrate what could be extracted, bypass authentication mechanisms, or chain multiple lower-severity findings into a realistic attack path. Exploitation is conducted safely and within the boundaries agreed in the rules of engagement.

The chaining of findings is important here. A tester might exploit an information disclosure vulnerability to identify a service, find a weak credential on that service, and use the resulting access to reach a more sensitive system. Each individual finding might carry medium severity; the combination can demonstrate critical risk. Automated tools cannot identify this kind of path.

Phase 6: Post-exploitation

Post-exploitation follows once initial access has been established. This phase determines the actual value of the compromise: which systems are reachable, what data is accessible, and how far an attacker could move through the environment from that position.

Activities in this phase, where authorised by the rules of engagement, include:

Lateral movement: attempting to reach other systems on the network from the initial access point
Privilege escalation: attempting to move from a limited user account to an administrative or domain-level account
Identifying sensitive data or systems accessible from the compromised position

Post-exploitation answers the question most relevant to the business: not whether a weakness exists, but what an attacker could do if they exploited it. It is particularly significant in internal network testing, where the realistic concern is how far an attacker with initial access could move before being detected.

Phase 7: Reporting

Reporting produces the formal output of the engagement. A PTES-aligned report covers more than a list of findings: it documents the methodology, the scope, the evidence for each finding, and specific remediation guidance.

A complete report typically includes:

Executive summary: a non-technical overview of the engagement, the key findings, and their business impact, written for senior stakeholders and auditors
Technical findings: each vulnerability documented with severity rating, evidence such as screenshots and request captures, reproduction steps, and specific remediation guidance
Scope and methodology: what was tested, how, and under what constraints are important for compliance submissions, and for understanding what the report does and does not cover
Informational notes: observations that are not vulnerabilities but are worth the organisation's attention

Our article on how to write a pentest report covers what the reporting phase should produce in more detail.

What PTES means if you are commissioning a penetration test

PTES is not a certification and providers do not need accreditation to follow it. It is a methodology reference that providers use to structure their engagements, and that buyers can use to evaluate whether a proposed test is likely to be thorough.

When reviewing a penetration test proposal, a few checks map directly to the PTES phases:

Does the proposal include a pre-engagement phase with documented scope, rules of engagement, and authorisation?
Does the methodology cover both passive and active reconnaissance, or does it start with scanning?
Is there manual exploitation and validation, or is the test primarily automated scanning with findings reported unvalidated?
Does the reporting section specify what the deliverable covers: executive summary, technical findings, evidence, and remediation guidance?

A proposal that describes only scanning and reporting, with no pre-engagement interactions, threat modelling, or manual exploitation, is not a complete penetration test in the PTES sense, regardless of what it is called.

PTES (Penetration Testing Execution Standard)