A penetration testing methodology is the step-by-step plan ethical hackers follow to attack your systems safely, find real weaknesses, and report them in a way you can fix. Without one, a pentest turns into a random tool run. Good methodologies borrow from published standards like PTES, NIST SP 800-115, and the OWASP Web Security Testing Guide. Below you'll find the 10 phases of a test, the main testing types, and how the major standards compare.
What is penetration testing methodology?
It's the repeatable process a tester follows, from scoping to retesting, so every test is safe, thorough, and comparable.
What are the phases of penetration testing?
Most tests move through scoping, reconnaissance, scanning, vulnerability analysis, exploitation, post-exploitation, reporting, and retesting.
What are the types of penetration testing?
By knowledge level: black box, gray box, and white box. By target: network, web app, mobile, API, cloud, social engineering, and physical.
Which penetration testing standard is best?
None fits everything. PTES covers the full process, OWASP WSTG covers web apps, and NIST SP 800-115 suits regulated teams.
Key Takeaways
- A methodology is the process. A method (black, gray, or white box) is how much the tester knows going in. You pick both.
- A full test runs through 10 phases, from scoping to retesting. PTES groups the core work into 7 phases, and NIST SP 800-115 into 4.
- Testing type follows the target: an API, a cloud account, and an office building each need different techniques.
- No single standard covers everything. Most good testers combine PTES for structure, OWASP WSTG for web apps, and MITRE ATT&CK for attacker behavior.
- Exploitation is only half the job. The report and the retest are what turn findings into fixes.
What Are the 10 Phases of a Penetration Testing Methodology?
Published standards split the work differently. PTES lists 7 phases, while NIST SP 800-115 (National Institute of Standards and Technology, 2008) uses 4: planning, discovery, attack, and reporting. The 10 phases below cover the full engagement, including the cleanup and retest steps that most standards leave out.
Phase 1: Pre-Engagement and Scoping
Every test starts with paperwork, and it matters more than any exploit. The tester and client agree on which IPs, apps, and accounts are in scope, the testing windows, and what's off-limits. This becomes the statement of work and the rules of engagement, signed before any traffic is sent. Scoping also sets the testing method (black, gray, or white box) and the goal, such as reaching customer data or a domain admin account. A vague scope is the most common reason a test misses the system that actually matters.
Phase 2: Reconnaissance (Intelligence Gathering)
Next, the tester learns everything an outsider could find about you. Passive recon uses public sources: DNS records, certificate transparency logs, old subdomains, job ads that name your tech stack, and leaked credentials. Active recon touches your systems directly, for example by checking which hosts respond. Tools like Amass, Shodan, and theHarvester speed this up. A forgotten staging server found here often becomes the easiest way in later.
Phase 3: Threat Modeling
With the attack surface mapped, the tester decides what is worth attacking and who would attack it. A fintech app faces fraud-driven attackers chasing payment flows. A hospital faces ransomware groups chasing downtime. The tester ranks assets by business value, such as customer records, admin panels, or payment APIs, and plans attack paths toward them. This phase keeps the test focused on real risk instead of whatever is easiest to scan.
Phase 4: Scanning and Enumeration
The tester now probes the targets in detail. Port scans with Nmap show which services are open. Enumeration digs further: software versions, user accounts, shared folders, API endpoints, and directory listings. On a web app, tools like Burp Suite map every page and parameter. The output is a detailed inventory of everything that can be attacked, with notes on what looks weak.
Phase 5: Vulnerability Analysis
Here the tester matches what was found against known weaknesses and looks for new ones. Scanners such as Nessus or Nuclei flag known CVEs and misconfigurations, but every result gets checked by hand to remove false positives. The tester also hunts for flaws no scanner understands, like broken access control or a password reset that can be abused. This step is where the difference between a pentest and a vulnerability scan becomes clear: a scan stops here, and a pentest keeps going.
Phase 6: Exploitation
The tester now tries to use the confirmed weaknesses to gain access, safely and within scope. That might mean a SQL injection that reads a database, a default password on a network device, or a chain of two low-risk bugs that together allow account takeover. Tools like Metasploit and sqlmap help, but most high-impact findings come from manual work. The tester stops at proof of access instead of causing damage, such as reading one record rather than dumping a whole table.
Phase 7: Post-Exploitation
Once inside, the question becomes: how far can an attacker go? The tester tries to escalate privileges, move laterally to other systems, and reach the goals set during scoping. In Windows networks this usually means attacking Active Directory, where tools like BloodHound reveal paths from a normal user to domain admin. Active Directory penetration testing often finds the shortest path to full control. This phase shows the real business impact of the initial foothold.
Phase 8: Cleanup and Evidence Handling
Good testers leave your environment the way they found it. They remove test accounts, uploaded files, web shells, and any tools placed on your systems. Every action has been logged with timestamps, so your team can match test activity against alerts and tell it apart from real attacks. Evidence like screenshots and captured data is stored encrypted and deleted on an agreed schedule. Most standards skip this step, but a test that leaves a backdoor behind creates new risk.
Phase 9: Reporting
The report is the product you actually pay for. It should include a short executive summary for leadership and a technical section for engineers. Each finding needs a severity rating, proof of exploitation, steps to reproduce, and specific fix guidance. Strong reports also show attack chains, so readers see how several small issues combined into a serious breach path. A penetration testing report example shows what this looks like in practice.
Phase 10: Remediation Support and Retesting
Findings only reduce risk once they're fixed. In this final phase, the tester answers developer questions and confirms that each fix closes the issue without opening a new one. A retest checks every finding again and updates its status in the report. Many teams also need an attestation letter for auditors or customers at this stage. Skip the retest and you have a list of problems with no proof they're gone.
How the 10 phases map to PTES and NIST SP 800-115:
Phase | PTES phase | NIST SP 800-115 phase |
|---|---|---|
1. Pre-engagement and scoping | Pre-engagement Interactions | Planning |
2. Reconnaissance | Intelligence Gathering | Discovery |
3. Threat modeling | Threat Modeling | Planning |
4. Scanning and enumeration | Intelligence Gathering | Discovery |
5. Vulnerability analysis | Vulnerability Analysis | Discovery |
6. Exploitation | Exploitation | Attack |
7. Post-exploitation | Post-Exploitation | Attack |
8. Cleanup and evidence handling | Not a separate phase | Not a separate phase |
9. Reporting | Reporting | Reporting |
10. Remediation and retesting | Not a separate phase | Not a separate phase |
What Are the Main Types of Penetration Testing?
Penetration tests are grouped two ways: by how much the tester knows at the start, and by what is being tested. The first is often called the testing method, as opposed to the overall methodology.
By knowledge level:
Method | What the tester gets | Best for | Trade-off |
|---|---|---|---|
Black box | Only a company name or a URL | Seeing what an outside attacker could find with no help | Time goes into discovery, so less gets tested in depth |
Gray box | Partial access, such as a user login or a network diagram | Most business apps and networks, because it mimics a stolen account or an insider | Slightly less realistic than black box for outside attacks |
White box | Full access: source code, architecture docs, admin credentials | Pre-release apps and high-risk systems that need the deepest coverage | Doesn't test how well your systems hide information from outsiders |
By target:
Type | What gets tested | Common findings |
|---|---|---|
External network | Internet-facing servers, VPNs, firewalls, email gateways | Exposed admin panels, unpatched VPNs, weak TLS |
Internal network | What an attacker can reach after getting inside | Weak Active Directory settings, flat networks, password reuse |
Logins, sessions, forms, business logic | Broken access control, injection, logic flaws | |
Mobile application | iOS and Android apps plus their backend APIs | Insecure local storage, hardcoded keys, weak certificate pinning |
API | REST, GraphQL, and gRPC endpoints | BOLA, broken authentication, excessive data exposure |
AWS, Azure, and GCP accounts and services | Over-permissive IAM roles, public storage buckets | |
Wireless | Wi-Fi networks and guest segmentation | Weak WPA keys, rogue access points, guest-to-corporate access |
Staff responses to phishing, calls, and pretexting | Credential capture, MFA fatigue, help desk resets | |
Physical | Offices, data centers, badge systems | Tailgating, cloned badges, unlocked server rooms |
Penetration testing vs. red teaming: A pentest tries to find as many exploitable weaknesses as possible in a defined scope. A red team engagement has one objective, such as reaching a payment system, and also tests whether your security team detects and stops the attack. Most companies need several pentests before a red team exercise is worth the cost.
One-time vs. continuous testing: A traditional pentest is a snapshot taken once or twice a year. Penetration Testing as a Service (PTaaS) spreads testing across the year through a platform, so new releases get tested as they ship. Teams that deploy weekly often combine both.
Which Penetration Testing Standards and Frameworks Should You Know?
Six references show up in almost every professional engagement. They aren't competitors. Each one answers a different question, so experienced testers combine them.
Standard | Maintained by | What it covers | Best for |
|---|---|---|---|
PTES (Penetration Testing Execution Standard) | Security practitioner community | The full engagement lifecycle in 7 phases, from pre-engagement to reporting | Structuring any pentest from start to finish |
OWASP Web Security Testing Guide (WSTG) | OWASP Foundation | 12 categories of web tests, from information gathering to API testing | Web applications and APIs |
NIST SP 800-115 | National Institute of Standards and Technology | Planning, discovery, attack, and reporting, with strong guidance on governance | Government, healthcare, finance, and other regulated teams |
OSSTMM | ISECOM | Operational security across networks, wireless, telecom, physical sites, and people | Measuring security with numbers instead of opinions |
ISSAF | Open Information Systems Security Group (OISSG) | Detailed steps tied to specific tools | Reference material; it is no longer actively updated |
MITRE ATT&CK | MITRE | A catalog of real attacker tactics and techniques, not a phase list | Red teams and mapping findings to how real groups operate |
For mobile apps, testers usually add the OWASP Mobile Application Security Testing Guide (MASTG), which plays the same role for iOS and Android that WSTG plays for web apps.
Where compliance fits: Frameworks like PCI DSS, SOC 2, HIPAA, and ISO 27001 don't define how to test. They define when a test is needed and what evidence an auditor expects. PCI DSS Requirement 11.4.1, for example, asks for a documented, industry-accepted methodology, and testers usually meet it with PTES, NIST SP 800-115, or OWASP. A PCI DSS penetration test then maps each finding back to the cardholder data environment.
How Do You Choose the Right Penetration Testing Methodology?
Start from what you need to protect and who needs to see the results. These questions narrow it down quickly.
- What is the target? Web apps and APIs call for OWASP WSTG. Mobile apps add OWASP MASTG. Networks and Active Directory lean on PTES and MITRE ATT&CK.
- Which compliance framework applies? PCI DSS, SOC 2, HIPAA, and ISO 27001 each expect certain evidence. Tell the tester up front so the report maps findings to the right controls.
- What are you trying to simulate? An outside attacker points to black box. A stolen employee login points to gray box. A pre-launch code review points to white box.
- How often do you ship changes? Annual testing suits stable systems. Weekly releases need continuous or per-release testing.
- Do you also want to test detection? If yes, you're looking at a red team or purple team engagement, not a standard pentest.
- Can the vendor show its methodology in writing? Ask for a sample report and a description of each phase. A vendor that can't explain its process won't follow one.
How OraSec Can Help
OraSec follows the 10-phase approach above on every engagement, with manual testing at each step and a retest included. The team builds each test on PTES for structure, OWASP WSTG and MASTG for apps, and MITRE ATT&CK for attack paths, then maps the findings to the compliance framework your auditor uses.
OraSec offers more than 20 penetration testing services, including web, mobile, API, cloud, Active Directory, OT/SCADA, AI/LLM, and physical testing. A typical web application assessment takes one to two weeks, and a full network test two to three. The same people who test your systems also do original research, with published CVEs (CVE-2025-50847 through CVE-2025-50850) to show for it.
For Ignite, a national technology fund, OraSec ran a black-box test of the fund's website and delivered a detailed report with clear fixes. In its review on The Manifest, the client praised how thorough the reporting was and how much value it got for the cost. If you ship often, Pentia, OraSec's PTaaS platform, turns that work into continuous testing.
Conclusion
A penetration testing methodology is what separates a real test from a scanner run with a logo on it. The 10 phases give the work a safe start, a focused middle, and an ending you can act on. The testing type decides what gets attacked, and standards like PTES, OWASP WSTG, and NIST SP 800-115 keep results consistent from one year to the next. When you compare vendors, ask how they handle each phase, which standards they follow, and what the report and retest include. Those answers tell you more than any price quote.
Frequently Asked Questions
What are the 5 phases of penetration testing?
Shorter models use reconnaissance, scanning, gaining access, maintaining access, and reporting. It's the same work as the 10 phases above, just grouped more broadly.
How long does a penetration test take?
A web application test usually takes one to two weeks of active testing, and a network test two to three. Reporting and a retest follow.
How much does a penetration test cost?
Most professional tests fall between about $4,000 and $30,000, depending on scope. The penetration testing cost guide breaks this down by test type.
What is the difference between PTES and OWASP?
PTES describes how to run the whole engagement. OWASP WSTG lists the specific tests to run against a web app, so most web tests use both.
Is black box testing better than white box testing?
Not always. Black box is more realistic for outside attacks, but white box finds more flaws in the same time because the tester skips discovery.
How often should a company run a penetration test?
At least once a year and after major changes, such as a new app release or a cloud migration. PCI DSS v4.0.1 requires this for systems in scope.
