July 10, 202618 min read

Penetration Testing Methodology: Complete Framework for Enterprise Security Teams (2026)

Sources:Penetration Testing Execution Standard (PTES)|OWASP Web Security Testing Guide v4.2|NIST SP 800-115: Technical Guide to Information Security Testing and Assessment|PTES Technical Guidelines

Eric Bang

Founder & Cybersecurity Evangelist

PTES

Penetration Testing Execution Standard: the most widely referenced penetration testing methodology framework, covering pre-engagement, intelligence gathering, threat modeling, exploitation, post-exploitation, and reporting phases

7 phases

the PTES methodology covers seven phases: pre-engagement interaction, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting

Rules of engagement

the most commonly skipped pre-engagement document -- the ROE defines testing scope, out-of-bounds systems, authorized techniques, and escalation procedures, and is the legal authorization for the engagement

4 target types

methodology adapts across four primary target types: web application, external/internal network infrastructure, cloud environment (AWS/Azure/GCP), and AI/LLM systems -- each with distinct reconnaissance, exploitation, and documentation requirements

Phase 1: Pre-Engagement and Scoping

Pre-engagement is where the most consequential decisions in a penetration test are made. The quality of the scoping document determines the quality of the test. Rushing pre-engagement to get to 'the interesting part' produces a test that misses the organization's actual attack surface.

Scope document: what is included and what is explicitly excluded

The scope document enumerates every asset authorized for testing: IP ranges, domain names, web application URLs, cloud account IDs, mobile application identifiers, and API endpoints. It explicitly lists out-of-bounds assets -- production databases, third-party services, partner network segments -- to prevent inadvertent testing of systems outside authorization. Scope documents should be written by the security team, not the testers, and reviewed by legal before signature.

Rules of engagement: what is authorized, what is prohibited

The rules of engagement (ROE) is a separate document from the scope that defines testing technique authorization: whether social engineering (phishing) is in scope, whether physical penetration is authorized, whether denial-of-service testing is permitted, whether destructive testing (ransomware simulation, data deletion) is explicitly authorized or prohibited, and whether password cracking using cloud compute resources is permitted. The ROE should include the testing window (authorized hours for active testing), the escalation procedure (what happens if a zero-day or active breach is discovered during testing), and the emergency contact chain.

Asset inventory and attack surface documentation

Before testing begins, the tester should receive the organization's current asset inventory: IP space, domain registrations, cloud account structure, known internet-facing services, and identity infrastructure overview. This baseline prevents time waste on reconnaissance already done internally and ensures the scope document covers the full attack surface. If the test is 'blind' (no prior information provided), document that decision and its rationale in the scope agreement.

Legal authorization and get-out-of-jail letter

Every penetration test must produce a signed statement of authorization from an individual with legal authority to authorize the test. This document -- sometimes called a 'get-out-of-jail letter' -- states that the organization authorizes the named testers to perform the defined testing activities against the specified assets between the specified dates. Testers operating without signed authorization are legally exposed even if they believe verbal permission was granted.

Success criteria and reporting requirements

Define what a successful engagement looks like before it starts: what objectives constitute success (demonstrated domain admin compromise, exfiltration of defined data set, access to a defined high-value asset), what the deliverables are (written report, executive summary, raw finding data, remediation verification opportunity), and what the report will contain. Organizations that do not define success criteria receive reports that reflect what the tester found, not what the organization needed to know.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Phase 2: Intelligence Gathering and Reconnaissance

Intelligence gathering is systematic attack surface enumeration. In a black-box test it starts from the organization's name. In a gray-box test it starts from the scope document. In both cases, the goal is the same: a complete map of the attack surface before any exploitation attempt.

Passive OSINT: what is publicly available without touching the target

