PTES
an operator-first view of the Penetration Testing Execution Standard

PTES: a complete view of a penetration test, not a checklist

The Penetration Testing Execution Standard (PTES) was published by a group of practitioners to give the industry a shared definition of what a penetration test actually is. It covers seven sections, from pre-engagement interactions through reporting, and an accompanying Technical Guidelines document that goes deeper into tooling and technique. PTES is widely cited in commercial penetration test scopes, in service provider methodology statements, and in client-side requests for proposals because it is engagement-shaped: it describes how to run a test, not which test cases to run.

PTES sits comfortably alongside more specific catalogues. The OWASP Top 10 and OWASP Testing Guide cover the web application phase in depth. The MITRE ATT&CK framework is the language to tag what attackers do during the engagement. Compliance frameworks like PCI DSS and ISO 27001 require penetration testing as a control, and PTES is the standard most testers reach for to execute that requirement consistently.

The seven sections at a glance

PTES is unusual in giving pre-engagement, threat modelling, and reporting the same weight as exploitation. That weighting reflects what actually determines whether an engagement is useful: a clean exploitation chain on the wrong target produces a report nobody acts on. The summary below is a working operator's read, not a substitute for the official standard.

Pre-engagement (Section 1): the part that decides the rest

PTES dedicates an unusually large amount of guidance to pre-engagement interactions because ambiguity here propagates through every later phase. The checklist below is drawn from the standard and refined by the patterns that turn up across real engagements. The matching penetration testing scope of work template gives a drop-in clause set covering most of these in writing, and the free rules of engagement template provides the operational ROE document that PTES Section 1 expects to be signed before any reconnaissance starts.

Intelligence gathering (Section 2): pick the level on purpose

PTES separates intelligence gathering into three levels of effort. The level chosen is a contractual decision. A Level 1 engagement that is later reported as Level 3 is a scope breach; a Level 3 engagement reported as Level 1 is a value gap. Decide the level during Section 1, and reflect the choice in the rules of engagement.

For external recon work, the attack surface management feature produces the asset, subdomain, and exposed service inventory that Section 2 expects. The external scanning capability adds CVE correlation, weak TLS detection, and outdated software identification, all retained per scan window for evidence purposes.

Threat modelling (Section 3): keep it short, keep it written

PTES asks for four small models, not one large one: business asset analysis, business process analysis, threat agent and community analysis, and threat capability analysis. The threat model is the bridge between Section 1 (what we agreed to test) and Section 4 (what we actually test). When the threat model is missing, vulnerability analysis tends to drift toward whatever the scanner finds, and the report ends up describing tools rather than risk.

For deeper background on threat modelling techniques and how they integrate with engagement planning, see the threat modelling guide. For organisations layering threat-led testing requirements on top of PTES (financial entities under DORA TLPT, for example), the threat agent analysis becomes more elaborate and is informed by threat intelligence rather than internal interviews alone.

Vulnerability analysis and exploitation (Sections 4 and 5)

PTES is deliberate about separating vulnerability analysis from exploitation. Section 4 identifies, validates, and rates findings; Section 5 turns the validated findings into demonstrated risk. That separation is what allows the report to distinguish between issues that exist (vulnerability) and issues that an attacker can act on under the agreed constraints (exploited). The standard also covers countermeasure analysis (AV, DLP, IDS, IPS, HIPS) so exploitation evidence acknowledges the defensive context rather than presenting a clean lab result.

The findings management feature carries CVSS 3.1 scoring, 300+ templates, and Nessus or Burp Suite imports so Section 4 output flows in without manual re-entry. Authenticated workflows live in the authenticated scanning capability which covers configuration and patch evidence behind login. For exploitation chains, every validated finding can be linked to the engagement, the threat model entry it evidences, and the post-exploitation result it enables.

Post-exploitation (Section 6): evidence the business impact

Post-exploitation is where PTES becomes operationally distinct from a vulnerability scan. The section covers infrastructure analysis, pillaging, business impact analysis, persistence (where authorised), and clean-up. The objective is to evidence what an attacker could actually achieve once a foothold exists, not to demonstrate every technique a tester knows. Tying post-exploitation evidence back to the assets identified in Section 3 keeps the narrative focused on business impact, which is what executive readers respond to.

Reporting (Section 7): the deliverable, not an afterthought

PTES treats reporting as a structured deliverable, not a wrap-up. The executive section is for an audience that will not read the technical body; the technical section is for the engineers and architects who will fix the findings. Both have to exist, and both have to tie back to the engagement objectives agreed in Section 1.

For a deeper write-up on report structure including how to balance executive and technical sections, see how to write a pentest report and the matching penetration testing report template. The AI report generation feature composes the Section 7 deliverable from the underlying engagement, intelligence, findings, and exploitation evidence rather than from a blank page.

PTES Technical Guidelines: the operational companion

PTES publishes a Technical Guidelines document alongside the standard. It is more prescriptive than the main standard, includes example tooling per phase, and maps common engagement scenarios onto the seven sections. The guidelines age (tools change), but the scaffolding does not.

How PTES compares to OWASP, NIST 800-115, OSSTMM, and ATT&CK

PTES is rarely used in isolation. The strongest pentest programmes layer it with at least one technical reference and one threat-informed catalogue. The contrast below is a working view, not a buyer's comparison: the practitioner question is which standard to combine with PTES, not which to pick instead of it. For UK and European buyers commissioning a penetration test, PTES typically sits inside a CREST aligned engagement as the methodology the CREST member firm follows under the CHECK, OVS, or STAR scheme.

Where SecPortal fits in a PTES-aligned engagement

SecPortal is the operating layer for a PTES-aligned engagement. The platform handles scope, intelligence, threat model notes, vulnerability analysis, exploitation evidence, and the Section 7 deliverable so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies running PTES engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals and findings deduplication across engagements.

Looking for the engagement workflow itself, end-to-end? The penetration testing use case captures how SecPortal turns a PTES-shaped engagement into a structured record covering scope, methodology, findings, retests, and the deliverable.

Need to position PTES alongside a broader methodology comparison? The penetration testing methodology guide covers PTES, OWASP, OSSTMM, and NIST SP 800-115 side by side, including where each one is the strongest fit and how they tend to be layered in practice.