Penetration Testing Methodology: Steps, Phases and Frameworks

Penetration Testing Methodology: The Short Answer

A penetration testing methodology is a documented, repeatable process that defines what is tested, in what order, how evidence is collected and how findings are reported. Most teams run the engagement lifecycle from PTES or NIST SP 800-115 (scoping, reconnaissance, vulnerability analysis, exploitation, post-exploitation and reporting), use the OWASP Web Security Testing Guide for web and API test cases, and map attacker behavior to MITRE ATT&CK. The methodology matters because it makes results comparable between tests, auditable for requirements such as PCI DSS 11.4, and focused on business impact rather than raw scanner output.

Quick Answers

• What is a pentest methodology? It's a formal plan that outlines the phases and rules for an ethical hacking engagement, ensuring the test is safe, repeatable, and effective.
• PTES vs NIST? PTES is a practical, practitioner-focused framework, while NIST SP 800-115 is a more formal, documentation-heavy guide suited to compliance and enterprise environments. OSSTMM adds measurable results across people, facilities and networks, and the OWASP WSTG supplies the web and API test cases.
• How many steps are in a penetration test? Most guides describe five stages, PTES uses seven phases and NIST SP 800-115 uses four. They cover the same work: scoping, reconnaissance, vulnerability analysis, exploitation, post-exploitation and reporting.
• What's essential for a 2026 pentest? A modern pentest must be threat informed (using MITRE ATT&CK), cover cloud and APIs (using the OWASP Top 10:2025 and WSTG), and demonstrate real business impact, not just list vulnerabilities.

Penetration Testing Frameworks Compared

The frameworks below solve different problems. Some define the engagement lifecycle, some catalog technical test cases, and one describes attacker behavior. Most mature programs combine at least two. This table is the landscape at a glance; the four standards buyers ask about most, PTES, OSSTMM, NIST SP 800-115 and the OWASP WSTG, are compared criterion by criterion later in this guide.

Beyond the Checklist: What is a Real Pentesting Methodology?

Let's get one thing straight: a real penetration testing methodology is more than just a checklist. It's a formal, documented game plan that outlines the scope, phases, and rules for an ethical hacking engagement. Think of it as the strategic blueprint that separates a professional security assessment from an unstructured, ad hoc "hack." It ensures the process is repeatable, thorough, and, most importantly, safe for your environment.

In the early days of cybersecurity, pentesting was often an unguided art form. There were few rules or shared standards, so businesses did not know what to expect and results varied widely from one tester to the next. That's a huge problem. In 2026, with the average cost of a data breach in the U.S. at $11.5 million according to IBM's Cost of a Data Breach Report 2026, businesses can't afford inconsistency.

From my experience leading red team engagements, the choice of methodology is the single most important decision made before any testing begins. It dictates whether we simply find a list of CVEs or if we uncover the multi stage attack chain that could actually take down the business. It’s the core difference between a basic scan and a true security validation, a distinction we'll break down completely by exploring the difference between a vulnerability assessment and penetration testing.

The move toward formal methodologies wasn't an academic exercise; it was a direct market response to the increasing financial and reputational damage caused by data breaches. As the stakes grew, the need for auditable, repeatable, and professional security validation became a business necessity, driving the creation of standards like PTES and the adoption of government frameworks like NIST SP 800 115 to bring order and predictability to the field. Specialized engagements such as wireless penetration testing follow these same structured phases.

Ready to run this on your systems? Get started with our penetration testing services.

The Core Frameworks: Choosing Your Battle Plan

No single methodology is a silver bullet. A mature testing provider blends the lifecycle management of PTES or NIST with the technical depth of OWASP and the threat intelligence of MITRE ATT&CK. The sections below explain what each one does; the side-by-side comparison of PTES, OSSTMM, NIST SP 800-115 and the OWASP WSTG follows them.

The Penetration Testing Execution Standard (PTES): The Practitioner's Choice

If you want to know how pentesters actually think, PTES is your guide. It was designed by and for security practitioners to provide a clear, end to end baseline for a high quality pentest. It's less about rigid compliance and more about a practical, real world workflow that mirrors how actual attacks unfold. The standard itself has not been substantially revised in years, so most teams pair its seven phases with current technical references such as the OWASP testing guides and MITRE ATT&CK.

