Pentest Methodologies and Frameworks Compared

Clients ask which methodology you follow. PTES is a pentest lifecycle. CREST is an accreditation body. MITRE ATT&CK is a catalog of how adversaries behave. OWASP Top 10 is an awareness list, not a test plan. Treat them as interchangeable and you over-promise coverage, or you write a report the blue team cannot turn into detections.

These are also the testing frameworks and methodologies listed under CompTIA PenTest+ PT0-003 Objective 1.3: OSSTMM, CREST, PTES, MITRE ATT&CK, OWASP Top 10, MASVS, Purdue, DREAD, STRIDE, and OCTAVE. The comparison below is useful for real engagements and for certification prep.

This is a writing-only guide. Pick the stack that matches the scope, name it in the RoE, then do the technical work in later lessons.

Methodology, framework, and knowledge base

People use "methodology" and "framework" as synonyms in sales decks. For PenTest+ and for a defensible engagement, keep the jobs separate:

You can finish a pentest with PTES and never mention ATT&CK. You cannot run ATT&CK "instead of" PTES and still cover pre-engagement, RoE, and reporting.

NIST SP 800-115 sits next to PTES as a planning guide many regulated buyers recognize. The comparison table and PTES vs NIST section below cover it alongside the PT0-003 objective list.

Quick comparison

Use this table to pick a primary reference, then read the section for the ones that apply to your scope.

PTES vs NIST SP 800-115

PTES gives penetration testers a seven-phase, practitioner-oriented lifecycle from pre-engagement through reporting. NIST SP 800-115 organizes security assessments around planning, execution, and post-testing activities. It is the reference many government and enterprise buyers expect when they ask for NIST-aligned testing documentation.

Use PTES when you need a clear offensive workflow. Use NIST SP 800-115 language when the SoW or compliance program names NIST explicitly. Most firms still run a PTES-shaped test and cite 800-115 in the methodology section for auditors.

I use this stack in kickoff calls. PTES (or a firm playbook that looks like PTES) is the spine. Everything else hangs off a phase or a target type.

PTES seven-phase lifecycle

The Penetration Testing Execution Standard is the shared outline most firms can explain without a custom slide deck. Practitioners wrote it because every shop had invented a different phase list. The seven sections are:

1. Pre-engagement interactions
2. Intelligence gathering
3. Threat modeling
4. Vulnerability analysis
5. Exploitation
6. Post-exploitation
7. Reporting

PTES does not tell you which Nmap flags to use. A companion technical guide exists, but the standard itself is about what work happens in which order. That is why it shows up in pre-engagement scoping as the place you build RoE, and why reporting is its own phase instead of an afterthought.

When I write a methodology paragraph in an SoW, PTES is usually the skeleton:

Methodology: PTES-aligned engagement.
Pre-engagement and RoE before any scanning.
Intelligence gathering and vulnerability analysis against
in-scope CIDR and URLs only.
Exploitation and post-exploitation only where the RoE permits.
ATT&CK technique IDs in the attack narrative.
OWASP WSTG coverage for in-scope web applications.

Two caveats you should say out loud to the client:

• The public PTES wiki has not had a large formal revision in years. Treat it as structure, then layer current technique from OWASP, ATT&CK, and your own lab practice.
• Threat modeling in PTES is a phase, not a Microsoft STRIDE workshop. You still choose STRIDE, attack trees, or a lighter abuse-case list inside that phase.

OSSTMM operational security measurement

The Open Source Security Testing Methodology Manual (OSSTMM 3) comes from ISECOM. It tries to measure operational security instead of collecting a pile of CVEs. An OSSTMM audit looks at five channels:

• Human (social engineering, process, personnel)
• Physical (doors, badges, site access)
• Wireless (RF, not only Wi-Fi)
• Telecommunications
• Data networks

The distinctive output is the Risk Assessment Value (RAV) family of metrics. The idea is that two tests a year apart should be comparable, which a "we found 14 highs" report is not.

Use OSSTMM when the client actually bought a broad operational audit. For a web-only assessment, physical and human channel modules usually add scope the client did not request. Put those channels in the RoE as in or out; do not assume OSSTMM means you may phishing-test the helpdesk.

OSSTMM is also where exam questions about "scientific" or "quantitative" testing usually point. If the stem talks about channels and operational security rather than exploitation phases, think OSSTMM, not PTES.

CREST accreditation and defensible testing

CREST is a not-for-profit that accredits organizations against CREST standards and discipline requirements. Buyers use CREST accreditation as independent assurance that a provider has met CREST's organizational and service-specific requirements.

