Phases of a Penetration Test

A penetration test is not a single undifferentiated action — it is a structured, sequenced engagement governed by methodology frameworks and rules of engagement that define what testers may do, when, and against which targets. The phases described here represent the operational architecture of a professional engagement, from initial authorization through final reporting. Understanding this structure is essential for organizations evaluating penetration testing providers and for practitioners benchmarking their methodologies against recognized standards.

Definition and scope

The phased structure of a penetration test formalizes the difference between authorized security assessment and unauthorized intrusion. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment defines penetration testing as security testing in which assessors mimic real-world attacks to identify methods for circumventing the security features of an application, system, or network. Authorization documentation — including a signed scope-of-work and rules of engagement — establishes the legal boundary separating engagement activity from conduct potentially subject to the Computer Fraud and Abuse Act (18 U.S.C. § 1030).

The scope of a phased engagement is defined along four primary axes: target type (network infrastructure, web application, mobile platform, physical controls, or human factors), test knowledge level (black-box, grey-box, or white-box), depth of authorized exploitation, and time constraints. These parameters are set during the pre-engagement phase and govern every subsequent phase of the test.

The Penetration Testing Execution Standard (PTES), a publicly available methodology reference, and the OWASP Testing Guide for application-layer work both segment penetration testing into discrete phases that align with the structure described below.

How it works

A professional penetration test proceeds through a defined sequence of phases. While naming conventions differ across frameworks, the operational logic is consistent across NIST SP 800-115, PTES, and similar standards.

The seven principal phases are:

1. Pre-engagement and authorization — Scope definition, rules of engagement, legal authorization, target asset inventory, and communication protocols are established. No technical activity begins before signed authorization is in place.

2. Reconnaissance (intelligence gathering) — Testers collect information about the target using passive techniques (open-source intelligence, DNS enumeration, public records) and, where authorized, active probing. OSINT sources such as WHOIS records, certificate transparency logs, and public code repositories are systematically queried.

3. Threat modeling and target analysis — Attack surface mapping identifies entry points, trust boundaries, and high-value targets. This phase translates reconnaissance data into a prioritized attack model aligned with the organization's threat profile.

4. Vulnerability identification — Automated scanning tools (such as those referenced in NIST's National Vulnerability Database) are used alongside manual analysis to enumerate weaknesses. This phase produces a candidate list of exploitable conditions rather than a final finding set.

5. Exploitation — Testers attempt to actively exploit identified vulnerabilities under the authorized rules of engagement. Exploitation may include privilege escalation, lateral movement, credential harvesting, or chaining of lower-severity findings to achieve higher-impact compromise. This distinguishes penetration testing from passive vulnerability assessment.

6. Post-exploitation and evidence collection — Following successful exploitation, testers assess the depth and persistence of access achievable by an adversary. This phase documents impact — what data, systems, or controls could be compromised — and preserves evidence for reporting.

7. Reporting — Findings are documented with proof-of-concept evidence, risk ratings (commonly using the Common Vulnerability Scoring System (CVSS) maintained by FIRST), remediation guidance, and an executive summary. Deliverables are defined in the pre-engagement agreement.

The distinction between phases 4 and 5 — identification versus exploitation — is the threshold separating a vulnerability scan from a penetration test, and is the basis on which frameworks such as PCI DSS v4.0, Requirement 11.4 mandate the latter for cardholder data environment testing.

Common scenarios

Phased penetration testing applies across regulated and non-regulated environments, with phase emphasis varying by engagement type:

External network penetration test — Reconnaissance and exploitation phases focus on internet-facing infrastructure. Post-exploitation assesses whether external compromise can pivot to internal systems.

Internal network penetration test — Pre-engagement typically involves assumed-breach starting conditions (a foothold is granted rather than earned), compressing reconnaissance and expanding post-exploitation phases to assess lateral movement and domain compromise depth.

Web application penetration test — Threat modeling and vulnerability identification phases follow the OWASP Testing Guide v4.2 methodology, covering injection flaws, authentication weaknesses, access control failures, and business logic errors across all 11 OWASP testing categories.

Red team engagement — All phases are executed at full operational depth with stealth constraints. The engagement tests detection and response capability, not just the presence of vulnerabilities. Rules of engagement are more permissive and engagements typically run 30 to 90 days rather than the 1 to 2 weeks typical of scoped penetration tests.

Organizations subject to HIPAA Security Rule (45 CFR § 164.306) or FedRAMP Penetration Testing Guidance face specific reporting and scoping requirements that shape how phases are documented and what constitutes an acceptable deliverable.

Decision boundaries

The selection of phase scope, depth, and sequence depends on specific operational and compliance factors. The penetration testing provider network purpose and scope resource provides context for how provider specializations map to engagement types.

Black-box vs. white-box phase weighting — Black-box engagements allocate significantly more time to reconnaissance and threat modeling phases, as testers begin with no internal knowledge. White-box engagements compress these phases and expand exploitation and post-exploitation depth, producing more complete coverage per unit of time. Grey-box — where testers receive partial information such as network diagrams or user credentials — represents the most common production configuration.

Compliance-driven vs. risk-driven scoping — Compliance mandates (PCI DSS, FedRAMP, HIPAA) define minimum phase requirements and reporting formats. Risk-driven engagements, conducted outside compliance mandates, allow organizations to customize phase depth based on asset criticality rather than regulatory checkbox requirements.

Retesting as a discrete phase — Many frameworks and the how to use this penetration testing resource reference treat remediation retesting as a formal eighth phase. After identified vulnerabilities are patched, a targeted re-execution of the exploitation phase confirms that findings have been resolved — a requirement explicit in PCI DSS v4.0 Requirement 11.4.2.

Automated vs. manual phase execution — Vulnerability identification (phase 4) may be partially automated; exploitation (phase 5) and post-exploitation (phase 6) require human-driven judgment. Engagements relying solely on automated tooling do not satisfy the manual exploitation requirement under NIST SP 800-115 or PCI DSS definitions of penetration testing.