Here's the deal. The PTES methodology is broken down into seven distinct phases:

1. Pre Engagement Interactions: The critical planning phase to define scope, get written authorization, and establish the Rules of Engagement (RoE). You can learn more in our penetration testing RFP writing guide (2026).
2. Intelligence Gathering (OSINT): Using open source intelligence to collect public information about the target without touching their systems.
3. Threat Modeling: Analyzing intel to map out probable attack paths and focus on realistic business risks.
4. Vulnerability Analysis: A mix of automated scanning and manual validation to find potential weaknesses.
5. Exploitation: The "attack" phase, actively exploiting validated vulnerabilities to prove they are real.
6. Post Exploitation: Demonstrating the full business impact by escalating privileges and moving laterally.
7. Reporting: Delivering a final report with a non technical Executive Summary and a detailed Technical Report.

NIST SP 800-115: The Enterprise & Compliance Standard

If PTES is the practitioner's field guide, think of the Technical Guide to Information Security Testing and Assessment (NIST SP 800-115) as the official, government issued manual. Published in September 2008, it is still the current final version of the guide in 2026. It's a formal, structured methodology widely adopted by federal agencies and large enterprises that require a rock solid audit trail and comprehensive documentation of security testing activities.

NIST SP 800-115 breaks a penetration test into four phases:

• Planning: Rigorous documentation of the Test Plan and RoE with formal stakeholder sign off.
• Discovery: Information gathering and scanning, followed by vulnerability analysis.
• Attack: Controlled exploitation of vulnerabilities within strict, pre agreed safety constraints.
• Reporting: Runs alongside the other phases and ends with findings, risk ratings and mitigation guidance.

We often use the NIST framework when a client's primary driver is compliance, such as for FedRAMP penetration testing explained. Its structure is also a great fit for Penetration Testing for DevOps environments.

OWASP Web Security Testing Guide (WSTG): The AppSec Bible

The WSTG isn't a full lifecycle methodology. Instead, it's the definitive, open source checklist of technical security controls for any web application penetration testing services or API assessment, OWASP Web Security Testing Guide (WSTG). The latest stable release is WSTG v4.2, and OWASP is developing version 5. Its input-validation checks are where classes like template injection get systematically tested.

During the "Vulnerability Analysis" and "Exploitation" phases, my team uses the WSTG as our technical guide. If we're testing for Broken Access Control, which is still ranked first as A01:2025 in the OWASP Top 10:2025, we follow the specific test cases outlined in the WSTG. As threats evolve, so does OWASP, with projects like the OWASP Top 10 for Large Language Models, which tackles emerging AI cybersecurity threats in 2026.

Our OWASP Top 10 2025 guide explains each category and how pentesters test for it.

OSSTMM (Open Source Security Testing Methodology Manual): The Holistic View

The Open Source Security Testing Methodology Manual (OSSTMM) from ISECOM focuses on measuring operational security as a whole, going far beyond just digital assets. OSSTMM 3, published in 2010, remains the edition available as a free download; ISECOM is releasing OSSTMM 4 in stages, with early access for its members.

OSSTMM 3 structures its testing across five "channels": Human Security, Physical Security, Wireless Communications, Telecommunications, and Data Networks. Instead of ending with a list of vulnerabilities, it measures the attack surface: the rav balances porosity (the points where an attacker can interact with a target) against controls and their limitations, and results go into a Security Test Audit Report (STAR) signed by the analysts who ran the test.

ISSAF and CREST: Two Names You Will See in RFPs

The Information Systems Security Assessment Framework (ISSAF), published by the Open Information Systems Security Group (OISSG), is an older, very detailed checklist-style framework. It has not been actively maintained for years, so treat it as a reference rather than a primary methodology. CREST is different: it is not a methodology but an international not-for-profit accreditation body that accredits penetration testing companies and certifies individual testers (for example CRT and CCT). When an RFP asks for a CREST-accredited provider, it is asking for evidence that the vendor's processes and testers have been independently assessed, not for a specific set of test phases.

