Standard Methodology Frameworks

Penetration Testing Methodology

Chapter 3 · Standard Methodology Frameworks

pentest1-1 and pentest1-2 covered authorization and scope — the preconditions a real engagement needs before it starts. This chapter covers what "methodology" actually means once testing does start: a documented, standardized structure, not an individual tester's own improvised approach.

Why Standardized Frameworks Exist

Three concrete reasons a real engagement follows a published framework rather than one tester's own personal process:

  • Consistency — the same engagement produces comparable results whoever runs it, and results from different engagements over time can be meaningfully compared.
  • Completeness — a published framework was built and refined by many practitioners over years specifically to avoid skipped steps; an individual's own improvised checklist has no such guarantee.
  • Legal defensibility — if an engagement is ever scrutinized after the fact (a dispute, an incident, an audit), "we followed a recognized, published standard" is a genuinely different, stronger position than "we did what seemed reasonable at the time."

PTES — The Penetration Testing Execution Standard

PTES defines seven phases, in order: Pre-engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation, and Reporting. It's broad and technique-agnostic — it applies to network, web application, wireless, and social engineering engagements alike, rather than being scoped to any one category from pentest1-2's own list.

This course's own chapter order loosely mirrors PTES
pentest1-1/pentest1-2 map to Pre-engagement Interactions; pentest1-4 is Intelligence Gathering; pentest1-5 extends that into active Vulnerability Analysis groundwork; pentest1-6 is Vulnerability Analysis proper; pentest1-7 is Exploitation; pentest1-8 is Post Exploitation; pentest1-9 is Reporting. This wasn't a coincidence — this course's own structure is deliberately built around PTES's own phase order.

The OWASP Testing Guide

Where PTES is broad, the OWASP Testing Guide is deliberately narrow and deep: it's the field manual specifically for the Web Application scope category named in pentest1-2. It's maintained by the same organization behind owasp1's own Top 10 survey, and its testing categories map closely onto vulnerability classes this site already teaches in real depth — xss1, csrf1, and sqli1 each correspond to entire testing categories inside the Guide.

NIST SP 800-115

NIST's Technical Guide to Information Security Testing and Assessment is a US government publication, organized around four higher-level phases: Planning, Discovery, Attack, and Reporting. It's the framework most likely to be explicitly, contractually required — government contractors and organizations in regulated industries are often required to demonstrate compliance with a named NIST standard specifically, not just "a reasonable methodology."

FrameworkMaintained byScope/focusStructureBest fit
PTESCommunity/industry practitionersBroad — any engagement type7 phasesGeneral-purpose engagements of any scope category
OWASP Testing GuideOWASPNarrow — web applications specificallyCategory-based (mirrors owasp1's own Top 10)Web Application-scoped engagements
NIST SP 800-115US NIST (government)Broad, compliance-oriented4 phasesGovernment contracts, regulated industries requiring named-standard compliance
No framework is universally legally mandatory — but contracts and regulations often name one specifically
Following a published framework isn't a general legal requirement in itself. But specific contracts, industry regulations, or compliance frameworks (PCI DSS is a common real example) can explicitly require testing to follow a named standard. Confirming which framework — if any — an engagement is contractually or regulatorily required to follow is itself part of scoping, not an afterthought.

Hands-On Exercises

Exercise 1

Using this chapter's own tip-box, map each of PTES's seven phases to the specific chapter of this course that corresponds to it.

📄 View solution
Exercise 2

A security firm has been hired to test a government contractor's systems, and the contract explicitly requires NIST-standard compliance. Using this chapter's own comparison table, explain why PTES or the OWASP Testing Guide wouldn't satisfy this requirement even if either was followed thoroughly.

📄 View solution
Exercise 3

Using this chapter's own three reasons (consistency, completeness, legal defensibility), explain specifically why "we followed PTES" is a stronger position after an incident than "we did what seemed reasonable at the time," even if the actual steps taken were nearly identical.

📄 View solution

Chapter 3 Quick Reference

  • Standardized frameworks exist for three reasons: consistency, completeness, legal defensibility — not because improvisation necessarily produces worse individual results
  • PTES — 7 phases (Pre-engagement, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation, Reporting), broad/technique-agnostic; this course's own structure mirrors it
  • OWASP Testing Guide — narrow, web-application-specific, maps onto xss1/csrf1/sqli1/owasp1's own vulnerability categories
  • NIST SP 800-115 — 4 phases (Planning, Discovery, Attack, Reporting), government/compliance-oriented, often contractually required by name
  • No framework is universally mandatory, but specific contracts/regulations (e.g. PCI DSS) can require a named one — confirming this is part of scoping
  • Next chapter: Reconnaissance & OSINT — passive vs. active recon, extending net1-9's and host1's own DNS material