Penetration Testing Methodology: The Phases That Actually Matter

A penetration testing methodology is the boring part that separates a real pentest from a scan anyone could have run themselves. It's the repeatable process — the ordered phases every engagement moves through, from agreeing on scope to handing over a report someone can act on — that guarantees two testers pointed at the same target come back with comparable coverage instead of two different piles of whatever happened to catch their eye. Skip the methodology and you get a lucky test. Follow one and you get an honest one.

I've delivered engagements against the standards this article walks through — PTES, OWASP's web testing guide, NIST SP 800-115 — and the phases below are how the work actually unfolds on a live target, not a diagram someone drew for a slide. I'll walk them in the order an engagement really runs, map each to the framework that formalizes it, and end with the one thing every good penetration testing methodology is quietly designed to prevent: a tester talking themselves out of the tedious 80% and calling it done.

Last updated: 2026.

A methodology is a process, not a checklist

Here's the distinction people collapse, and it matters more than any single tool. A checklist is a flat list of things to look for — test for SQL injection, test for XSS, check TLS config. A methodology is an ordered process that decides what to look for next based on what you just found. Recon surfaces a forgotten API subdomain; that changes what you enumerate; enumeration reveals a GraphQL endpoint; that changes which vulnerability classes you prioritize. The checklist is downstream of the method. If you run the checklist without the method, you test the things you remembered to write down and miss the asset you never knew existed.

That's why the recognized standards are structured as phases with feedback loops, not as bullet lists. Each phase feeds the next, and the interesting engagements loop backwards — a foothold in exploitation sends you back into recon on the internal network you just reached.

A checklist tells you what to check. A methodology tells you what to check next. Only one of them survives contact with a target you've never seen.

The practical payoff is coverage you can defend. When a client asks "how do you know you didn't miss anything," the answer isn't "trust me." It's "we ran every asset through the same defined phases, and here's the evidence at each step." That's also exactly why this is the part autonomous execution changes most — hold that thought for the last section.

Phase 1 — Scoping and pre-engagement

Nothing technical happens yet, and this is still the phase that decides whether the engagement is worth anything. PTES calls it Pre-engagement Interactions, and it's the whole first section of the standard for good reason. You nail down scope (which domains, IP ranges, apps, and — critically — what's explicitly out), the rules of engagement, testing windows, whether production is in play, emergency contacts, and the goal: are we proving perimeter breach, testing a specific app, or validating a compliance control?

Get scope wrong and everything downstream is wasted. Too narrow and you certify a slice while the breach comes through the subdomain you were told to ignore. Too vague and you'll spend half the budget arguing about whether that third-party portal counts.

This is also where you agree what "done" looks like and what evidence the report needs. Compliance-driven work anchors here: PCI DSS v4.0 Requirement 11.4 dictates scope and segmentation testing for cardholder environments, and if that's the driver you scope to it deliberately — more in the PCI penetration testing guide. Authorization in writing, signed, before anyone sends a packet. No exceptions.

Phase 2 — Reconnaissance

Recon is where the engagement is won or lost, and it's the phase amateurs rush. PTES splits it into Intelligence Gathering; NIST SP 800-115 folds it into the Discovery phase; OWASP's Web Security Testing Guide opens with Information Gathering (the WSTG-INFO test series). Different names, same job: build the target's shadow before you touch it.

Passive first. You map every domain, subdomain, IP block, cloud bucket, exposed API, third-party integration, and forgotten staging box without sending traffic that looks hostile. amass and subfinder pull passive DNS and certificate-transparency logs; certificate transparency alone routinely surfaces subdomains a company doesn't remember provisioning. Then you go wider — GitHub for leaked keys and internal hostnames, Shodan and Censys for exposed services, job postings that quietly disclose the stack, and the Wayback Machine for endpoints deleted from the UI but never taken offline.

Whoever wins recon wins the engagement. The exploit is usually easy once you find the asset nobody was defending.

The methodology point here is discipline: recon is systematic, not a vibe. You don't stop enumerating because you found something interesting — you finish the sweep, because the goal is completeness of the attack surface, not the first shiny target. A rushed recon phase is the single most common reason a report misses the finding that later becomes the breach.

Phase 3 — Enumeration and mapping

Now you turn a list of hosts into a map of things you can attack. This is scanning and service enumeration — NIST keeps it inside Discovery, PTES bridges it between Intelligence Gathering and Threat Modeling, where you rank what's actually worth attacking.

nmap and masscan sweep for open ports and fingerprint services and versions. For web targets you enumerate virtual hosts, spider the app, and brute-force content and parameters with ffuf or gobuster — /admin, /.git/, /api/v1/, /backup.zip, .env, Swagger docs at /openapi.json. An exposed .git directory or a readable API spec collapses whatever black-box advantage the defender was counting on: suddenly you know the routes.