MITRE ATT&CK: The Threat Informed Lens

The MITRE ATT&CK framework is not a testing methodology itself. It's a globally accessible knowledge base of adversary tactics, techniques, and procedures (TTPs) based on real world observations. MITRE updates it about twice a year; as of November 2026 the current release is ATT&CK v20 (October 2026), so check which version your provider maps findings to.

• Pros: Enables realistic, threat informed testing; provides a common language for defenders and attackers; helps prioritize defenses against real world TTPs.
• Cons: It's a library of TTPs, not a step by step testing plan. It must be used to enhance other methodologies.

We use ATT&CK to make our tests more realistic. Instead of random exploits, we emulate the exact TTPs used by threat actors who target our client's industry, such as specific lateral movement techniques (T1021, Remote Services). This is fundamental to a true red team vs blue team explained engagement.

Adapting the Methodology for Cloud, APIs and AI

The lifecycle frameworks predate most of today's attack surface. NIST SP 800-115 was published in 2008, before managed cloud, containers and public APIs became the default, so a modern methodology adds technology-specific references to the same phases.

• Cloud: follow each provider's own testing policy, and test identity, IAM roles and misconfigured services as well as hosts. Our AWS penetration testing guide covers the AWS rules.
• Containers and Kubernetes: use NIST SP 800-190, the Application Container Security Guide, for the risk model, and test cluster RBAC, exposed dashboards and container escape paths. See our Kubernetes penetration testing guide.
• APIs: add the OWASP API Security Top 10 (2023 edition) to the WSTG test cases, with particular focus on object-level and function-level authorization. More in our guide to API penetration testing.
• AI and LLM applications: add the OWASP Top 10 for LLM Applications and MITRE ATLAS for prompt injection, data leakage and model abuse scenarios.

If these environments are in scope, ask your provider which of these references they test against. See our cloud penetration testing services and LLM and AI penetration testing services.

PTES vs OSSTMM vs NIST SP 800-115 vs OWASP WSTG

These four standards come up in almost every RFP and audit conversation, and they are often treated as interchangeable. They are not. PTES and NIST SP 800-115 describe how an engagement runs from scoping to reporting, OSSTMM measures operational security across people, places and networks, and the OWASP WSTG is a catalog of web application test cases. The table below compares them on the points that change how a test is scoped, run and reported. For version status and the wider landscape, including MITRE ATT&CK, see the frameworks overview table near the top of this guide.

When to Use Each Standard

In practice you rarely pick just one. Choose a lifecycle framework to run the engagement, then add the technical catalog that matches what is in scope. These rules of thumb cover most planning and buying decisions:

• PTES: use it as the default engagement structure for network, infrastructure and application tests. Its pre-engagement section works as a checklist for agreeing scope and rules of engagement before any testing starts.
• NIST SP 800-115: use it when the test has to stand up to an auditor, a regulator or a federal buyer. Its planning, discovery, attack and reporting phases and its rules of engagement template leave a documented trail. PCI DSS Requirement 11.4.1 asks for an industry-accepted methodology without naming a single one, and NIST SP 800-115 is one of the references commonly cited there.
• OSSTMM: use it when you need to measure security rather than only list vulnerabilities, or when the scope covers staff, physical sites, wireless and telecom alongside networks. Its rav metric gives you a number you can compare between tests, at the cost of more effort to learn and apply.
• OWASP WSTG: use it whenever a web application or API is in scope, inside whichever lifecycle framework you chose. Findings mapped to WSTG test IDs make a penetration testing report easier to verify and to retest.

A common combination for a SaaS company is PTES or NIST SP 800-115 for the engagement, the WSTG and the OWASP API Security Top 10 for the application, and MITRE ATT&CK to describe attacker techniques in the report. For a broader assessment that also covers offices, staff and network infrastructure, OSSTMM's five channels make a useful scope checklist even if the final report follows another format.

If a provider describes only a proprietary methodology, ask which of these four it maps to, and which phases, channels or test cases it leaves out. A clear answer to that question tells you more about coverage than the methodology's name.

