Stages of Penetration Testing: From Planning and Recon to Exploitation, Reporting, and Retest

If you are still choosing the assessment format, start with types of penetration testing: black box, white box, API, web, and network. For product teams, also read why startups need early API audits.

People search for “stages of penetration testing” for two reasons. Either they are learning to become a pentester and want a clear workflow. Or they are a buyer and want to understand what happens between the contract and the final PDF.

Without stages, a pentest turns into “we poked some tools and wrote a report.” With stages, you get a managed process: clear scope, reproducible findings, priorities, and retest. Below is a practical map of penetration testing stages as they look in real web and API projects — not as abstract textbook theory.

Why pentesting needs stages

Stages are not decoration. They solve three problems:

• Risk control. The team knows what can and cannot be touched.
• Finding quality. Less scanner noise, more real attack paths.
• Business value. At the end you get a fix plan, not just a CVE dump.

Important: stages are not always perfectly linear. After exploitation you may return to recon; during reporting you may refine severity. But the process frame must exist. Otherwise the team loses focus and the client does not understand what they paid for.

The classic chain looks like this: planning → recon → scanning → analysis → exploitation → post-exploitation → reporting → remediation and retest. Let’s break each step down.

Stage 1. Planning and scope

This is the most underestimated stage. Many people want to “start breaking things” immediately. Without proper planning you either get dangerous chaos in production or a useless report that misses the real risks.

At this stage you define:

• targets: web, API, mobile, network, cloud;
• format: black / gray / white box;
• environments: staging, restricted production, test accounts;
• work window and stop rules;
• what is critical for the business;
• incident contacts;
• communication rules and NDA.

A good scope answers: which risk do we want to validate in the available time? Example: “Can a regular user access another user’s orders and payment data through the REST API?”

A bad scope sounds like: “Test everything possible.” That is not a scope. That is a wish that almost guarantees a blurry result.

From mentoring and audit work: for most SaaS products the best start is gray-box web + API with user/admin/partner roles. It gets you to BOLA/IDOR, XSS, and authorization flaws faster than a vague “pentest the whole company internet.”

Another practical planning detail is success criteria. Define in advance what “done” means: critical scenario coverage, role coverage, payment-flow checks, BOLA checks on key objects. Then at the end you can honestly say whether the scope was completed, instead of arguing after the fact.

Also define stop conditions early. Examples: heavy production load, bulk entity creation, unlimited brute force, any destructive actions. A good pentest is aggressive in thinking and disciplined in execution.

Stage 2. Reconnaissance

Recon is information gathering. It is usually split into passive and active.

Passive recon

No direct noisy interaction with the target: open sources, WHOIS, DNS history, public repos, docs, leaks, job posts, external subdomain data.

Active recon

Direct interaction: site mapping, endpoint discovery, JS bundle analysis, robots.txt, sitemap, API schemas, technology fingerprinting.

For web/API engagements, this stage is especially useful to:

• map roles and objects (user, order, invoice, organization);
• find hidden or legacy endpoints;
• understand where authorization is enforced;
• spot predictable IDs;
• see where UI blocks actions but API does not.

This is where attack hypotheses are born. Not “is there a CVE,” but “if I swap the object ID, do I get another user’s data?”

During recon it helps to keep a live attack map: roles → objects → endpoints → possible ownership breaks. That map later saves hours in analysis and exploitation. Without it, teams often jump between random bugs and lose focus on the main risk.

Stage 3. Scanning and enumeration

Tools help cover breadth quickly: ports, services, known signatures, basic misconfigurations, outdated components.

Key principle: a scanner is an assistant, not the pentest. It speeds things up. It does not replace thinking.

Typical work includes:

• network/service discovery (if network is in scope);
• web crawling and endpoint discovery;
• header and basic control checks;
• user, role, and parameter enumeration;
• interesting entry points: upload, search, password reset, admin API.

For API pentests, enumeration is critical: which methods exist, which fields are accepted, where bulk operations live, and how the access model actually behaves.

Stage 4. Vulnerability analysis

After collection, the team separates noise from signal. Not every scanner finding is a real risk. Not every missing header is critical.

Questions at this stage:

• does the issue exist, or is it a false positive?
• can it be exploited within scope?
• what is the business effect: data leak, account takeover, fraud, downtime?
• how easy is reproduction?
• does it need a chain of weaknesses?

This is where pentesting value really starts. Beginners often stop at “the scanner found a lot of red.” Experienced specialists build a short list of high-impact hypotheses and validate them manually.

For web/API, priorities usually look like this: broken access control / BOLA, auth bypass, XSS with real impact, mass assignment, sensitive data exposure, logic bugs in payments and roles.

Good analysis is always tied to business impact. “SQL injection on a data-free test stub” and “BOLA in the orders API with real PII” are different priorities. So this stage is not only about technical possibility — it is also about damage: money, data, access, reputation, compliance.

Stage 5. Exploitation

Exploitation means proving the issue in practice. Not “this might be IDOR,” but “here is the request, here is the response, here is another user’s data.”

What matters here:

• reproducible steps;
• minimum sufficient evidence;
• care: do not wipe production data or take the service down;
• context capture: role, token, object ID, timestamp.

