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.