Penetration Testing Steps: How to Conduct a Test in 6 Stages

Here’s a practical, step by step look at how a typical engagement works, combining the best of PTES and NIST.

Search for penetration testing steps and you will find five, six or seven stages. They describe the same work at different levels of detail. This is how the common five-stage model, the seven PTES phases and the four NIST SP 800-115 phases line up with the six steps below:

The step count matters less than what each step produces: a signed scope, a map of the attack surface, validated findings rather than scanner output, proof of business impact, and a report with retest results.

Step 1: Pre Engagement & Scoping (The Rules of Engagement)

This phase sets the foundation for everything that follows. The goal is to define exactly what will be tested, when, and how, and to get explicit, written permission. We craft the Rules of Engagement (RoE), a document that outlines testing windows, emergency contacts, and what actions are permissible.

Step 2: Intelligence Gathering (Reconnaissance)

The goal here is to collect as much information about the target as possible from public sources. This includes:

• Passive Recon (OSINT): Using Google Dorks and tools like theHarvester without directly interacting with the target’s systems. We also check data breach repositories like HaveIBeenPwned (HIBP) to see if employee credentials have been previously exposed.
• Active Recon: Using tools like Nmap to scan target IP ranges to discover live hosts, open ports, and running services.

Step 3: Scanning & Vulnerability Analysis

Now, we identify specific, potential vulnerabilities.

• Vulnerability Scanning: We use automated tools like Nessus or OpenVAS to check systems against a database of known vulnerabilities (CVEs).
• Manual Validation: This is the critical human element. A skilled tester manually verifies the findings from scanners to eliminate false positives.

Step 4: Exploitation (Gaining Access)

This is where we prove that a vulnerability is exploitable. We attempt to gain an initial foothold, perhaps using the Metasploit Framework for an unpatched service or exploiting a path traversal in client-side requests.

Step 5: Post Exploitation (Demonstrating Real Impact)

This phase answers the critical question: "So what?". Key activities include:

• Privilege Escalation: Attempting to elevate permissions from a standard user to an administrator.
• Lateral Movement: Using the compromised machine as a pivot point to access other systems, a key tactic in the MITRE ATT&CK framework.
• Data Exfiltration (Simulated): Identifying sensitive data to prove it could be stolen.

Step 6: Reporting & Remediation

The final goal is to deliver a clear, actionable report. A high quality report from a penetration testing provider includes an Executive Summary and detailed Technical Findings with remediation guidance.

Worked Example: The Phases in a Real DeepStrike Engagement

The phases are easier to judge when you see them applied. This example comes from a red team engagement DeepStrike has published as a case study, with client details removed. It is summarized here to show how each phase shaped the result.

• Scope: a multi-tenant SaaS platform where each customer had its own subdomain, all served by one shared API.
• Intelligence gathering: testers mapped how the platform separated tenants and found that the API used a client-supplied Source header to decide which tenant a request belonged to.
• Threat modeling: that design raised a concrete question: would an identity issued for one tenant be accepted by another?
• Vulnerability analysis: registering the same email address on two tenant subdomains succeeded. Each returned a JWT whose identity was the email rather than a unique subject ID, and neither token carried a tenant claim.
• Exploitation: a token issued on one subdomain, replayed against the other with a modified Source header, returned the matching user's profile from the other tenant.
• Post-exploitation: using administrator email addresses found through OSINT, the testers repeated the technique and reached full administrator access, including user accounts, credential resets, internal logs and billing data.
• Reporting and retest: the report and proof of concept reached the client three days after the first finding, and the client refactored token validation five days later.

The methodology lesson: no single scanner check would have flagged this. Each issue looked minor on its own, a duplicate registration, an email-based identity, a trusted header. Only phase-by-phase chaining showed the business impact. Read the full write-up in our JWT account takeover case study.

Pentesting in the Real World: Key Distinctions That Matter

Myth vs Fact: Vulnerability Assessment vs Penetration Test

• The Myth: The terms are interchangeable.
• The Fact: They are fundamentally different.
  • A Vulnerability Assessment is a broad, automated scan that identifies potential vulnerabilities.
  • A Penetration Test is a deep, manual process that exploits vulnerabilities to prove their business impact.