Passive reconnaissance uses public sources that do not generate traffic to the target organization's infrastructure: WHOIS and domain registration data, certificate transparency logs (crt.sh) for subdomain enumeration, Shodan and Censys for internet-facing asset discovery, LinkedIn and company websites for employee information (useful for phishing scope), GitHub and code repositories for exposed secrets and architecture information, and Google dorking for sensitive files in search indexes. Document every passive finding -- passive OSINT sources are not in scope limitations for most ROEs.

Active reconnaissance: direct enumeration of in-scope assets

Active reconnaissance generates traffic to in-scope systems and should begin only after confirming scope authorization. DNS enumeration (brute-force subdomain discovery via tools like dnsx, amass, or subfinder), port scanning (nmap against in-scope IP ranges), service fingerprinting, SSL/TLS certificate enumeration, and web crawling of in-scope domains. Document every active technique used and the timestamps of first contact with each target -- this record is essential if the client reports anomalous traffic during the engagement period.

Threat modeling: which attack paths matter most

After reconnaissance, apply threat modeling to prioritize the attack surface: which systems are highest-value targets, which attack paths are most likely given the organization's industry and adversary profile, and which finding would have the greatest business impact if exploited. Threat modeling prevents pentest reports full of low-severity findings on irrelevant systems while missing the critical path from internet to crown jewel. STRIDE or ATT&CK Navigator are appropriate frameworks for documenting the threat model.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Phase 3: Vulnerability Analysis

Vulnerability analysis is systematic identification of exploitable weaknesses -- distinct from exploitation. It produces the candidate finding list that Phase 4 (exploitation) will validate.

Automated scanning: establishing the baseline

Authenticated and unauthenticated vulnerability scans against in-scope systems using tools appropriate for the target type (Nessus or Qualys for network infrastructure, Burp Suite Pro for web applications, ScoutSuite or Prowler for cloud environments). Automated scanning establishes the baseline of known vulnerabilities and misconfigurations. It does not replace manual testing -- automated scanners consistently miss business logic flaws, chained vulnerabilities, and authentication bypass issues that require context.

Manual analysis: what scanners miss

Manual vulnerability analysis focuses on the classes of vulnerabilities that automated scanners consistently miss: authentication and authorization flaws (IDOR, broken access control, JWT manipulation), business logic vulnerabilities (price manipulation, workflow bypass, race conditions), server-side request forgery in complex multi-component architectures, and chained vulnerabilities where no single finding is critical but the combination is. Manual analysis time should be concentrated on high-value targets identified during threat modeling.

Configuration review

Security configuration review evaluates whether systems are hardened against established baselines (CIS Benchmarks, DISA STIGs, vendor security hardening guides). Configuration findings are often excluded from automated scanner results but represent significant risk: default credentials, unnecessary services, overly permissive firewall rules, weak TLS configurations, and audit logging gaps. Automated configuration scanning (Lynis for Linux, CIS-CAT for benchmarks) covers this efficiently at scale.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Phase 4: Exploitation

Exploitation validates that identified vulnerabilities are actually exploitable -- not theoretical. The distinction between 'the vulnerability exists' and 'we can exploit it to achieve this impact' is the most important quality gate in a penetration test. Unexploited theoretical vulnerabilities produce lower-quality reports than fewer, fully validated exploited findings.

Prioritize exploitation by business impact, not technical severity

Exploit the vulnerabilities that lead to the highest-impact outcomes first: paths from unauthenticated internet access to internal network access, authentication bypass on critical systems, vulnerabilities that enable lateral movement to high-value assets. A CVSS 7.5 vulnerability that provides a direct path to the domain controller is more valuable to exploit and document than a CVSS 9.8 vulnerability on an isolated test system with no network connectivity to production.

Document exploitation artifacts

Every exploitation must be documented with: timestamp, target system, vulnerability exploited, tool or technique used, the specific payload or command executed, the result achieved (shell access, file read, credential capture), and screenshots or terminal output confirming the result. Documentation during exploitation prevents the common problem of 'I exploited it but I cannot reproduce the exact steps for the report.'

Minimum necessary access principle