Threat modeling is the step people skip and shouldn't. You take the mapped surface and reason like the specific attacker who'd target this org — what's valuable, what's exposed, what's the shortest path between the two. That's what turns a flat host list into a ranked target list. You're not testing everything with equal effort; you're finding the soft edges — the default admin panel on a subdomain, the API that returns different errors for valid versus invalid users, the upload that doesn't check content type. The full toolkit for this phase is in the penetration testing tools breakdown.

Phase 4 — Vulnerability analysis

Here you go from "these services exist" to "these are the specific weaknesses, and here's how confident I am in each." PTES makes Vulnerability Analysis its own phase; OWASP's WSTG is essentially this phase written out in exhaustive detail — test cases organized by category (WSTG-ATHN for authentication, WSTG-ATHZ for authorization, WSTG-SESS for session management, WSTG-INPV for input validation, WSTG-BUSL for business logic) so nothing gets silently dropped.

This is where a methodology earns its keep, because a scanner will hand you a wall of "medium" findings and it's on you to separate signal from noise. nuclei runs thousands of templates for known CVEs and misconfigurations at speed; Burp Suite's scanner catches the obvious app-layer stuff. But the analysis — deciding which of those are real, which are exploitable in this context, and which are the head of a chain — is the human-shaped judgment the checklist can't encode.

You're cataloguing candidates across the OWASP Top 10 and OWASP API Security Top 10: broken access control and IDOR, injection, broken authentication, SSRF-prone URL fetchers, deserialization sinks, SSTI. A confirmed-but-unexploited finding is still a hypothesis at this stage. This phase overlaps heavily with straight vulnerability assessment and penetration testing — the difference is that a pentest doesn't stop at "found," it proceeds to prove it.

Phase 5 — Exploitation

A candidate finding is a hypothesis; exploitation is where you prove it, because a report full of "potential" and "possible" is worthless to the person who has to fund the fix. Both PTES and NIST SP 800-115 make this an explicit phase — NIST names it Attack, and importantly draws a feedback loop from Attack back into Discovery, because gaining access reveals new systems to enumerate.

The vulnerability classes that carry real impact are the same ones every year:

• Broken access control / IDOR — change account_id=1001 to 1002 and read someone else's data. Still number one in the OWASP Top 10.
• Authentication bypass — password-reset flaws, JWT alg:none, predictable tokens, MFA not enforced on every route.
• SQL injection — rarer than it was, still fatal when present. sqlmap to confirm and dump.
• SSRF — coax the server into fetching an internal URL; on a cloud host that's often a straight line to the metadata endpoint and temporary IAM credentials.
• Insecure deserialization and SSTI — turn a data field into code execution.

The rule that keeps exploitation honest: prove impact with a working proof-of-concept — the exact request, the response, and the access or data it yields — not a scanner's guess. This is the line between a finding a client patches and one they argue with. And you exploit within scope and with restraint; the goal is demonstrated impact, not a smoking crater in production.

Phase 6 — Post-exploitation

Getting a shell isn't the finding — what that shell means is the finding. Post-exploitation answers the question the board actually asks: so what? PTES has a dedicated Post Exploitation phase, and this is where MITRE ATT&CK becomes the right map, because ATT&CK is a taxonomy of exactly what attackers do after initial access.

You work the ATT&CK tactics in sequence: Privilege Escalation (TA0004), Credential Access (TA0006) — dumping hashes, hunting for keys in config and memory — Discovery (TA0007) of the internal network you can now see, Lateral Movement (TA0008) to reach the systems that matter, and Exfiltration (TA0010) to prove data can actually leave. Mapping each action to its ATT&CK technique ID (T1078 Valid Accounts, T1003 OS Credential Dumping, T1021 Remote Services) does two things: it makes the narrative precise, and it lets the client's blue team check their detection coverage against the exact techniques you used.

Post-ex is also where you demonstrate the chain. One medium bug is a ticket; three chained — SSRF to metadata to credentials to an S3 bucket of customer exports — is an incident. That end-to-end narrative is what a real report delivers, and it only exists because the methodology carried you past "got a shell" into "here's what a shell gets an attacker."

Phase 7 — Reporting and retest

The report is the deliverable. Everything before it is process the client doesn't see; the report is the only artifact they keep. PTES closes with Reporting, NIST with Reporting, and if this phase is weak, the whole engagement was theater.

A report that's worth paying for has, per finding: a clear description, the affected asset, reproduction steps a developer can follow, the working proof-of-concept, a CVSSv3 score with the vector string (so severity is defensible, not a gut call), business impact in plain language, and a specific fix — not "sanitize inputs" but the actual remediation. An executive summary that a non-technical decision-maker can read, and technical detail an engineer can act on. Two audiences, one document.

Then the part that separates a vendor from a box-ticker: the retest. You come back after remediation and verify the fixes actually hold — that the patch closed the hole and didn't open a new one. A finding isn't closed because a ticket says "fixed"; it's closed because you re-exploited and failed. Skip the retest and you've sold a snapshot, not assurance.