When to Choose a Red Team Engagement Over a Pentest

• Penetration Test Objective: Find as many vulnerabilities as possible within a defined scope. It's about breadth.
• Red Team Objective: Achieve a specific goal (e.g., "exfiltrate the customer database") while remaining undetected. It's about depth and stealth, designed to test an organization's detection and response capabilities.

Pentesting for Compliance: Meeting Regulatory Demands

PCI DSS Requirement 11.4

PCI DSS v4.0.1, the current version of the standard (v4.0 was retired at the end of 2024), covers penetration testing in Requirement 11.4. Requirement 11.4.1 calls for a defined, documented methodology based on industry-accepted approaches that covers the entire CDE perimeter and critical systems, segmentation controls, and both application-layer and network-layer testing. Approaches commonly used to meet it include NIST SP 800-115, PTES, OSSTMM and the OWASP testing guides. Requirements 11.4.2 and 11.4.3 require internal and external testing at least once every 12 months and after any significant upgrade or change, by a qualified tester with organizational independence. For a deep dive, see the PCI Security Standards Council document library and our PCI DSS penetration testing guide.

HIPAA Security Rule

The Health Insurance Portability and Accountability Act (HIPAA) requires regular risk analysis. While the current Security Rule doesn't explicitly mandate penetration testing, it's strongly advised to meet the requirement for a "thorough assessment of the potential risks and vulnerabilities" to protected health information (ePHI). HHS proposed in January 2025 to require penetration testing at least every 12 months, but as of November 2026 that rule has not been finalized. Our HIPAA penetration testing checklist 2026 can help.

SOC 2 and Cyber Insurance

Penetration testing has become a standard expectation for SOC 2 penetration testing requirements 2026 and a critical factor for penetration testing for cyber insurance eligibility. Insurers see regular testing as proof of due diligence and may deny coverage without it. This is especially true for penetration testing for startups and SMBs.

Key Statistics for 2026: Why Methodology Matters More Than Ever

• Small Businesses Are a Prime Target: It's a dangerous myth that attackers only go after large enterprises. Smaller organizations remain a frequent target because their defenses are often thinner; see our small business cyber attack statistics for current figures.
• The Human Element is a Top Risk: According to the 2026 Verizon Data Breach Investigations Report (DBIR), the human element was involved in 62% of breaches (up from about 60% in the 2025 report). This highlights the importance of testing against the latest phishing attack trends and statistics (2026).
• Vulnerability Exploitation is Surging: In the same report, exploitation of vulnerabilities became the top initial access vector at 31% of breaches, up from 20% a year earlier, and organizations in Verizon's data fully remediated only 26% of the vulnerabilities listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog that were found on their systems, taking a median of 43 days.
• The Cost of Crime is Exploding: The FBI's 2025 Internet Crime Report logged 1,008,597 complaints and reported losses of nearly $20.9 billion in 2025, up from $16.6 billion in 2024.
• Ransomware Payouts Remain High: Sophos' State of Ransomware 2026 survey put the median ransom payment at $769,000, down from $1 million in the 2025 survey but still a serious hit for most organizations. You can see more in our ransomware payout statistics and trends for 2026.
• IoT Devices are a Growing Target: Connected devices expand the attack surface, and many ship with weak default security. As our IoT hacking statistics roundup notes, Bitdefender and NETGEAR found the average home network faces 29 attacks per day across its 22 connected devices.

Buyer's Checklist: What to Ask a Pentesting Provider

• If you are evaluating penetration testing services in the U.S., what is your primary methodology (e.g., PTES, NIST)?
• How do you incorporate the OWASP WSTG for web applications?
• Do you use the MITRE ATT&CK framework to inform your testing?
• Can you provide a sanitized sample report?
• What are your procedures for handling sensitive data?
• What are the credentials and certifications of your testing team (e.g., OSCP, CREST CRT or CCT, CISSP)?
• How do you define the Rules of Engagement and handle scope creep?
• What is your communication plan during the test?
• Is re testing included after we remediate the findings?
• How do you ensure the testing process won't disrupt our operations?

