Pentest methodology
A pentest without a methodology is luck — you find what you happened to poke at. PTES and OWASP WSTG turn it into coverage you can prove, scope you can defend, and a report a defender can act on.
Two testers get the same week-long engagement against the same web app. The first opens Burp, clicks around the parts of the app that look interesting, finds a stored XSS on day two, spends the rest of the week chasing it, and ships a report with one finding. The second works a checklist: every authentication path, every access-control boundary, every input that crosses a trust line, session handling, the file-upload flow, the password-reset flow, the admin API that the UI never links to. Same hours, same tools — but the second tester finds the XSS and an IDOR on the invoice endpoint, a missing rate limit on reset, and a forgotten staging subdomain serving debug stack traces. The difference isn’t talent. The first tester found what they happened to look at; the second tested the application. That gap — luck versus coverage — is what a methodology closes, and it’s the whole reason a client pays for a pentest instead of a lucky afternoon.
By the end of this lesson you’ll know why a repeatable methodology (PTES, OWASP WSTG) turns testing into provable coverage, how the phases hang together, and where scope and authorization sit before any of it starts.
Before anything: authorization and scope
Everything in this lesson assumes one document exists first: a signed authorization with an explicit scope. Penetration testing is, mechanically, doing to a system the things an attacker would do — and the only thing separating a paid engagement from a felony is written permission from someone with the authority to grant it. Practice on lab targets, CTFs, your own infrastructure, or systems you have explicit, in-writing authorization to test. Nothing else.
Scope is not paperwork you skim. It is the contract that defines what coverage even means. A scope says which hosts, domains, IP ranges, and application surfaces are in bounds; what is explicitly out (the shared SSO provider, the payment processor you don’t own, the third-party CDN); the testing window; the rules of engagement (is social engineering allowed? denial-of-service? testing in production or only staging?); and an emergency contact for when something breaks at 02:00. The senior reflex: if it’s not in scope, you do not touch it — and if a finding’s blast radius reaches out of scope, you stop and call the contact. PTES calls this the Pre-engagement Interactions phase, and it is the phase that keeps you out of jail and keeps the client’s unrelated systems intact.
What a methodology actually buys you
Two frameworks dominate. PTES (the Penetration Testing Execution Standard) defines the shape of an engagement end to end — seven phases from pre-engagement through reporting. OWASP WSTG (the Web Security Testing Guide) is the depth for the web-application slice: a checklist of concrete test cases — authentication, session management, access control, input validation, business logic, client-side — each with a stable ID like WSTG-ATHN-03 so a finding maps to a named, repeatable test. You use them together: PTES for the flow of the whole job, WSTG to make sure the web-app phase is exhaustive rather than vibes-based.
The value is three things a senior cares about. First, coverage you can prove: when the client asks “did you test the password-reset flow?”, the answer is a WSTG case ID and a result, not “I think so.” Second, repeatability: a different tester, or the same tester next quarter, runs the same checklist and the results are comparable — you can see what changed. Third, a defensible report: every finding traces to a named test, a reproduction, and a risk rating, so the dev team can act on it instead of arguing about whether it’s real. A methodology converts a tester’s intuition into an auditable process — which is exactly what turns “we got lucky” into “we have coverage.”
The phases, and why the order is load-bearing
The phases aren’t bureaucracy — each one exists because skipping it makes a later one shallow or wrong.
| PTES phase | What you do | Skip it and… |
|---|---|---|
| Pre-engagement | Scope, rules of engagement, signed authorization | You test out-of-bounds systems — illegal and out of scope |
| Intelligence gathering | Map the real attack surface: subdomains, endpoints, tech stack | You test the homepage and miss the forgotten staging API |
| Threat modeling | Decide what an attacker actually wants here; prioritize | You spend the week on low-value bugs, miss the crown jewels |
| Vulnerability analysis | Run the WSTG checklist against every surface and trust boundary | Coverage becomes “what I happened to poke” — luck, not testing |
| Exploitation | Confirm the finding is real and reachable, not theoretical | Report is full of unconfirmed “potential” noise the team ignores |
| Post-exploitation | Show real impact and reach — within scope and rules | Client can’t size the risk: “so what if you got one shell?” |
| Reporting | Findings, reproductions, risk ratings, remediation | All the work above is worthless — nobody can act on it |
The order is load-bearing because each phase is the input to the next. Intelligence gathering before vulnerability analysis is what surfaces the staging subdomain you’d otherwise never test. Threat modeling before exploitation is what stops you burning the week on a self-XSS while the unauthenticated admin API sits untouched. And reporting is not an afterthought — to a client, the report is the product. A brilliant finding nobody can reproduce, rate, or fix has the same value as no finding at all.
▸Why this works
Why follow a checklist at all — doesn’t it make testing mechanical, and won’t a creative attacker beat a checklist-follower? The checklist isn’t a replacement for creativity; it’s the floor under it. WSTG guarantees you cover the known classes — every auth path, every access-control boundary — so your scarce creative energy goes to the business-logic flaws and chained exploits no checklist can enumerate, instead of being spent rediscovering that you forgot to test session fixation. A senior runs the checklist to bank the routine coverage cheaply, then spends the freed-up time where intuition actually pays. Skipping the checklist doesn’t make you more creative; it makes you forget the boring bug that turns out to be the breach.
How a senior runs it
The methodology is a frame, not a cage. A senior treats PTES as the spine — scope first, report always — and WSTG as a coverage ledger: each case is checked, passed, or flagged, so at the end “what did we test?” has a literal answer. The judgment lives in threat modeling and depth allocation: run the full checklist to bank coverage cheaply, then concentrate the remaining hours on the surfaces the threat model says matter most — the money flows, the auth boundaries, the admin paths. Coverage from the checklist; depth from judgment. That combination is what makes the second tester from the hook beat the first every single time, regardless of who got luckier that week.
You have a one-week authorized web-app engagement. On day two you find a juicy stored XSS. What's the senior move for the rest of the week?
What is the single most important artifact that must exist before any testing begins?
A tester confirms one critical bug and writes a report with just that finding, having tested only the surfaces near it. Why does a methodology call this a failure even though the bug is real?
Order the early PTES phases as they must run, from first to last:
- 1 Pre-engagement (scope + signed authorization)
- 2 Intelligence gathering (map the real attack surface)
- 3 Threat modeling (decide what an attacker wants)
- 4 Vulnerability analysis (run the WSTG checklist)
- 5 Exploitation (confirm the finding is real)
- 01Explain how PTES and OWASP WSTG fit together, and what each one buys you.
- 02Why is the order of the PTES phases load-bearing, and why is scoping the phase that gates everything?
A penetration test without a methodology is luck: you find what you happened to look at. A methodology turns it into provable coverage. Everything starts with pre-engagement — a signed authorization and an explicit, written scope from someone with the authority to grant it; that document is both what keeps the work legal and the definition of what coverage means, and you never touch anything outside it. PTES gives the seven-phase spine: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting — and the order is load-bearing, because each phase feeds the next and reporting is the product the client actually buys. OWASP WSTG gives the web-app depth: a checklist of ID’d test cases so “what did we test?” has a literal, repeatable answer. The senior pattern is to run the checklist to bank routine coverage cheaply, then spend judgment on depth where the threat model says it pays. So when you see a one-finding report that only touched the surfaces near the bug, your first question is: where’s the rest of the coverage — what did this test actually prove about the whole scope?
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.