PTES Methodology: The 7-Phase Penetration Testing Standard

Quick answer: PTES (Penetration Testing Execution Standard) is an industry-accepted, seven-phase standard that defines how a penetration test is run from start to finish. The phases are: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. Its purpose is to turn ad hoc scanning into a repeatable, measurable discipline that proves real business impact.

Let us be blunt: a large share of the work sold as a "pentest" is just pointing an automated scanner at a target and converting the output into a PDF. A scan produces a list. A penetration test proves a claim: "In the hands of a real attacker, this vulnerability does this damage to that asset." PTES is precisely the common language that institutionalizes this difference. It is the discipline that lets a tester say "proven" where a scanner only says "possible."

At DSET, in the penetration tests we have run since 2003, we use PTES not as a checklist but as a thinking framework. Because the real value of the standard hides in its two most-skipped phases: threat modeling and post-exploitation. In this article we unpack all seven phases one by one, with examples from the field.

What is PTES and why do we need a "common language"?

PTES was launched in 2009 by experienced penetration testers to close the quality gap in the industry. The problem was this: give the same scope to two different firms, and one delivered a shallow scan report in three days while the other delivered an Active Directory takeover chain in two weeks. The customer had no shared yardstick to compare these two outputs.

PTES brought a seven-phase skeleton to this chaos. The beauty of the standard is that it does not dictate which tool you use. Nmap, Burp Suite, or a script you wrote yourself, that is your call. PTES answers "what" and "why" and leaves "with which tool" to the expert. That is exactly why it has stayed relevant for years.

The seven phases at a glance

# Phase Core question Typical output
1 Pre-engagement What, within which limits, with whose authorization do we test? Scope, ROE, legal authorization, goals
2 Intelligence Gathering What does an attacker see from outside? OSINT report, asset inventory, attack surface
3 Threat Modeling Which asset is valuable, which attacker is realistic? Asset priority map, attacker profile
4 Vulnerability Analysis Which vulnerabilities truly exist and are verified? Validated vulnerability list (false positives removed)
5 Exploitation Can the vulnerability actually be exploited? Initial access, proof of working exploit
6 Post-Exploitation How much damage does this access cause? Lateral movement, privilege escalation, crown jewels access
7 Reporting What should management and the technical team do? Executive summary, technical findings, remediation plan

1. Pre-engagement Interactions

This phase ends before a single packet is captured or a single port is scanned. The only thing discussed here is words, not code. Yet this is exactly the phase that decides whether the test succeeds or becomes a legal disaster.

In pre-engagement we settle four things. First, scope: which IP ranges, which domains, which applications are in, and which are strictly out. Second, Rules of Engagement (ROE): when the test happens (business hours or overnight), which techniques are forbidden (for example DoS, social engineering, physical entry), and who to contact in an emergency if a critical system goes down. Third, goals: does the customer want a compliance stamp, or a real answer to "can you take over our AD?" Fourth, and most important, written legal authorization: a single packet sent without an authorization document is not a penetration test, it is a crime.

At DSET we never close this phase over the phone. We put scope and ROE into a signed document and keep the "out of scope" list deliberately long. The most common crisis in the field is accidentally affecting an out-of-scope system; the cure is a well-written pre-engagement.

2. Intelligence Gathering

This phase is about looking at the organization through the attacker's eyes. Before knocking on any door, we measure how much information leaks from the outside. Intelligence advances on two fronts.

Passive reconnaissance (OSINT): Gathering information from open sources without direct contact with the target. Domain records (WHOIS), certificate transparency logs (subdomain discovery via crt.sh), DNS records, corporate email formats, leaked password databases, API keys accidentally pushed to GitHub, and staff and tech stack scraped from LinkedIn. The attacker leaves no trace here, because the target's server is never touched.

Active reconnaissance: Direct contact with the target. Port scanning, service and version detection, web technology fingerprinting, subdomain brute-force. Active recon leaves traces and hits the logs; that is why we tune the noise level to the ROE.

The output of this phase is an attack surface map. The most frequent mistake we see in the field is underrating intelligence and jumping straight to scanning. In reality, good OSINT often gets you inside faster than an exploit. A forgotten test server or a credential exposed on GitHub is more dangerous than the strongest vulnerability.

3. Threat Modeling

Here is the most-skipped yet most valuable phase of PTES. Most firms jump from intelligence straight to vulnerability scanning. We do not, because a test done without threat modeling turns into "shoot at everything you find." That produces unread reports stuffed with hundreds of findings that have no business impact.

Threat modeling models two sides. First, asset modeling: what is truly valuable to the organization? The customer database, the payment infrastructure, the source code repository, the Active Directory admin accounts? We call these the "crown jewels." Second, attacker modeling: who attacks this organization, and why? An opportunistic ransomware gang, a targeted attacker working for a competitor, an insider? The attacker's motivation and capability shape the test scenario.

At DSET we sit at the same table as the customer in this phase. Because the customer knows best which asset is most valuable, and we know best who the realistic threat is. Combine the two, and the test stops being a random scan and becomes a simulation locked onto a target.

4. Vulnerability Analysis

Here we discover vulnerabilities and, more importantly, validate them. The keyword is validation. Automated scanners are masters at producing false positives: they see a banner, look at a version number, and say "this version has CVE-XXXX." But that patch may have been backported, that feature may be disabled, that path may be unreachable.

