What is a penetration testing methodology?
A penetration testing methodology is the documented, repeatable process testers follow from planning to reporting. The most widely referenced is NIST SP 800-115, which defines four phases: planning, discovery, attack and reporting. Testers pair it with the OWASP Web Security Testing Guide for applications and MITRE ATT&CK for describing attacker techniques.
A penetration testing methodology makes results comparable from one test to the next and lets auditors see what was tested and how. PCI DSS Requirement 11.4.1 goes further and requires a defined methodology based on industry-accepted approaches.
What are the four phases of NIST SP 800-115?
NIST SP 800-115 defines four penetration testing phases. Planning sets rules and goals. Discovery gathers information and identifies vulnerabilities. Attack verifies them through exploitation, looping back to discovery as access grows. Reporting documents findings and fixes, and runs alongside the other three phases rather than only at the end.
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, was published in September 2008.
Phase 1: Planning
Testers and the organization agree on scope, rules of engagement, testing windows, contacts and goals, and the organization gives written authorization. Nothing is tested in this phase. NIST stresses that management approval and clear rules are what separate a penetration test from an attack.
Phase 2: Discovery
NIST splits discovery into two parts:
- Information gathering and scanning: identifying hosts, open ports, services, domain names and other information about the targets.
- Vulnerability analysis: comparing what was found against vulnerability databases and the testers’ own knowledge to identify likely weaknesses.
Phase 3: Attack
The attack phase verifies potential vulnerabilities by trying to exploit them. NIST describes it as a loop of four steps:
- Gaining access: exploiting a weakness to get a foothold.
- Escalating privileges: moving from limited access to administrative control.
- System browsing: exploring the compromised system to find data and new targets.
- Installing additional tools: adding tools needed to go further.
Each new foothold feeds back into discovery, because access to one system reveals new targets. That loop is what separates a penetration test from a vulnerability scan.
Phase 4: Reporting
Reporting runs alongside the other phases: testers log activity during planning, discovery and attack. At the end, they deliver a report with findings, risk ratings, evidence and remediation guidance.
What else does NIST SP 800-115 cover?
Beyond the four phases, the guide groups assessment techniques into three families: review techniques (documentation, log, ruleset and configuration review), target identification and analysis (network discovery, port and service identification, vulnerability scanning, wireless scanning) and target vulnerability validation (password cracking, penetration testing and social engineering).
How do NIST SP 800-115 phases map to OWASP, PTES and MITRE ATT&CK?
Each NIST SP 800-115 phase lines up with parts of the other common frameworks. NIST planning matches PTES pre-engagement, discovery matches OWASP’s information gathering tests and ATT&CK reconnaissance, attack matches OWASP authentication and authorization tests and ATT&CK initial access through lateral movement, and reporting matches the OWASP and PTES reporting phases.
| NIST SP 800-115 phase | What testers do | OWASP WSTG categories | PTES phase | MITRE ATT&CK tactics | Deliverable |
|---|---|---|---|---|---|
| Planning | Agree on scope, rules of engagement, windows, contacts and written authorization | Scope and objectives (WSTG Introduction) | Pre-engagement Interactions; Threat Modeling | Choose which adversary techniques to emulate | Rules of engagement and test plan |
| Discovery: information gathering and scanning | Identify hosts, services, technologies and entry points | Information Gathering (WSTG-INFO) | Intelligence Gathering | Reconnaissance | Asset and attack surface inventory |
| Discovery: vulnerability analysis | Combine scanning with manual analysis of configuration, identity and cryptography | Configuration and Deployment Management (WSTG-CONF), Identity Management (WSTG-IDNT), Cryptography (WSTG-CRYP) | Vulnerability Analysis | Reconnaissance (gather victim host and identity information) | List of candidate vulnerabilities |
| Attack: gaining access | Exploit confirmed weaknesses to get a foothold | Authentication (WSTG-ATHN), Session Management (WSTG-SESS), Input Validation (WSTG-INPV) | Exploitation | Initial Access, Execution, Credential Access | Proof of exploitation |
| Attack: escalating privileges | Move from limited to administrative access | Authorization (WSTG-ATHZ) | Post Exploitation | Privilege Escalation | Privilege escalation path |
| Attack: system browsing | Find sensitive data and new targets from the foothold | Business Logic (WSTG-BUSL), API Testing (WSTG-APIT) | Post Exploitation | Discovery, Lateral Movement, Collection | Evidence of data access and attack chains |
| Attack: installing additional tools | Deploy tools needed to go further, within the rules of engagement | Rarely applies to web application tests | Post Exploitation | Persistence, Command and Control | Record of tools used and removed |
| Reporting | Document findings, risk ratings, evidence and fixes throughout and at the end | WSTG Reporting | Reporting | Findings mapped to ATT&CK techniques | Executive summary and technical report |
The OWASP Web Security Testing Guide supplies the detailed application test cases. MITRE ATT&CK gives a shared vocabulary for attacker behavior, which helps defenders turn findings into detection rules.
How does NIST SP 800-115 compare with PTES, OSSTMM and OWASP?
NIST SP 800-115 describes the overall testing process. PTES adds more detail on pre-engagement and post-exploitation. OSSTMM focuses on measurable operational security. OWASP’s guides supply specific test cases for web, API and mobile applications. Most providers combine NIST SP 800-115 for process with OWASP for application test cases.
| Framework | Publisher | What it covers | Best used for |
|---|---|---|---|
| NIST SP 800-115 (2008) | U.S. National Institute of Standards and Technology | Overall testing and assessment process, phases and techniques | Program structure and audit-ready process |
| PTES | Community-maintained standard | Seven phases from pre-engagement to reporting | Engagement planning and post-exploitation detail |
| OSSTMM 3 (2010) | ISECOM | Scientific, metrics-based operational security testing | Measuring security across channels, including physical and human |
| OWASP WSTG v4.2 (2020) | OWASP Foundation | Web application and API test cases by category | Application penetration tests |
| OWASP MASTG | OWASP Foundation | Mobile application test cases | iOS and Android testing |
| MITRE ATT&CK | MITRE | Catalogue of real-world attacker tactics and techniques | Describing findings and red team objectives |
| PCI SSC Penetration Testing Guidance | PCI Security Standards Council | How to scope and run tests for cardholder data environments | PCI DSS Requirement 11.4 |
Is NIST SP 800-115 still current?
It has not been revised since 2008, but its phases are still the most-cited public description of the penetration testing process. Its technique details predate modern cloud, API and identity attacks, which is why providers pair it with current guides such as OWASP and MITRE ATT&CK.
How do black box, gray box and white box testing change the methodology?
The phases stay the same; the time spent in each changes. Black box testing starts with no information, so discovery takes longer. Gray box testing provides credentials or limited documentation, shifting time to the attack phase. White box testing provides architecture details or source code, giving the deepest coverage in the shortest time.
What does PCI DSS require from a penetration testing methodology?
PCI DSS Requirement 11.4.1 requires a defined penetration testing methodology based on industry-accepted approaches. It must cover the entire cardholder data environment perimeter and critical systems, test from inside and outside the network, validate segmentation, include both application and network layers, and define how findings are documented, retained and remediated.
NIST SP 800-115 is one of the industry-accepted approaches the PCI Council’s own Penetration Testing Guidance refers to. Ask your provider to show how their methodology meets each element of 11.4.1.
What should you prepare before a penetration test?
Before a penetration test, define the objective and scope, name a technical contact, agree on testing windows and excluded systems, create test accounts for authenticated testing, notify hosting providers whose terms require it, and confirm how critical findings will be escalated. Preparation is the planning phase of NIST SP 800-115, and it decides how useful the test will be.
- Objective agreed (audit evidence, pre-launch check, real-world risk)
- Scope list: IP ranges, domains, applications, APIs, wireless sites
- Excluded systems and testing windows documented
- Test accounts created for each user role
- Technical contact and escalation path named
- Hosting and cloud provider notice requirements checked
- Written authorization and rules of engagement signed
- Backups and monitoring confirmed for in-scope systems
Frequently asked questions about penetration testing methodology
Does NIST SP 800-115 apply outside the U.S. government?
Yes. NIST wrote it for federal agencies, but it is free, vendor-neutral and widely used by private companies, auditors and providers worldwide as a reference for how penetration tests should run.
Is PTES better than NIST SP 800-115?
Neither is better; they work at different levels. NIST SP 800-115 is a broad process guide. PTES gives more practical detail on pre-engagement, threat modeling and post-exploitation. Many providers use both.
What penetration testing methodology does FedRAMP require?
FedRAMP publishes its own Penetration Test Guidance, which defines required attack vectors and reporting for cloud service providers. Tests must be performed by an accredited third-party assessment organization (3PAO).
How long does each phase take?
It depends on scope and test type. Planning happens before testing starts. Discovery and attack make up most of the testing window. Reporting runs throughout and is finalized after testing ends.
What is the difference between a methodology and a checklist?
A methodology defines the process and decisions; a checklist lists specific test cases. NIST SP 800-115 is a methodology. The OWASP WSTG test categories work more like a checklist inside the attack phase.
Work with a team that documents its methodology
Canary Trap has delivered penetration testing since 2020. Every engagement follows a documented methodology and ends with an executive summary and technical report your auditors and engineers can both use. Talk to our team to see a sample of how we scope and report.
Related guides: How Often Should You Conduct Penetration Tests? · How to Choose a Penetration Testing Company · Internal Penetration Testing · API Penetration Testing