CREST does not give you a seven-phase pentest plan, a replacement for RoE or an SoW, or a promise that every test will use PTES or OWASP.

In practice you get:

• Company accreditation and a skilled-persons register
• Individual certifications at several levels
• The CREST Defensible Penetration Test (CDPT) discussion of commercially defensible assurance (scoping, sign-off, competency)
• CREST Application Security Testing (commonly referenced through the CREST OVS programme), which assesses organizations against OWASP ASVS and MASVS Levels 1 and 2

In the UK and several other markets, CREST also sits under government schemes (for example NCSC CHECK). For PenTest+, remember the exam objective is "testing frameworks and methodologies." CREST is the buyer-assurance answer. PTES is the phase-list answer. Mixing those two on a multiple-choice question is a common trap.

If a client requires a CREST-accredited supplier, that constraint belongs in pre-engagement, next to the NDA and SoW, not in the Nmap section of the report.

MITRE ATT&CK adversary behavior

MITRE ATT&CK catalogs tactics (the adversary's goal at a stage of the intrusion) and techniques (how they achieve it). Matrices exist for Enterprise, Mobile, and ICS. ATT&CK is particularly useful for red-team, purple-team, and detection-engineering work. Pentesters use it in a few honest ways:

• Plan a red-team scenario ("we will attempt T1078 Valid Accounts and T1021 Remote Services, not a full ransomware simulation")
• Label what you actually did after exploitation so the SOC can hunt for the same behavior
• Show coverage gaps ("we obtained a shell but never needed T1547 Boot or Logon Autostart because the local admin password was reused")

ATT&CK will not tell you whether production SAP is in scope, when to stop, or how to write the executive summary. Map findings to technique IDs in the attack narrative. Keep PTES or your firm process for the engagement.

A short report fragment looks like this:

Finding: local administrator hash reused on FILE01 and DC01.
ATT&CK: T1003 OS Credential Dumping, T1550.002 Pass the Hash.
Detection gap: no LSASS access alerting on FILE01.

A SOC can hunt from tactic and technique IDs. A CVE list with no tactics is harder to turn into detections.

OWASP Top 10 and MASVS

OWASP publishes several things that exam stems lump together. They serve different purposes and should be distinguished in the SoW.

OWASP Top 10

The OWASP Top 10 is an awareness document for the most critical web application security risks. The 2025 list is:

1. A01 Broken Access Control
2. A02 Security Misconfiguration
3. A03 Software Supply Chain Failures
4. A04 Cryptographic Failures
5. A05 Injection
6. A06 Insecure Design
7. A07 Authentication Failures
8. A08 Software or Data Integrity Failures
9. A09 Security Logging and Alerting Failures
10. A10 Mishandling of Exceptional Conditions

Use it to talk to developers and to sanity-check that a web test did not ignore access control because the scanner was busy with injection. Do not claim "we performed an OWASP Top 10 pentest" as if those ten rows were test cases. The OWASP Web Security Testing Guide (WSTG) is the actual web test-case catalog. ASVS is the verification standard buyers can put in a contract.

When you practice against DVWA, you are exercising WSTG-style test cases that happen to land in Top 10 categories. The lab is not "completing the Top 10."

OWASP MASVS

The Mobile Application Security Verification Standard is the mobile counterpart: control groups you verify on iOS and Android apps, not a ranked Top 10. Current groups include:

• MASVS-STORAGE
• MASVS-CRYPTO
• MASVS-AUTH
• MASVS-NETWORK
• MASVS-PLATFORM
• MASVS-CODE
• MASVS-RESILIENCE
• MASVS-PRIVACY

The companion testing material lives in the OWASP MAS project (MASTG and related checklists). MobSF is one lab tool you can point at an APK; MASVS is the control language you map those findings to. CREST Application Security Testing assesses organizations against MASVS and ASVS for accredited app work.

If the exam question says mobile app verification, answer MASVS. If it says most common web risks, answer Top 10. If it says how to test a login form, answer WSTG.

Purdue model for ICS and OT scope

The Purdue Enterprise Reference Architecture started as a 1990s manufacturing model. Security teams reused it as a way to talk about ICS and OT networks, because a plant is not one flat /24. Typical levels:

NIST SP 800-82 uses this kind of ICS architecture when it discusses OT assessment. IEC 62443 then talks about zones and conduits on top of the same mental picture. Purdue is the map. It is not the test procedure.

On an OT engagement, write Purdue levels into the asset list the same way you write CIDRs for an office network. "Test the plant" is not a scope line. "Level 3 and 3.5 in the coating line, no Level 0/1, no SIS" is a scope line.

Home-lab isolation in pentest lab requirements is the same habit at a smaller scale: attacker and targets on a private segment, nothing on the home LAN. Purdue is that idea with safety-critical equipment.

Threat modeling with STRIDE, DREAD, and OCTAVE

PTES puts threat modeling in phase 3. The exam then names three models that are not pentest phase lists. Use them inside design reviews and ranking conversations, not as the whole engagement.

STRIDE

STRIDE is Microsoft's mnemonic for threat types against a system you have already drawn (often as a data-flow diagram):

STRIDE is excellent in white-box and architecture reviews. It is a slow way to start an external black-box test where you do not have a DFD yet. On those tests, you still threat-model, but you do it from OSINT and attack trees rather than a full STRIDE matrix on day one.

DREAD

DREAD scores a threat on five factors from 1 to 10 each:

• Damage potential
• Reproducibility
• Exploitability
• Affected users
• Discoverability

Add the five scores and divide by five, or use another agreed formula, then rank. Microsoft's threat modeling guidance still documents DREAD with that 1 to 10 scale. DREAD is subjective because individual scorers can assign different values to the same threat. You will still meet it on PenTest+ and in older firm templates.

For vulnerability findings, CVSS provides a more standardized scoring system than DREAD. CVSS scores vulnerabilities, not generic architectural threats. If DREAD is required, document all five component scores and the reasoning behind them so the final rating remains auditable.

OCTAVE

OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) comes from CERT at the Software Engineering Institute. It is an organizational risk method: workshops that identify critical assets, threats to those assets, and mitigation priorities. OCTAVE Allegro is a later, lighter variant.