Vulnerability analysis means taking the raw list the scanner produces and filtering it by hand. We verify every finding to see whether it truly exists. On the web side, manual testing (for example confirming a SQL injection with a time-based query), on the network side, service configuration review, and logic analysis of authentication mechanisms. At the end of this phase we hold not a "possible" list but a "validated" one.

Our internal link gains meaning right here: those who want to experience the process step by step can explore our PTES process simulator.

5. Exploitation

The phase that draws the most attention but is actually the most misunderstood. Exploitation means using a validated vulnerability to gain real access to the target. Turning a SQL injection into a database shell, escalating a file upload flaw into remote code execution, logging in with a stolen credential.

The critical insight is this: saying "I exploited it" is not the moment the work ends, but the moment it begins. Initial access is a door, not the destination. Discipline in the field starts here. Exploitation is carried out within the ROE limits set in pre-engagement, in a controlled and reversible way. Running an exploit that could crash a production system aggressively, over and over after impact is proven, is amateurish.

At DSET we always leave a "proof anchor" (canary) during exploitation: a unique marker that proves the access is real and not a false positive. Because writing "access achieved" in a report is easy; proving it undeniably is the measure of professionalism.

6. Post-Exploitation

This is the phase where the report's real value is born, and the second most-skipped link in PTES. Initial access is achieved; so what does it mean? Post-exploitation is the phase that turns "I opened a door" into "I reached the organization's most valuable asset by this path and I can cause this damage."

Here we do several things. Privilege escalation: climbing from an ordinary user to administrator, and from there to domain admin. Lateral movement: hopping from the first compromised machine to other systems. Pivoting: using a reached machine as a bridge to infiltrate the internal network that is unreachable from outside. Persistence: showing, in a controlled way, how a real attacker could remain on the system. And the goal of all of it: reaching the crown jewels, the assets we identified in threat modeling, and concretely proving the business impact.

The severity of a finding lies not in its technical complexity but in its business impact. Saying "I found an XSS" is one thing; saying "with this XSS chain I stole an admin's session and exfiltrated the entire customer database" is something else entirely. Post-exploitation is the phase that proves the second. For those who want to see a real attacker scenario end to end, our red team attack simulation service applies this phase in its deepest form.

7. Reporting

The single tangible output of the whole test is the report. No matter how elegant an exploit chain you build, a bad report makes it invisible. A PTES report addresses two audiences at once.

Executive summary: For non-technical decision makers. Risk level, business impact, priorities that need budget. No CVE numbers or payloads here; instead, "if this flaw is not closed, customer data may leak, which means a regulatory fine and reputational loss."

Technical findings: For security and systems teams. For each finding: the location of the vulnerability, reproduction steps (PoC), evidence, impact, and the most critical part, remediation, the concrete fix recommendation.

Let us say it plainly: the value of a report lies not in the exploit but in the remediation. The customer does not applaud your vulnerability; they trust you once they learn how to close it. Which version to upgrade to, which configuration to change, which WAF rule to write must be clear. Mapping findings to a framework like MITRE ATT&CK helps the organization direct its defensive investment to the right place.

DSET's PTES approach

At DSET we run the seven phases not as a ritual but as an engineering discipline. We sign the pre-engagement, we do not underrate intelligence, we never skip threat modeling, we validate every vulnerability, we run exploitation within ROE limits and with proof, we concretize business impact in post-exploitation, and we build the report on remediation.

You can find more about when the process is needed, how long it takes, and pricing in our penetration testing process article. Those curious about who does this work can look at our what is a pentester article.

Frequently Asked Questions (FAQ)

What is the difference between PTES, OWASP, and NIST SP 800-115? PTES is an end-to-end seven-phase execution framework that covers an entire general penetration test. OWASP focuses more on web application security (Testing Guide, Top 10). NIST SP 800-115 is an institutional technical guide. In practice they complement each other: PTES gives the skeleton, OWASP deepens the web side, NIST provides the institutional framework.

Which phase of PTES is skipped most often? By far, threat modeling and post-exploitation. Many firms jump from intelligence straight to vulnerability scanning (skipping threat modeling) and stop at initial access (skipping post-exploitation). Yet the business value of the test is produced in exactly these two phases.

How does a penetration test differ from a scanner? A scanner produces a list of probabilities; a penetration test proves a claim. A scanner says "this version may be vulnerable," the tester exploits that vulnerability and demonstrates the business impact. PTES is the standard that disciplines this difference.

Does saying "I exploited it" mean the test was successful? No. Initial access is only a beginning. The real question is what damage that access causes. The severity of a vulnerability is measured not by its technical complexity but by its business impact on the crown jewels. The phase that proves this is post-exploitation.

What is the most valuable part of a penetration test report? Remediation, the fix recommendations. Listing findings is easy; explaining clearly how to close them is the real value of the work. In a good report, every finding comes with a concrete, actionable solution.

Sources

DSET has provided cybersecurity, penetration testing, digital forensics, and data recovery services from Hacettepe Teknokent Beytepe, Ankara, since 2003. To plan a PTES-standard penetration test for your organization: +90 536 662 38 09.