The phases of a penetration test, start to finish

A penetration test can look like a black box from the outside: you hand over a target, time passes, a report comes back. Inside, though, every serious engagement follows a recognizable arc, and the same arc is written into the standards. Knowing it does two things for you. It tells you what you are paying for at each stage, and it tells you exactly where a cheap engagement quietly skips a step.

The two most cited methodologies, NIST's SP 800-115 and the Penetration Testing Execution Standard, describe the same shape with slightly different labels. Here it is in plain terms.

1. Pre-engagement and scoping

Before anyone touches the target, scope is defined: what is in bounds, what is explicitly out, which accounts the testers get, the testing window, and the rules of engagement for when something breaks or a critical finding surfaces. This phase looks like paperwork and is actually where the value of the whole test is decided. A vague scope produces a vague test.

2. Reconnaissance and intelligence gathering

The testers map the target: subdomains, endpoints, parameters, technologies, exposed services, anything that expands the known attack surface. In a black-box test this phase eats a large share of the budget, which is one reason granting more access pays off, it shortcuts the guesswork and leaves more time for the parts that matter.

3. Threat modeling and analysis

With the surface mapped, the testers reason about where the real risk lives: which assets are valuable, which entry points are weak, which weaknesses are worth pursuing. This is the first place human or machine judgment separates a real test from a tool run. A scanner does not prioritize; it lists.

4. Exploitation

Now the testers actually attempt the weaknesses they identified, confirming which are real by exploiting them under controlled, authorized conditions. This is the phase that justifies the name. A finding that was never exploited is a hypothesis, and a report full of hypotheses is a scan with a nicer cover.

5. Post-exploitation and chaining

A single low-severity issue is often a doorway. The most valuable findings come from chaining: information disclosure feeding a targeted injection, a weak account reaching an admin function, an SSRF reaching cloud credentials. This is where a good test demonstrates the difference between a theoretical weakness and a real path to your data.

The vulnerability that gets you breached is rarely the scariest one on the list. It is two unremarkable ones that nobody connected.

6. Reporting

Each proven finding is written up with its severity, its evidence, its business impact, and a specific fix. A good report serves three readers at once: the engineer who fixes it, the leader who prioritizes it, and the auditor who needs it. We cover how to read one in how to read a penetration test report.

7. Remediation and retest

The engagement is not finished when the report lands. You fix the serious findings, and the testers re-run against the same paths to confirm the fixes held and did not open something new. A test without a retest tells you what was wrong, not whether it is fixed.

The early phases are exhaustive and mechanical; the value concentrates in exploitation, chaining, and judgment. That split is exactly how Uvy runs: the mechanical work happens at machine scale, the exploitable findings are proven with a real exploit, and the fixes are verified shut. See how it works.