PENETRATION TESTING · CHOOSING A METHOD
Six frameworks get listed as if they were peers. Three of them stopped moving years ago, and one was never a testing method at all.
TL;DR
No framework makes you pick a methodology, and the methodology is not what makes a pen test good. Scope, tester skill and the report do. Of the six names you will see compared, only OWASP WSTG and MITRE ATT&CK still get updates. And ATT&CK is a catalogue of attacker behaviour rather than a test method. Pick by what you are testing, then spend your attention on the scope and the report.
Sources: Verizon DBIR 2026 · NIST SP 800-115
Why this matters more than it used to
The case for testing got stronger this year, and not in a way anyone predicted.
“Exploitation of vulnerabilities is now the most common initial access vector for breaches. It has risen to 31%”
Verizon, 2026 Data Breach Investigations ReportOn how attackers get in
Verizon notes this is the first time in 19 years that exploited vulnerabilities have passed stolen credentials as the top way in. Credential abuse dropped to 13%. Breaches involving a third party reached 48%, up 60% on the year before.
So the reason to test is no longer a compliance checkbox. It is that the thing a pen test looks for became the thing attackers use most.
A pen test is not a vulnerability scan
A scanner compares what it finds against a list of known issues and hands you the output. A penetration test is a person trying to get in, chaining small weaknesses into a real path, and stopping short of damage.
Two low-severity findings that combine into administrative access is the kind of thing a scan never reports and a tester lives for. That is what you pay for. A report full of scanner output with a human name on the cover is the most common way to waste the budget.
No framework requires a methodology
This surprises people who bought a test to satisfy an auditor.
SOC 2 does not require a penetration test at all. The Trust Services Criteria mention it under CC4.1 as one example of a monitoring activity, alongside others. Our breakdown of what a SOC 2 Type 2 report costs puts the line item at USD 4,000 to 30,000. That is real money to spend on an assumption.
ISO 27001 does not name one either. Annex A 8.8 asks you to manage technical vulnerabilities. A pen test is a common way to show you do, and it is not the only one. The standard names no methodology.
What trips people up
Auditors do expect a test, and enterprise buyers do ask for one. Those are real reasons to run one. “The framework requires it” is not, and starting from a false premise tends to produce a scope nobody chose on purpose. Decide what you want tested first.
Which of these are still maintained
Here is the part most comparisons leave out. Check the dates before you cite a framework in a statement of work.
| Framework | Current version | Dated | Still moving |
|---|---|---|---|
| OWASP WSTG | v4.2, with v5.0 in development | Dec 2020 | Yes |
| MITRE ATT&CK | Continuous releases | Current | Yes, but not a test method |
| PTES | v1.0, v2.0 planned and never shipped | c. 2014 | No |
| OSSTMM | 3 | 2010 | No |
| NIST SP 800-115 | Original, never revised | Sep 2008 | No |
| ISSAF | 0.2.1 | 2006 | No |
Frozen does not mean worthless. PTES still describes the shape of an engagement better than anything that replaced it. It does mean you should not treat a 2006 document as current practice. And you should not let a vendor wear one as a badge.
What each one is for
OWASP Web Security Testing Guide
The one to name when the target is a web application or an API. OWASP calls it “a comprehensive guide to testing the security of web applications and web services”, and it is an OWASP Flagship Project. Stable release v4.2 landed in December 2020 and v5.0 is in development.
It is a test catalogue rather than a process. Hundreds of specific checks, each with how to run it and what a failure looks like. That specificity is why it holds up.
PTES
Seven phases covering the whole engagement. Pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting.
PTES answers a question OWASP does not, which is how an engagement should run from first call to final report. Use it for the shape of the work. Use something current for the technical checks.
NIST SP 800-115
Published in September 2008 and never revised.
“The purpose of this document is to assist organizations in planning and conducting technical information security tests and examinations, analyzing findings, and developing mitigation strategies.”
NIST SP 800-115Technical Guide to Information Security Testing and Assessment
Read that purpose again. It is about planning, conducting and acting on tests, not about which payload to send. The process advice aged well. The technical detail did not, because it predates the cloud as most teams know it.
Name it when you sell to US federal or public sector buyers, who recognise it.
OSSTMM
ISECOM’s manual, version 3, from 2010. Its distinguishing idea is measurement. OSSTMM produces a RAV score, a number for operational security, rather than a list of findings.
That appeals to teams who want to track security over time. The trade is a vocabulary almost nobody else uses, and a document that has not moved in fifteen years.
ISSAF
Last released in 2006 and abandoned since. Listing it as a live option in 2026 is the clearest sign an article came together from other articles. Skip it.
MITRE ATT&CK
Current, excellent, and not a penetration testing methodology. ATT&CK catalogues the tactics and techniques real attackers use. It tells you what to emulate, never how to run an engagement.
It belongs in red team and adversary emulation work, where the goal is testing whether your detection fires. Pair it with a methodology. Do not substitute it for one.
What makes a pen test good
Three things, and the framework is not among them.
- Scope. What sits in and out, which environments, which credentials the tester gets, and whether social engineering and physical access count. A tester who starts with no credentials spends half the window at the front door.
- The tester. Skill and time decide the depth. Ask who does the work, not who signs the contract, and ask how many test days the window holds.
- The report. Findings ranked by real risk to you, with reproduction steps, evidence and a retest. A finding you cannot reproduce is a finding you cannot fix.
What good looks like
A statement of work that names the targets, the window and the test days. It names the methodology for the technical checks, and puts a retest in the price. Then a report with an executive summary your buyer can read and reproduction steps your engineers can follow.
What an auditor and a buyer want to see
Neither asks which methodology you used. They ask for evidence, and the shape of that evidence is the same in both directions.
- Scope and dates. What the tester covered, and when. A test from two product versions ago answers nothing.
- Method stated in one line. One line naming the framework your tester followed for the technical checks. It shows the work had a structure.
- Findings with severity. Ranked, with enough detail to judge them.
- Remediation and retest. The part people forget, and the part that carries the most weight. A high finding with a dated retest confirming the fix reads better than a clean report nobody can verify.
For the frameworks behind those questions, see what a SOC 2 report is and our complete ISO 27001 guide. The distinction between requirements and guidance comes up again in ISO 27001 vs ISO 27002.
Frequently asked questions
Does SOC 2 require a penetration test?
No. The Trust Services Criteria mention penetration testing under CC4.1 as one example of a monitoring activity, alongside others. Auditors expect a test and enterprise buyers ask for one, which are real reasons to run one. A requirement in the criteria is not.
Does ISO 27001 require a penetration test?
No, and it names no methodology. Annex A 8.8 asks you to manage technical vulnerabilities. A pen test is a common way to evidence that and it is not the only one. How you satisfy the control is your choice to justify.
Which penetration testing methodology should I pick?
Let the target decide. Web application or API, use OWASP WSTG. Infrastructure or a full engagement, use PTES for the shape and something current for the checks. US public sector buyers, name NIST SP 800-115. Red team work, use MITRE ATT&CK alongside a methodology rather than instead of one.
Is PTES still maintained?
No. PTES sits at version 1.0, and a version 2.0 has sat in the plan for years without shipping. The seven-phase structure still describes an engagement well. Treat the technical guidance as dated.
Is MITRE ATT&CK a penetration testing methodology?
No. ATT&CK is a catalogue of tactics and techniques that real attackers use. It tells you what to emulate, not how to run an engagement. It fits red team and adversary emulation work, paired with a methodology.
How often should we run a penetration test?
Once a year covers most buyer and auditor expectations, and after any significant change to the system in scope. A major release, a new environment or a change to how authentication works all justify a fresh test regardless of the calendar.
What is the difference between a pen test and a vulnerability scan?
A scan compares what it finds against known issues and reports the output. A pen test is a person attempting to get in, chaining weaknesses into a real path. A scan cannot tell you that two low-severity findings combine into administrative access.
Key takeaways
- Exploited vulnerabilities are now the top initial access vector at 31%, past stolen credentials for the first time in 19 years.
- Neither SOC 2 nor ISO 27001 requires a penetration test, and neither names a methodology.
- Only OWASP WSTG and MITRE ATT&CK still get updates, and ATT&CK is not a test method.
- PTES sits at v1.0, OSSTMM at 3 from 2010, NIST SP 800-115 at its 2008 original, ISSAF abandoned in 2006.
- Frozen is not worthless. PTES still describes engagement shape better than anything since.
- Scope, tester and report decide quality. The framework name does not.
- An auditor wants scope, dates, method, findings with severity, and a retest.
Buying a pen test to satisfy an auditor?
We scope the test against what your buyers and your auditor will ask for, then brief the testers. We turn the findings into remediation you can evidence. A named compliance manager runs it. Same process whether you sell in Toronto, Denver or both.