Penetration Testing Frameworks
When you're doing a pentest, you can't just randomly poke at things and hope something breaks. You need a structured approach — something that tells you what to test, in what order, and how to prove you tested it. That's what frameworks are. They're not rules you follow blindly; they're maps that prevent you from missing entire attack surfaces.
There are several frameworks in active use, each born from a different philosophy. Some are academic, some are government-issued, some are built by practitioners who were tired of inconsistent engagements. Knowing which one to reach for — and why — is what separates a methodical tester from someone just running tools.
OSSTMM
The Open Source Security Testing Methodology Manual. This one comes from ISECOM and it's the most scientific of the bunch — it treats security testing like a measurable discipline rather than an art.
The core idea is RAV — Risk Assessment Value. Instead of just saying "this is vulnerable," OSSTMM gives you a numerical score based on attack surface, controls in place, and actual exposure. It covers not just technical systems but also physical security, human factors, and telecommunications.
In practice: OSSTMM is thorough to the point of being heavy. It's more suited for formal audits than a quick web app pentest. The value is in its completeness — it forces you to think about attack surfaces you'd otherwise skip.
Key channels it covers: Human, Physical, Wireless, Telecommunications, Data Networks.
OWASP WSTG
The OWASP Web Security Testing Guide. This is the one you'll actually use day-to-day if you're doing web app pentesting or bug bounty.
OWASP WSTG is organized around test cases — each one maps to a specific vulnerability class, has a defined objective, a testing procedure, and expected results. It covers everything from information gathering and authentication testing to business logic flaws and client-side attacks.
The structure:
- OTG-INFO — Recon and fingerprinting
- OTG-AUTHN — Authentication mechanisms
- OTG-AUTHZ — Authorization and access control
- OTG-INPVAL — Input validation (SQLi, XSS, XXE, etc.)
- OTG-SESS — Session management
- OTG-CRYPST — Cryptography
- OTG-BUSLOGIC — Business logic flaws
- OTG-CLIENT — Client-side attacks
This is the framework you open mid-engagement, not beforehand. You're testing auth bypass? Open the AUTHN section. It's a reference, not a book to read cover to cover.
NIST SP 800-115
Published by the National Institute of Standards and Technology. This is the U.S. government's take on how security testing should be done — formal, phase-based, and compliance-oriented.
It defines four phases:
- Planning — Scope, rules of engagement, objectives
- Discovery — Identifying systems, services, vulnerabilities
- Attack — Exploitation and validation
- Reporting — Documenting findings and remediation
NIST 800-115 is less about how to hack and more about how to run an engagement properly. It's what you reference when a client asks "what methodology do you follow?" and the answer needs to satisfy a compliance requirement. The technical depth is shallow compared to OWASP or PTES, but the process rigor is high.
PTES
The Penetration Testing Execution Standard. This one was built by practitioners — people who were actually doing engagements and needed a standard that reflected reality.
PTES has seven phases:
- Pre-engagement Interactions — Scope, contracts, legal clearance
- Intelligence Gathering — OSINT, recon, target profiling
- Threat Modeling — What's actually worth attacking given the target's business
- Vulnerability Analysis — Identifying weaknesses
- Exploitation — Actually getting in
- Post-Exploitation — Persistence, lateral movement, data exfil simulation
- Reporting — Findings, evidence, remediation advice
What makes PTES useful is that it mirrors how real engagements work. The threat modeling phase in particular is underrated — it forces you to think from an attacker's business perspective, not just a technical one. You're asking: what does this organization actually care about protecting, and what's the realistic path to compromising it?
ISSAF
Information Systems Security Assessment Framework. Older, nine-phase methodology that was influential in formalizing how assessments are structured.
The phases: Planning → Assessment → Treatment → Accreditation → Monitoring → Detection → Response → Recovery → Review.
ISSAF goes beyond just "find vulnerabilities" — it extends into incident response, recovery, and ongoing monitoring. It's more of a full security program framework than a pure pentest methodology. In modern practice it's largely been superseded by PTES and NIST, but it's worth knowing it exists, especially in enterprise contexts where the client wants to see a comprehensive lifecycle, not just an attack simulation.
MITRE ATT&CK
This is different from the others — it's not a testing methodology, it's a knowledge base of adversary behavior. ATT&CK catalogs real-world TTPs (Tactics, Techniques, and Procedures) observed from actual threat actors.
The structure:
- Tactics — The why (what the attacker is trying to achieve): Reconnaissance, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Exfiltration, Command and Control, Impact
- Techniques — The how (specific methods to achieve the tactic)
- Sub-techniques — Granular variants of techniques
- Procedures — How specific threat groups implement a technique
Where ATT&CK shines is in mapping your findings to real attacker behavior. Instead of just saying "we got RCE via SQLi," you can say "Initial Access via T1190 (Exploit Public-Facing Application), Execution via T1059.004 (Unix Shell)." This is meaningful to blue teams because it tells them what to detect, not just what was broken.
For bug bounty writeups and CTF reports, ATT&CK mapping adds immediate credibility. For red team engagements, it's how you demonstrate that your simulation reflects realistic threat actor behavior.
Other Notable Frameworks
A few worth knowing without going deep:
WASC Threat Classification — Web Application Security Consortium's taxonomy of web threats. Predates OWASP WSTG, less granular, occasionally referenced in older reports.
CSA Cloud Controls Matrix — Cloud-specific. Maps security controls across cloud service models (IaaS, PaaS, SaaS). Useful when the engagement scope includes cloud infrastructure.
OWASP MASTG — Mobile Application Security Testing Guide. Same philosophy as WSTG but for Android and iOS. Covers platform-specific attack surfaces like insecure storage, improper platform usage, and reverse engineering of mobile binaries.
PCI DSS Penetration Testing Guidelines — Compliance-driven. If the target handles payment card data, PCI DSS mandates specific testing requirements. You don't choose this one — the compliance requirement chooses it for you.
CBEST Framework — UK financial sector specific. Intelligence-led penetration testing for critical financial infrastructure. Threat-intelligence driven — you model real threat actors likely to target the specific institution before testing begins.
Choosing the Right Framework
The honest answer: you almost never use just one, and you almost never follow any of them completely.
A practical mapping:
| Scenario | Primary Framework | Supplement With |
|---|---|---|
| Web app bug bounty | OWASP WSTG | MITRE ATT&CK for reporting |
| Corporate network pentest | PTES | NIST 800-115 for process rigor |
| Compliance audit | NIST 800-115 or PCI DSS | OSSTMM if they want RAV scoring |
| Mobile app assessment | OWASP MASTG | WSTG for any web backend |
| Red team engagement | PTES + MITRE ATT&CK | Threat-intel to model adversary |
| Cloud environment | CSA CCM | PTES for execution |
The real skill isn't memorizing frameworks — it's knowing which parts of which framework apply to your current target, and using them as a checklist to make sure you haven't missed an entire attack category. The moment you're mid-engagement and you realize you haven't tested auth token expiry or checked for IDOR on a numeric ID endpoint — that's OWASP WSTG's job to catch.
Frameworks are a forcing function against tunnel vision.