Strong finding example: user A reads user B’s order via `GET /api/orders/{id}`, then changes status via `PATCH`. That is not theoretical risk — that is a damage scenario.

Weak “finding” example: missing X-Frame-Options with no demonstrated clickjacking on a critical flow. It can be mentioned, but should not be inflated to Critical.

A separate exploitation skill is stopping in time. The goal is not to break everything possible. The goal is to prove risk within the rules and gather material for the report.

Stage 6. Post-exploitation

If access is gained, the next question is: what else can an attacker do?

• privilege escalation;
• access to neighboring objects and tenants;
• reading secrets and tokens;
• movement toward admin panels or internal APIs;
• blast-radius assessment: one account or the whole platform.

Post-exploitation shows the difference between “a bug exists” and “a bug is dangerous for the business.” XSS in a test field and XSS that steals an admin session are different worlds.

In internal network pentests this stage often includes lateral movement. In product AppSec/API work it is usually about role, token, and data chains.

Stage 7. Reporting

The report is the product of the pentest for business and engineers. If the report is weak, even strong technical work loses value.

A solid report includes:

• executive summary without jargon;
• scope and limitations;
• findings with severity;
• reproduction steps;
• evidence;
• business impact;
• fix recommendations;
• remediation priorities.

The best reports work for two audiences. A CTO understands risk in five minutes. A developer can reproduce and start fixing in fifteen.

A bad report: 70 pages of scanner noise, everything marked Critical, no requests/responses, no clear “what to do tomorrow.”

Separately agree how sensitive evidence will be shared. Sometimes full tokens or real personal data should not go into the PDF. In that case use redaction, masking, and a secure channel for PoCs. That is part of a mature process, not bureaucracy.

Stage 8. Remediation and retest

This is the stage most often skipped in conversations — and that is a mistake. A pentest without remediation is almost useless.

After the report, the client team should:

• triage Critical/High;
• fix the issues;
• add regression checks;
• request retest on key findings.

Retest confirms the vulnerability is actually closed and did not reappear on a similar nearby endpoint. Without it, teams often “fix one IDOR” and leave the same pattern in the next API.

Practical advice: reserve time and budget for retest from day one. Otherwise the report sits in Confluence and returns half a year later in the next audit.

Common mistakes across pentest stages

1. Weak scope. “Test everything” with no priorities.
2. Scanner instead of thinking. Lots of PDF, few real scenarios.
3. No roles in gray box. Without user/admin it is hard to catch broken access control.
4. UI-only testing. The biggest holes are often in the API.
5. No evidence. “Possibly vulnerable” is not a finding.
6. No retest. Risk found on paper, not closed in reality.
7. Ignoring business context. A technical bug without damage context is poorly prioritized.

How the stages look in practice for web/API

A short real-world flow for a product:

1. Agree gray box: staging + roles + critical flows.
2. Map APIs and objects.
3. Run basic scans and manually review authorization.
4. Confirm BOLA on orders and XSS in profile.
5. Check whether a chain can reach admin actions.
6. Deliver a prioritized report with request examples.
7. After fixes, retest and close findings.

That is how a pentest becomes a security growth tool instead of a checkbox ritual.

What buyers should demand at each stage

• Planning: written scope, roles, environments, stop rules.
• Recon/scanning: a clear attack-surface picture, not just “tools are running.”
• Exploitation: reproducible PoCs for critical findings.
• Reporting: executive summary + technical details + fix priorities.
• Retest: confirmation that Critical/High issues are closed.

If a vendor cannot explain which stage they are in and which question they are answering, the process is already at risk. Stage transparency is a sign of a professional team.

A mini checklist before kickoff

If you are the buyer, run this short checklist before the engagement starts:

1. Do you have test accounts for at least two roles?
2. Is the list of critical business scenarios clear?
3. Is the environment agreed and safe to test against?
4. Who owns Critical findings on day one?
5. Is retest included in timeline and budget?

If two or more answers are “no,” fix the process gaps first. Otherwise even a strong technical team will deliver a report nobody can use quickly.

FAQ

How many stages should a pentest have?

Textbooks often list 5–7. In real projects it is useful to count 8, including remediation/retest. Without the last stage the cycle is incomplete.

Can you skip reconnaissance?

Almost never. Without recon you miss important surfaces and waste time on random checks.

How is exploitation different from scanning?

Scanning looks for signals. Exploitation proves the attack works and shows real impact.

Is post-exploitation always required?

Not always deep. But at least an assessment of “what happens after first access” is needed in almost every serious engagement.

What matters more: stages or tools?

Stages. Tools change every year. The process of thinking and proving risk stays.

Conclusion

The stages of penetration testing are the frame of a quality assessment: from clear scope to report and retest. If you are learning, master the full process — not only “how to run a scanner.” If you are a buyer, demand transparent stages, reproducible findings, and verification of fixes.

Practical takeaway for most digital products: the strongest cycle is planning → recon → API/web analysis → exploitation → report → retest, focused on authorization, BOLA/IDOR, XSS, and business logic.

Also read: types of penetration testing, why BOLA and XSS remain top risks, and a cybersecurity roadmap for beginners.

Similar articles

• Types of Penetration Testing
• OWASP Top 10:2025 — BOLA and XSS
• Startup product security and API audits