Pentest Methodologies & Standards

The 5-phases lesson gave you the mental map nearly every methodology reduces to. This lesson covers the actual named, formal frameworks professionals reference in real engagements and reports — genuinely useful vocabulary for both conducting and being taken seriously in real pentest work.

Why formal methodologies exist at all

A structured methodology ensures consistency across engagements and testers, provides a defensible, documented standard a client can evaluate a report against, and helps ensure nothing important gets accidentally skipped — directly connecting to Path 10's "measurement and structure beat ad-hoc practice" theme, applied here to the testing process itself.

PTES: Penetration Testing Execution Standard

The PTES organizes engagements into seven phases: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting — genuinely just a more granular, formalized version of the 5-phase model this path already taught, with pre-engagement (the RoE lesson's territory) and threat modeling made explicit as their own distinct phases.

OSSTMM: Open Source Security Testing Methodology Manual

The OSSTMM takes a broader, more measurement-focused approach, emphasizing quantifiable, repeatable security testing across multiple channels (not just networks — physical, human, and wireless security testing all get explicit treatment) with a formal scoring system for expressing results.

NIST SP 800-115: the government/enterprise standard

NIST SP 800-115 provides technical guidance specifically, organized around planning, discovery, attack, and reporting — directly connecting to Path 23's GRC material, since organizations operating under specific NIST-aligned compliance requirements often specifically expect testing to reference this standard.

OWASP Testing Guide: web-application-specific

Directly extending Path 11's entire web-security curriculum: the OWASP Testing Guide provides a detailed, web-application-specific testing methodology, mapping closely onto the OWASP Top 10 categories this course has covered throughout Path 11.

Why knowing these names matters practically

• Client expectations — some organizations, especially in regulated industries (Path 23), specifically require testing aligned to a named standard as part of their own compliance obligations
• Report credibility — referencing a recognized methodology in a report signals structured, professional rigor rather than ad-hoc testing, directly connecting to Path 21's Vulnerability Report Writer material
• Cross-team communication — using shared, recognized vocabulary makes it easier to communicate scope and approach with clients, other testers, and compliance teams who may already be familiar with these specific frameworks

Why might a client operating in a regulated industry specifically request that a penetration test follow NIST SP 800-115 or a similarly named standard, rather than simply asking for "a thorough test"?

Key terms

• PTES (Penetration Testing Execution Standard) — a seven-phase formal pentest methodology.
• OSSTMM — a measurement-focused testing methodology covering multiple security channels beyond just networks.
• NIST SP 800-115 — the NIST technical guide for security testing, often required in regulated/government contexts.

Recap

• PTES, OSSTMM, NIST SP 800-115, and the OWASP Testing Guide are the named, formal frameworks real pentest engagements reference, each a more structured elaboration of this path's 5-phase model.
• Formal methodology alignment matters for client compliance requirements, report credibility, and shared professional vocabulary, not just technical thoroughness.
• Knowing these names by reputation is genuinely practical — client requests and job postings reference them directly, expecting familiarity.

Next up → Reconnaissance in practice