The Penetration Testing Process: Every Phase, Step by Step

Every credible penetration test follows the same arc, whether it targets a web application, a network, or a cloud account. The names shift between methodologies, but the work moves through seven phases: scoping, reconnaissance, discovery, exploitation, post-exploitation, reporting, and retest. Knowing the arc tells you what a good provider is doing at each point, what they need from you, and where the value actually comes from.

This guide walks the process end to end. It follows the structure of the Penetration Testing Execution Standard and the way we run engagements, described in full on our methodology page.

Phase 1: Scoping and rules of engagement

Nothing starts until scope is written down. Scoping decides what is tested, what is off limits, when testing may run, and what happens if something breaks. It is where the fixed price is set, because the price follows the scope, not the hour.

A scoping conversation settles a short list of questions. Which assets are in: which applications, which IP ranges, which cloud accounts, which people. Whether the test is black box, grey box, or white box, meaning how much the testers are told up front. Whether it is external, internal, or both. What the testers must avoid, such as production payment flows or a fragile legacy host. And who to call if a finding is serious enough to report before the engagement ends.

The output is a signed rules-of-engagement document. It protects both sides: it authorizes the testing in writing, which is what separates a penetration test from a crime, and it records the boundaries everyone agreed to. Our guide on how to scope your first penetration test covers this phase in depth.

Phase 2: Reconnaissance

With authorization in hand, testing opens with information gathering. Reconnaissance builds a picture of the target before anyone touches it in anger.

Passive reconnaissance uses sources that never send a packet to your systems: public DNS records, certificate transparency logs, breached-credential databases, code repositories, job postings that reveal your technology stack, and the general footprint an attacker would assemble from the open internet. Active reconnaissance begins the light-touch interaction, resolving hosts and mapping the shape of the environment.

For an external network test this phase often finds the first real problem before a single exploit runs: a forgotten subdomain, a staging server exposed to the internet, or credentials from an old breach that still work.

Phase 3: Discovery and vulnerability analysis

Discovery turns the map into a list of possibilities. Testers enumerate services, versions, endpoints, and behaviors, then analyze them for weaknesses worth pursuing.

This is where automated tools earn their place. Scanners and enumeration tooling cover ground quickly, cataloguing open ports, software versions, and known vulnerability signatures. But the scanner output is the starting point, not the finding. A senior tester reads it the way an investigator reads a tip: most leads go nowhere, a few are worth everything, and the tool cannot tell which is which. The difference between a scan and a test lives in this phase, and it is the subject of automated versus manual penetration testing.

Phase 4: Exploitation

Exploitation is the phase people picture when they hear penetration testing. A tester takes a candidate weakness and proves it, safely, by actually using it: extracting data through an injection flaw, reaching another user’s records through a broken authorization check, or gaining a foothold through an exposed service.

Proof matters here for a practical reason. A validated finding is one you can trust and prioritize; an unvalidated scanner alert is one you have to argue about. Every finding in a real report carries the request, the response, and the steps to reproduce it, so your engineers can see the flaw rather than take it on faith. Exploitation is also where restraint shows: a professional proves impact without causing an outage, and never runs denial-of-service techniques unless they are explicitly in scope.

Phase 5: Post-exploitation and lateral movement

A single foothold is rarely the whole story. Post-exploitation asks what that foothold is worth: what data it reaches, what privileges it can escalate to, and how far it can travel.

On an internal network test this is the heart of the engagement. From one compromised workstation, testers pursue the path most real breaches take, harvesting credentials, moving between hosts, and working through Active Directory toward Domain Admin and the systems that matter. The point is not to plant a flag. It is to show the blast radius, so leadership can see that a phishing click on a laptop in accounting reaches the financial systems three hops away. The same logic drives a red team assessment, where the objective is defined up front and detection is part of the test.

Phase 6: Reporting

The report is the deliverable, and it is where a good engagement separates itself from a mediocre one. A report that lists findings without context wastes the test. A report written for the three audiences that read it earns its cost.

Leadership needs an executive summary: what was tested, how exposed the organization is, and what to do first, in plain language. Engineers need technical findings with reproduction steps, evidence, and specific remediation guidance. Auditors and customers need findings mapped to the framework they care about, whether that is the OWASP Top 10, PCI DSS, or SOC 2, and an attestation letter that proves an independent test happened without exposing the findings themselves. What a strong report contains, and the red flags of a weak one, is covered in what a penetration testing report should contain.

Phase 7: Remediation and retest

The test is not finished when the report lands. Findings get fixed, and the fixes get checked. A retest confirms that the serious issues are genuinely closed and that the fix did not open something new, which happens more often than teams expect.

Some providers charge for the retest or skip it entirely, which leaves you with a report full of open findings and no proof they were resolved. We include a retest with every penetration test, because a finding that is fixed but unverified is not evidence you can hand to an auditor or a customer. For teams that change constantly, continuous penetration testing folds the retest into an ongoing program rather than waiting a year.

How long the process takes

For most single-target engagements, scoping takes about a day, onboarding begins within 24 hours of a signed proposal, and the active phases run one to three weeks depending on size, with reporting close behind. A larger network or a multi-part application takes longer, and the timeline is set during scoping. The full breakdown is in how long a penetration test takes.

The process is the product

A penetration test is not a scan with a nicer cover page. It is a disciplined process that turns a map of your environment into a ranked, proven, fixable list of the ways it can be broken, and then confirms you closed them. When you evaluate a provider, ask them to walk you through these seven phases for your specific engagement. The ones who can are the ones worth hiring.

Ready to scope one? Tell us what to test and we will come back with a fixed price, or read how we run each phase on our methodology page.