Phases of a Penetration Test

A penetration test is not a single action but a structured sequence of discrete phases, each with defined objectives, methods, and deliverables. The phased model governs how authorized testers move from initial scoping through active exploitation to final reporting, ensuring engagements remain controlled, repeatable, and legally defensible. Understanding how these phases interconnect is essential for procurement officers, compliance teams, and security professionals evaluating or commissioning penetration testing services.

Definition and scope

The phase-based structure of a penetration test formalizes the adversarial simulation process into a reproducible methodology. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment identifies four broad technical assessment phases — planning, discovery, attack, and reporting — which align closely with widely adopted industry frameworks including the Penetration Testing Execution Standard (PTES) and the OWASP Testing Guide.

The phased model serves a dual purpose: it structures the work for the testing team and provides the commissioning organization with audit-ready documentation demonstrating that testing was conducted within authorized boundaries. This distinction carries direct legal weight under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), which makes unauthorized computer access a federal offense regardless of intent. Authorization documentation, scope agreements, and phase-by-phase records form the evidentiary record that separates a legitimate test from prosecutable intrusion.

Regulatory frameworks that mandate or reference penetration testing — including PCI DSS v4.0 Requirement 11.4, HIPAA Security Rule guidance published by the Department of Health and Human Services, and FedRAMP assessment requirements — all presuppose phase-structured engagements. Compliance documentation produced without a clear phase record is unlikely to satisfy auditor expectations.

How it works

A standard penetration test proceeds through six primary phases. While terminology varies across frameworks, the operational logic is consistent across NIST SP 800-115, PTES, and OWASP guidance.

Pre-engagement and scoping — The tester and client define the target environment, testing boundaries, rules of engagement, and authorization agreements. This phase produces the written authorization that gives the engagement legal standing. Rules of engagement specify permitted techniques, restricted systems, and escalation procedures.
Reconnaissance — Testers collect information about the target using passive and active methods. Passive reconnaissance — querying public DNS records, WHOIS databases, and open-source intelligence sources — does not interact directly with target systems. Active reconnaissance involves direct probing, such as port scanning with tools like Nmap. PTES classifies reconnaissance as either open-source intelligence gathering or active target enumeration.
Scanning and enumeration — The tester maps live hosts, open ports, running services, and software versions. This phase transitions from information collection to systematic attack surface analysis, identifying specific technologies that may carry known vulnerabilities documented in databases such as the NIST National Vulnerability Database (NVD).
Exploitation — The tester actively attempts to compromise identified vulnerabilities. Exploitation is what distinguishes a penetration test from a vulnerability assessment: the tester must demonstrate that a flaw is exploitable, not merely present. Frameworks such as the Metasploit Framework are commonly used to validate exploitability against specific CVEs. Chained exploitation — using one compromised system as a pivot point to reach adjacent targets — is a defining feature of this phase.
Post-exploitation and lateral movement — Following initial access, the tester evaluates what an attacker could accomplish from the compromised position. This includes privilege escalation, lateral movement across network segments, and data exfiltration simulation. Post-exploitation techniques reveal the true business impact of a vulnerability, moving beyond technical severity ratings to operational consequence.
Reporting — The tester documents findings, evidence, exploitation chains, and remediation recommendations. A well-structured penetration testing report classifies findings by severity (typically using the Common Vulnerability Scoring System, CVSS, maintained by FIRST.org), maps findings to regulatory requirements, and provides technically reproducible evidence for each confirmed vulnerability.

Common scenarios

The six-phase model applies across engagement types, but the emphasis and depth of specific phases shift depending on scope and target environment.

External network tests weight reconnaissance and scanning heavily, since the tester begins with no internal access. The exploitation phase focuses on perimeter controls, exposed services, and authentication bypass. These engagements directly address PCI DSS Requirement 11.4.1, which mandates external penetration testing at least once every 12 months and after significant infrastructure changes.

Web application tests following the OWASP Testing Guide compress the reconnaissance phase and expand scanning and exploitation to cover injection flaws, broken authentication, and server-side request forgery. The Burp Suite proxy is the dominant tool for this phase sequence in web-focused engagements.

Red team operations extend the standard six-phase model across weeks or months, layering in social engineering and physical penetration testing alongside technical exploitation. The post-exploitation phase in red team engagements is significantly deeper than in point-in-time network tests, with persistent access and long-dwell simulation reflecting realistic advanced persistent threat (APT) behavior.

Cloud penetration testing applies the same phase sequence but requires modified tooling and authorization processes, since exploitation against cloud-hosted infrastructure must operate within provider-specific terms of service — AWS, Azure, and Google Cloud each publish penetration testing policies that define permissible testing activities.

Decision boundaries

The phase model is consistent, but three structural variables determine how phases are weighted and executed across different engagement types.

Knowledge state at engagement start — Black-box testing begins reconnaissance from zero, making that phase the longest and most resource-intensive. White-box testing provides full documentation and credentials at the start, compressing reconnaissance and expanding exploitation depth. Gray-box testing — the most common commercial configuration — provides partial knowledge, typically network diagrams or application credentials, balancing breadth and depth.

Phase depth versus breadth tradeoff — A time-boxed engagement (the industry norm for cost-managed penetration testing) forces a tradeoff: expanding reconnaissance depth reduces exploitation time and vice versa. Organizations with compliance-driven requirements — PCI DSS, FedRAMP, SOC 2 — typically specify minimum phase coverage in their procurement documentation.

Automated versus manual execution — Phases 3 and 4 (scanning and exploitation) can be partially automated using commercial scanners and exploit frameworks. Automated versus manual penetration testing represents a substantive difference in deliverable quality: automated scans enumerate known CVEs but cannot perform chained exploitation, session hijacking, or business logic abuse. Phases 2 (reconnaissance) and 5 (post-exploitation) remain predominantly manual across all engagement types because they require contextual human judgment that automated tools cannot replicate.

References

📜 2 regulatory citations referenced · 🔍 Monitored by ANA Regulatory Watch · View update log

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator