From scope to evidence. The whole roadmap, one stage at a time.
Most penetration tests fail quietly in the gap between noticing something and proving it. This is the roadmap we run — seven stages that turn a signed scope into findings you can hand an engineer, with everything that doesn't reproduce held back instead of padding the report.
The short version: a good test is a pipeline, and the value is concentrated at the end of it. Anyone can run a scanner and notice things. The work that earns trust is what happens after a signal — the controlled test, the clean-session reproduction, the evidence that travels with the claim. Skip the back half and you have a list of maybes. Here is each stage, what it is for, and the failure that waits if you rush it.
The roadmap at a glance
Seven stages. The first three decide what you test and what you expect; the last four decide whether anyone should believe the result. Teams tend to over-invest in the left and abandon the right — which is exactly backwards.
1 · Scope and rules of engagement
Everything downstream inherits the quality of this stage. Scope is not a sentence in an email — it is the list of hosts, applications, APIs and agent surfaces that are in bounds, the identities you will be given, the methods that are allowed, and the hard limits (no destructive payloads, a stop signal, a rate ceiling). A wildcard like *.example.com authorises subdomains; a bare apex does not. Write it down, both sides sign it, and nothing runs until ownership is confirmed. The failure here is silent: an under-specified scope means the tester either stays too narrow and misses the real surface, or drifts wide and tests something that was never theirs to touch.
2 · Reconnaissance that reaches the live surface
Recon decides what the rest of the test even sees. The goal is not "a long list of hosts" — it is the live, reachable, in-scope surface, found fast enough that the vulnerability work still has time to run. Passive sources first (certificate transparency, passive DNS, public indexes) to pre-find hosts for free; short liveness timeouts; no retrying a host that refuses or doesn't resolve. A run that spends its budget knocking on dead hosts never reaches the interesting part. The quiet win of good recon is the shadow asset — the forgotten staging box, the un-decommissioned API — that nobody put on the scope because nobody remembered it existed.
3 · Hypotheses, not payloads
This is the stage that separates a test from a scan. Before firing anything, state what the application is supposed to enforce, as a checkable rule: "an invoice is visible only to its owner," "an order total can never be negative," "a coupon can be applied once." Each rule is a hypothesis you then try to break. Phrasing the work this way is what pulls a test into business logic and authorization — the classes a signature-based scanner structurally cannot reach, because they are about your rules, not a known-bad string. If you cannot write the rule down, you cannot test it, and you certainly cannot prove it is broken.
Why this order matters. Scanners invert it — they fire payloads first and reason later. That is why they are fast and shallow: they find the classes that look the same on every site (reflected XSS, known CVEs) and miss the ones that depend on what your product promises. Hypothesis-first is slower and it is where the expensive bugs are.
4 · Controlled testing
A test is a deliberate experiment against one hypothesis, run as the identities you supplied, with a control to compare against. The control is the part people skip and the part that makes the result legible: to prove a broken access control, you show the owner's request succeeding and a second identity's identical request being wrongly allowed. One response on its own is ambiguous; the pair is not. Everything is bounded — benign canaries instead of live payloads, narrow budgets, a circuit-breaker that stops on your signal or ours. The output of this stage is still only a candidate. It is not yet a finding, and treating it as one is the single most common mistake in the industry.
5 · Reproduction from a clean session
This is the pivot of the whole roadmap. Most false positives survive because nobody tried to make the issue disappear. A single success can be luck, leftover state from an earlier step, or an artefact of the testing context — all of which vanish on a second look. Reproducing from a clean session (fresh context, no history, conditions reset) removes those explanations. If the issue reappears from a clean start, it is a property of the application, not of the run. If it doesn't, it was never a finding and it is held back. A good pipeline runs an adversarial critic here whose job is to challenge thin evidence, so the bar to promotion is hostile rather than hopeful. We go deeper on this in how a candidate becomes a finding.
6 · Evidence that travels with the claim
A finding is only worth what you can do with it. Each confirmed one should carry the exact request, the control it was compared against, the replays that reproduced it, the affected identity or tenant, and a direction for the fix — captured so the evidence cannot drift from the claim. We hold it in a hash-chained, append-only ledger: each entry is linked to the one before it, so a report cannot be quietly edited after the fact and a number on the cover always traces to the proof behind it. This is what makes a "Critical: 3" line meaningful — you can open each of the three and watch it break. See a full worked finding for exactly what that package looks like.
7 · Report, then retest
The report is not the finish line; the fix is. A finding that can't be re-tested is a story, so each one ships with enough to reproduce it and, after your team ships a patch, the same experiment runs again against the fixed version to confirm it actually closed — and didn't just move. Two habits make the report trustworthy for an auditor as much as an engineer: separate "attempted" from "verified" so a headline count is never inflated by things that were tried but not proven, and map each finding to the controls it touches (OWASP, SOC 2, ISO 27001, PCI DSS) so compliance evidence falls out of the work instead of becoming a second project.
FAQ
How long should a penetration test take?
It depends on the surface, not the calendar. One web app with a couple of roles is days of focused work; an app plus its API and an agent surface is longer. What matters is that every stage actually happens — a run that never reaches the business-logic stage has not really tested the application.
What is the difference between a candidate and a finding?
A candidate is a signal — a tool hit, a suspicious response, a model's assertion. A finding is a candidate that reproduced from a clean session and whose impact is backed by evidence. Treating the two as the same is why so many reports are long and so few are trusted.
Do I need to give a tester real user accounts?
For anything behind a login, yes — one account per role and per tenant. The highest-impact bugs (broken access control, cross-tenant access, privilege escalation) can only be found by replaying a real request as a different identity. Without accounts, the authorization layer goes untested.
Want to see the back half of this pipeline in practice? Read how a candidate becomes a finding, open a worked report, or book a demo.