Exploitation should demonstrate impact with minimum necessary system access. The ROE should specify whether 'demonstrating access is sufficient' or whether 'exfiltrating a defined data set is required to demonstrate impact.' If the ROE does not specify, default to demonstrating access (reading a known non-sensitive test file, capturing a screenshot of a restricted dashboard, obtaining a non-sensitive credential) rather than taking actions with potential operational impact.

Escalation procedures for unexpected findings

If active exploitation reveals an ongoing breach (ransomware pre-positioning, active C2 beaconing, unauthorized user accounts), the ROE should specify the escalation procedure. Do not continue testing when an active breach is suspected. Stop, document the finding, and contact the defined escalation contact immediately -- continuing the test risks destroying forensic evidence or complicating incident response.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Phase 5: Post-Exploitation

Post-exploitation demonstrates the realistic impact of a successful attack beyond initial access. Initial compromise of a single system is rarely the end of an attack -- adversaries pivot, escalate, and establish persistence. Post-exploitation validates whether the initial foothold provides a meaningful path to higher-value targets.

Lateral movement: can initial access reach high-value targets

From the initially compromised system, attempt to reach in-scope high-value targets: domain controllers, database servers, financial systems, identity systems. Document the lateral movement path: which credentials were reused, which protocols enabled movement (SMB with captured hashes, RDP with stolen credentials, cloud API keys found in file system), and which network segments were reachable from the initial foothold. The lateral movement chain is often the most valuable finding in the report -- it shows the realistic blast radius of an initial compromise.

Privilege escalation: local to domain admin

From any low-privilege foothold, attempt privilege escalation: local administrator (via unpatched local vulnerabilities, service account abuse, or scheduled task manipulation), then domain administrator (via Kerberoasting, AS-REP Roasting, ADCS certificate abuse, DCSync from a compromised privileged account). Document each escalation step with the specific technique and the privilege level achieved.

Persistence simulation (documented, not installed)

If the ROE authorizes persistence simulation, document how an attacker would establish persistence -- which scheduled task would be created, which registry key would be written, which user account would be added to which group -- without actually installing persistent mechanisms. Installed persistence left on production systems causes significant operational problems. The documentation demonstrates the technique without the operational risk.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Phase 6: Reporting Standards

The penetration test report is the deliverable. Testing quality is irrelevant if the report does not communicate findings in a format that enables remediation prioritization. These are the standards that separate reports security teams use from reports that sit unread in a SharePoint folder.

Executive summary: one page, business impact, no jargon

The executive summary should be written for a CISO presenting to a board, not for a penetration tester. It covers: overall risk rating, the most critical findings with their business impact in plain English, what was tested, what was not tested, and the top three remediation priorities. No CVE numbers, no CVSS scores, no technical jargon. If a board member cannot understand the executive summary, rewrite it.

Finding format: title, severity, impact, evidence, remediation

Every finding should include: a descriptive title (not 'SQL Injection' but 'SQL Injection on /api/login Enables Unauthenticated Database Access'), a severity rating with justification (CVSS v4.0 base score plus contextual adjustment), a plain-English description of the vulnerability, a step-by-step reproduction procedure, screenshot or terminal output evidence, confirmed business impact (what an attacker can do with this vulnerability), and specific remediation guidance with referenced standards (OWASP, CIS, vendor documentation).

Attack narrative: chain the findings

In addition to per-finding documentation, the best penetration test reports include an attack narrative: a chronological account of how the tester moved from initial access to the highest-impact outcome. The narrative makes the systemic risk visible -- showing that five medium-severity findings chain together to produce a critical-impact path is more compelling than five isolated medium-severity findings.

Remediation prioritization matrix

Provide a prioritized remediation list that orders findings by the combination of exploitability and business impact, not CVSS score alone. A CVSS 9.0 vulnerability on a non-internet-facing system with compensating controls is lower remediation priority than a CVSS 6.5 vulnerability that provides unauthenticated access to customer data. The matrix should give the security team a sequenced remediation plan, not a raw severity list.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Methodology Variations by Target Type

