
Professional penetration testing isn't improvised. It's anchored to published standards so that engagements are repeatable, defensible, and comparable across vendors. The four you'll encounter most are PTES, OSSTMM, NIST SP 800-115, and the OWASP testing guides, and they're not competitors so much as different lenses: engagement process, measurable rigor, regulatory baseline, and application-layer coverage.
This guide explains what each standard covers, where it shines, and how testers combine them. Knowing the standards helps you scope better, read reports critically, and ask vendors the right questions.
Standards matter because they make testing repeatable and comparable. Without a methodology, two testers attacking the same target could deliver wildly different results, and you'd have no way to judge quality. A standard defines what gets tested, in what order, and to what depth, so coverage isn't left to luck.
They also support compliance. Frameworks like SOC 2 and PCI DSS expect testing aligned to a recognized methodology. Following one of these standards is what separates a structured penetration testing methodology from an ad-hoc poke around.
PTES, the Penetration Testing Execution Standard, is the most complete end-to-end engagement framework. It defines seven sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. It's the standard most often mapped to the classic penetration testing phases.
PTES is strong because it covers the whole lifecycle, including the business-side parts like scoping, rules of engagement, and reporting that other standards skip. Its technical guidelines also recommend concrete tools and techniques. If you want one framework to structure a full engagement, PTES is usually it.
OSSTMM, the Open Source Security Testing Methodology Manual from ISECOM, is a rigorous, metrics-driven approach focused on measurable operational security. Instead of a vulnerability checklist, it defines how to test across channels (physical, wireless, telecom, data networks, human) and produces a quantified RAV (Risk Assessment Value) score.
Its strength is scientific rigor and repeatability: results are measured, not just described. That makes OSSTMM popular where you need defensible, comparable metrics over time. The tradeoff is that it's dense and less prescriptive about specific modern web tooling, so testers often pair it with OWASP for the application layer.
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, is the US government's reference for security testing. It defines four phases (planning, discovery, attack, reporting) and covers review techniques, target identification, and vulnerability validation at a high level.
It's the go-to baseline for federal agencies, contractors, and regulated industries because it's authoritative and widely accepted by auditors. It's deliberately less granular than PTES on technique, acting more as a policy-level standard you align to than a step-by-step playbook. Many engagements cite NIST for compliance while using PTES or OWASP for execution detail.
OWASP publishes the application-layer standards testers map findings to. The Web Security Testing Guide (WSTG) is the definitive checklist for web app testing; the Mobile standard MASVS covers iOS and Android; and the API Security Top 10 covers REST and GraphQL endpoints. The OWASP Top 10 categorizes the most critical web risks.
These aren't full engagement frameworks like PTES, they're coverage standards for a specific surface. A typical web test uses PTES for the overall process and the OWASP WSTG for the technical checklist. Mapping findings to OWASP categories also makes reports easier for developers to act on.