The Penetration Testing Process, Step by Step
- A penetration test has seven stages, and only two of them involve attacking anything.
- Scoping is where most of the value is won or lost - a scope trimmed to fit a budget decides in advance what will not be found.
- The retest is the stage teams skip and the only one that proves a fix worked.
- Continuous testing compresses this cycle from weeks to hours, triggered by a deploy rather than a date.
A penetration test runs in seven stages: scoping, reconnaissance, mapping, vulnerability analysis, exploitation, reporting, and retest. Only exploitation resembles what people picture when they hear the word, and it is rarely the stage that determines how useful the test turns out to be.
What follows is the process as the buyer experiences it, with a note at each stage about where things commonly go wrong.
The seven stages
- Scoping. Agreeing what is in and out: which applications, which environments, which user roles, whether production is included, and what the tester is allowed to do if they gain access. This is the most consequential stage and it happens before anyone tests anything.
- Reconnaissance. Gathering what is publicly knowable - subdomains, exposed services, technology fingerprints, leaked credentials, staff names useful for social engineering if that is in scope.
- Mapping. Walking the application to build an inventory: every endpoint, parameter, role, and workflow. Coverage is decided here. Anything not mapped will not be tested, and forgotten endpoints are a recurring source of real incidents.
- Vulnerability analysis. Working through the map looking for weaknesses: injection points, authorisation gaps, session handling, misconfigurations, business logic that can be driven out of order.
- Exploitation. Confirming which of those weaknesses actually work, and how far they reach. A finding that has been exploited is a fact; a finding that has only been observed is a hypothesis.
- Reporting. Writing up what was found, what it means, how it was reproduced, and what to do about it. A good report is reproducible by your own engineers without asking the tester anything.
- Retest. Re-running the specific attacks after the fixes ship. This is the stage that gets dropped when a project runs late, and it is the only one that proves the work is done.
Where the value is actually decided
Stage one. Almost every disappointing pentest is a scoping failure rather than a testing failure.
The mechanism is simple: a traditional test is priced in human hours, so scope gets trimmed until the number fits the budget. That trimming is a decision about what will not be examined, made before anyone has looked at the application. The finding you most needed was frequently in the part that got cut. What that number typically looks like is covered in how much a penetration test costs.
The second common failure is testing a sanitised staging environment that differs from production in exactly the ways that matter - different auth provider, different data, missing integrations.
How long each stage takes
| Stage | Traditional engagement | Continuous testing |
|---|---|---|
| Scoping | Days to weeks, often contract-bound | Once, at onboarding |
| Recon and mapping | 1 to 3 days | Minutes, re-run every time |
| Analysis and exploitation | 1 to 2 weeks | Hours |
| Reporting | Several days | On completion |
| Retest | Weeks later, sometimes never | Next run, automatically |
The stages do not change when testing becomes continuous. What changes is that the cycle restarts on every deploy instead of every quarter, so a flaw introduced on Tuesday is not waiting until the next fiscal window.
What you should ask for
Three things make a report usable rather than decorative. Reproduction steps your own engineers can follow without the tester present. A clear separation between what was proven and what was merely suspected. And a retest, agreed in the contract rather than hoped for.
If you want to see what that shape looks like in practice, our services page sets out what each engagement includes, and our published research shows the reporting standard we hold ourselves to.
Frequently asked questions
What are the stages of a penetration test?
Scoping, reconnaissance, mapping, vulnerability analysis, exploitation, reporting, and retest. Only exploitation involves attacking anything; scoping usually determines how useful the whole exercise turns out to be.
How long does a penetration test take?
A traditional engagement typically runs one to three weeks of testing plus several days of reporting, with scoping and scheduling adding more before it starts. Continuous automated testing compresses the same stages into hours and re-runs them on every deploy.
What is a pentest retest and do I need one?
A retest re-runs the specific attacks that succeeded, after your fixes ship, to confirm they actually closed the hole. It is the stage most often dropped when a project runs late, and the only one that proves remediation worked. Agree it in the contract.
Should a penetration test run against production or staging?
Staging is safer but only useful if it genuinely mirrors production. Differences in authentication, data, and integrations are exactly where flaws hide, so a sanitised staging environment can produce a clean report for an application that is not clean.