Frequently Asked Questions (FAQs)

What are the 7 phases of penetration testing?

This refers to the Penetration Testing Execution Standard (PTES), which includes: Pre engagement Interactions, Intelligence Gathering, Threat Modeling, Vulnerability Analysis, Exploitation, Post Exploitation, and Reporting.

What are the 5 stages of penetration testing?

Most guides list five: planning and reconnaissance, scanning, gaining access (exploitation), maintaining access (post-exploitation), and analysis and reporting. The names vary between sources, and PTES splits the same work into seven phases.

What is the NIST penetration testing methodology?

NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, describes four phases: planning, discovery, attack and reporting. Discovery covers information gathering and vulnerability analysis, and the attack phase can loop back to discovery as testers gain new access. The current version was published in September 2008.

What is OSSTMM?

The Open Source Security Testing Methodology Manual (OSSTMM) is ISECOM's methodology for testing and measuring operational security. OSSTMM 3, released in 2010, covers five channels (human, physical, wireless, telecommunications and data networks) and expresses results as an attack surface metric called the rav, reported in a Security Test Audit Report (STAR). ISECOM is releasing OSSTMM 4 in stages.

Which penetration testing standard should I use: PTES, OSSTMM, NIST SP 800-115 or OWASP WSTG?

Use a lifecycle framework, PTES or NIST SP 800-115, to run the engagement, and add the OWASP WSTG whenever web applications or APIs are in scope. Choose NIST SP 800-115 when auditors or federal buyers expect a government reference, and OSSTMM when you need measurable results across people, facilities and networks. Most mature tests combine two or more.

What is the difference between a methodology and a framework?

In this context, they are often used interchangeably. A framework (like NIST or PTES) provides the high-level structure, while the methodology is the specific application of that framework, including the tools and techniques used.

How long does a penetration test take?

For buyers comparing penetration testing services in the UK, timing depends on scope. A small web application test might take one to two weeks, while a full internal and external penetration test for a large enterprise could take a month or more.

Is penetration testing required for compliance like PCI DSS or HIPAA?

Yes for PCI DSS: under PCI DSS v4.0.1, Requirement 11.4 requires internal and external penetration testing at least every 12 months and after significant changes. HIPAA's current Security Rule does not name penetration testing, but it requires a risk analysis and periodic technical evaluation, and many organizations use a pentest as evidence for both. HHS proposed in January 2025 to require penetration testing at least every 12 months; as of November 2026 that rule had not been finalized.

What is the most important phase of a penetration test?

While all are critical, many practitioners agree the Post Exploitation phase delivers the most value. It demonstrates the real world business impact of a breach, moving beyond a simple technical finding.

Can I perform a penetration test myself?

While you can run tools, a true penetration test requires deep expertise and an outside perspective. Many compliance standards, like PCI DSS, require the tester to be organizationally independent. You can explore the differences in our article on manual vs automated penetration testing.

How much does a penetration test cost?

Costs vary widely based on scope, complexity, and duration. For a detailed breakdown, see our guide on penetration testing cost.

A structured, repeatable penetration testing methodology is the foundation of modern security assurance. It's what transforms security testing from a guessing game into a strategic business function. Frameworks like PTES and NIST provide the roadmap, specialized guides like OWASP WSTG provide the technical depth, and threat intelligence from MITRE ATT&CK ensures the simulation is realistic. The ultimate goal is not to produce a list of CVEs, but to uncover and demonstrate tangible business risk, allowing you to prioritize your defenses effectively. Once the assessment concludes, some teams convert the final report from PDF to flipbook before sharing it with executives, making a dense technical document easier to navigate section by section.

Ready to Strengthen Your Defenses?

The threats of 2026 demand more than just awareness; they require readiness. If you're looking to validate your security posture, identify hidden risks, or build a resilient defense strategy, DeepStrike is here to help. Our team of practitioners provides clear, actionable guidance to protect your business.

Explore our penetration testing services for businesses to see how we can uncover vulnerabilities before attackers do. Drop us a line, we’re always ready to dive in.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.