Pentesters do not run a full OCTAVE program as the pentest. The client security team might. Your job is to know that OCTAVE answers "which business assets matter" while STRIDE answers "how can this component be abused" and DREAD (or CVSS) answers "how bad is this one finding."

How to combine them on one engagement

Most tests use more than one of these names. The question is which layer each name occupies.

Worked example: a manufacturer wants a two-week test of the customer portal, the corporate Office 365 tenant they own, and a read-only look at the industrial DMZ. I would write:

• PTES for kickoff, intel, vuln analysis, limited exploitation, reporting
• OWASP WSTG for the portal; Top 10 as the exec-summary vocabulary
• ATT&CK technique IDs on any foothold in corporate IT
• Purdue: Level 3.5 in scope for configuration review, Levels 0 to 2 out of scope, no process manipulation
• CREST only if procurement already required an accredited supplier
• STRIDE on the portal if they delivered architecture diagrams (gray-box); skip a full DREAD matrix and use CVSS on findings

Name that stack in the RoE methodology section so nobody argues later that "OWASP" meant you should have phishing-tested the plant.

Track the work in whatever tracker you use. Cervantes is one option for findings and report workflow; it does not replace the methodology paragraph.

Common mix-ups

Summary

A pentest methodology is the ordered work from authorization through the report. PTES is the lifecycle most testers can explain without a slide deck. NIST SP 800-115 is the planning and documentation language many audited buyers expect. OSSTMM measures operational security across channels when the client bought that breadth. CREST accreditation tells a buyer the provider met CREST's organizational requirements. MITRE ATT&CK is none of those. It labels adversary behavior so the SOC can hunt.

OWASP Top 10 is how you talk about common web risks. WSTG and MASTG provide testing guidance; ASVS and MASVS define verification requirements for web and mobile applications. The Purdue model is how you keep a plant from being treated like an office VLAN. STRIDE classifies design threats, DREAD or CVSS ranks severity, and OCTAVE is an organizational workshop. None of that replaces exploitation or reporting.

Write the stack in the RoE before the first packet, then execute it. Turning that execution into a report a non-tester can read is a different article.

References

• Penetration Testing Execution Standard
• ISECOM — OSSTMM 3
• CREST
• CREST Defensible Penetration Test (PDF)
• CREST Application Security Testing (OVS programme)
• MITRE ATT&CK
• OWASP Top 10:2025
• OWASP Web Security Testing Guide
• OWASP Application Security Verification Standard
• OWASP MASVS
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security
• Microsoft Learn — STRIDE and DREAD in the Threat Modeling Tool
• FIRST — Common Vulnerability Scoring System
• SEI CERT — OCTAVE