PTES vs OWASP vs NIST — which framework for what

You don't pick one and burn the others. In practice you run PTES as the engagement skeleton, use OWASP's WSTG to make the web/app coverage exhaustive inside the vulnerability-analysis and exploitation phases, and cite NIST SP 800-115 when a compliance auditor wants a recognized process on paper. They operate at different altitudes. WSTG is also the backbone of a dedicated web application penetration testing engagement, where the app layer is the whole scope.

	PTES	OWASP WSTG	NIST SP 800-115
Focus	Full engagement lifecycle	Web/app-layer test cases	Technical assessment process for orgs
Structure	7 phases, pre-engagement → reporting	Test categories & IDs (WSTG-*)	4 phases: planning, discovery, attack, reporting
Scope	Any target, end to end	Web apps and APIs specifically	Networks, systems, general infrastructure
Best for	Structuring a commercial pentest end to end	Making web coverage genuinely exhaustive	Compliance/government, a defensible documented process
State	Community standard, detailed technical guidelines	Actively maintained (WSTG v4.2)	Canonical NIST reference, but dated (2008)

Two others worth knowing. OSSTMM (from ISECOM) is the metrics-heavy option — its RAV scoring quantifies operational security state rather than just listing findings, which suits organizations that want a repeatable, measurable number over time. And MITRE ATT&CK, as covered above, isn't a lifecycle framework at all — it's the post-exploitation and detection language, best used alongside PTES rather than instead of it.

My honest take: PTES for the shape of the engagement, WSTG for depth on the web layer, NIST when the auditor's in the room, ATT&CK for the post-ex story. Anyone insisting there's one true methodology is usually selling their own. The frameworks agree on the phases — they differ on altitude and audience. Network-specific work is the same phase model applied to internal ranges: recon becomes host discovery, enumeration becomes service and share enumeration, exploitation becomes credential relay and lateral movement.

Where autonomous AI fits the methodology

Now the part that changes. Look back at the seven phases and sort them by what they actually demand. Scoping and threat modeling need human judgment. But recon, enumeration, a large slice of vulnerability analysis, and the mechanical exploitation of known classes are labor — serial, tedious, unbounded work where the human is the bottleneck, not the skill ceiling. That's exactly the work a tester under a two-week clock quietly triages away, going deep on three targets and skimming the rest. The methodology says test everything; the stopwatch says you can't.

That gap is what BackDoor closes. It's an autonomous, AI-driven black-box penetration test: a swarm of agents runs a PTES/OWASP-aligned methodology end to end from the outside — no source, no credentials, no backend access. They execute recon, enumeration, vulnerability analysis, and exploitation in parallel across the whole surface, so the forgotten subdomain gets the same attention as the front door instead of being the thing that got skimmed. Machines don't get bored on hour forty of subdomain enumeration, and they run the same defined phases on every asset, every time — which is precisely what a methodology is supposed to guarantee and what a tired human quietly fails to.

What comes back is a real deliverable, not a scan dump: proven exploits with working PoC for each finding, CVSSv3 scoring and ranking, step-by-step fixes, and mapping to SOC 2, ISO 27001, NIST CSF, GDPR Article 32, and PCI DSS v4.0 so it drops into audit prep. Turnaround is roughly five hours versus the four-to-six weeks of a manual engagement, from €5,100, with zero data retention and NDA/DPA available. You can see the shape of it in the sample report, and the economics are covered further in the automated penetration testing and black-box penetration testing pieces.

The guardrail, because I don't overclaim and neither should you: autonomous execution is exceptional for coverage and continuous testing and strong pre-audit readiness. It is not a full substitute for human red-teaming on the hardest, most bespoke engagements — the ones needing social engineering, physical access, or a creative human chaining a business-logic flaw no template describes. And mapping findings to a framework is mapping, not a certification or a regulatory attestation like DORA TLPT. Use it for what it's outstanding at; bring in specialist humans where the engagement genuinely demands them.

What to actually do next

A penetration testing methodology isn't paperwork you tolerate to reach the fun part. It's the thing that makes the fun part count — the repeatable process that turns "we poked at it and found some stuff" into "we ran every asset through defined phases and here's the evidence at each one." Pick your frameworks by altitude: PTES for the engagement shape, OWASP WSTG for web depth, NIST SP 800-115 for the auditor, MITRE ATT&CK for the post-exploitation story. Then run every phase, on every asset, without skimming the long tail — because the long tail is where next year's breach is sitting right now.

The reason methodologies exist is that humans cut corners under a clock, and the corners they cut are exactly where the holes hide. Take the clock away and coverage stops being aspirational. Point an autonomous pentest at your own domain, watch a standards-based methodology run end to end, and read the rest of the BackDoor blog for the phases in more depth.