The core methodology phases apply across all target types, but the specific techniques, tooling, and documentation standards vary by what is being tested.

Web application penetration testing

OWASP Web Security Testing Guide v4.2 is the standard methodology reference for web application testing. The OWASP Top 10 provides the minimum coverage checklist, but complete web application testing extends to all OWASP WSTG categories: authentication, authorization, session management, input validation, business logic, API security, and client-side controls. Burp Suite Pro is the standard tool for web application testing. Document every tested endpoint, every input validated, and every authorization boundary evaluated -- web application test reports frequently lack reproducibility because findings cannot be mapped back to specific test cases.

Cloud penetration testing (AWS, Azure, GCP)

Cloud penetration testing focuses on IAM misconfigurations, resource exposure, cross-service privilege escalation, and data exposure rather than traditional network-level exploitation. Key assessment areas: overly permissive IAM roles (PrivEsc via AssumeRole or managed policy attachment), public-facing storage (S3, Azure Blob, GCS), service-linked role abuse, metadata service SSRF (IMDSv1 in AWS, IMDS in Azure), and cross-account trust misconfigurations. Tools: ScoutSuite (multi-cloud), Prowler (AWS), Cloudsplaining (AWS IAM), ROADtools (Azure AD). Cloud pentest authorization requires written approval from the account owner -- cloud providers' acceptable use policies prohibit unauthorized testing.

Network infrastructure penetration testing

Network infrastructure testing covers external perimeter (internet-facing services, VPN endpoints, mail servers), internal network (post-assumed-breach lateral movement simulation), and wireless networks (802.11, Bluetooth). External perimeter testing is broadly authorized under standard ROE; internal assumed-breach testing requires network access provisioned at the ROE-specified entry point. Tools: nmap, Nessus, Metasploit, CrackMapExec, Impacket, BloodHound/SharpHound for Active Directory attack path analysis.

AI and LLM system penetration testing

AI penetration testing is an emerging methodology area with evolving standards. Primary assessment categories: prompt injection (both direct and indirect via tool outputs), model extraction (inferring training data or model parameters), training data poisoning (for ML pipelines with external data ingestion), output manipulation (causing models to generate harmful or misleading outputs), and agentic AI attack paths (LLM agents with tool access -- can the agent be manipulated into taking unauthorized actions via adversarial inputs). OWASP LLM Top 10 provides the coverage checklist. Test AI systems in isolated environments -- production AI systems with external API calls or database access represent the highest-risk test targets.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

A penetration testing methodology is not bureaucratic overhead -- it is the quality gate that separates consistently useful tests from inconsistent ones. The most common methodology failures are in pre-engagement (undefined scope, missing ROE, no success criteria) and reporting (findings without impact context, no attack narrative, no remediation prioritization). Fix those two phases first. The intermediate exploitation and post-exploitation phases will produce better results automatically when the test is well-scoped and the reporting standard is defined before testing begins. For organizations building an internal penetration testing program, PTES provides the framework and OWASP WSTG provides the web application test case library -- start there, then adapt the documentation standards and authorization workflows to your organization's legal and operational context.

Sources & references

Penetration Testing Execution Standard (PTES)
OWASP Web Security Testing Guide v4.2
NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
PTES Technical Guidelines

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

penetration testing methodology pentest framework PTES OWASP testing guide penetration testing scoping rules of engagement pentest report red team methodology offensive security enterprise pentest pentest phases penetration testing guide 2026

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Penetration Testing Methodology: Complete Framework for Enterprise Security Teams (2026)

Phase 1: Pre-Engagement and Scoping

Phase 2: Intelligence Gathering and Reconnaissance

Phase 3: Vulnerability Analysis

Phase 4: Exploitation

Phase 5: Post-Exploitation

Phase 6: Reporting Standards

Methodology Variations by Target Type

The bottom line

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway