How many phases are there in penetration testing?

Eight in practice: the seven PTES phases — pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting — plus the remediation retest that closes the loop. [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) describes a similar sequence in four broader stages (planning, discovery, attack and reporting), so a provider using either model is on solid ground.

What is the PTES standard in penetration testing?

The [Penetration Testing Execution Standard (PTES)](http://www.pentest-standard.org/) is a community-maintained methodology that defines the seven phases of a penetration test, from pre-engagement interactions through reporting. It is the most widely referenced phase model in commercial testing and the structure this guide follows. Because PTES stops at reporting, mature engagements add a remediation retest as an eighth stage to verify fixes.

How long does the whole penetration testing process take?

For a mid-size scope, expect roughly 10 to 14 weeks from kick-off to a completed retest. Only about 7 to 14 days of that is hands-on testing; the rest is scoping and approvals at the front and remediation by your own teams at the back. Cloud-provider notification and third-party SaaS permissions are the most common cause of a delayed start date.

How much does a penetration test cost in India?

In India, a focused web application penetration test typically costs ₹1.5–4 lakh (USD 2,000–5,000). A combined network + web application VAPT for a mid-size environment runs ₹5–15 lakh (USD 6,000–18,000), and large multi-scope programmes covering cloud, API and mobile go beyond ₹25 lakh (USD 30,000+). US/EU-market engagements for comparable scope typically price two to three times higher. The final number depends on scope, asset count and whether a remediation retest is included.

What does the client need to provide before a penetration test starts?

A current asset inventory with IP ranges, domains and application URLs; working test accounts for every user role; network diagrams and any previous test reports; named technical and escalation contacts with out-of-hours numbers; and signed authorisation from someone entitled to grant it. Test the credentials yourself the day before the engagement begins — dead test accounts are the most frequent reason a testing day is wasted.

What is the difference between exploitation and post-exploitation?

Exploitation proves a vulnerability is genuinely exploitable, usually with a minimal, controlled proof of concept and captured evidence. Post-exploitation measures what that foothold is actually worth to an attacker: privilege escalation, credential harvesting, lateral movement and which data becomes reachable. Post-exploitation is what turns a technical finding into a business-impact statement your leadership can act on.

Is a retest included in the price of a penetration test?

It depends on the provider, so ask before signing. Quality providers include at least one retest cycle within scope, because billing separately creates a disincentive to validate fixes properly. If it is priced separately, add it to the original budget and schedule it two to six weeks after the report, once fixes are genuinely deployed.

Penetration Testing Process: The 8 Phases

A penetration test is a project, not a scan. The difference between an engagement that ends with vulnerabilities actually fixed and one that ends with a PDF nobody reads is almost always process — how the scope was agreed, how findings were evidenced, and whether anyone verified the fixes. This guide walks through each phase in the order it happens and, for every phase, sets out what the testers do, what you as the client have to provide, how long it typically takes and what you receive at the end. For budget context: IBM's Cost of a Data Breach Report 2025 puts the global average breach at USD 4.44 million, Gartner forecasts worldwide information security spending of USD 244.2 billion in 2026, and MarketsandMarkets projects the penetration testing market will reach USD 4.39 billion by 2031 at a 14.2 per cent CAGR.

Direct answer

What are the phases of penetration testing?

The penetration testing process has eight phases: the seven PTES phases plus the remediation retest that closes the loop. The Penetration Testing Execution Standard (PTES) defines pre-engagement and scoping, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. PTES itself stops at reporting; most commercial engagements add remediation and retest as the eighth stage, because a finding that is never verified as fixed has not reduced any risk.

The phases run in order but they are not strictly linear. A tester who compromises a host during exploitation will loop back to intelligence gathering against the internal network, and post-exploitation discoveries frequently reopen the threat model. What should never move is the boundary at either end: nothing is touched before the rules of engagement are signed, and nothing is considered closed before a retest confirms it.

The 8 phases of a penetration testing engagement

Scoping & rules of engagementTargets, test windows, legal authorisation, success criteria
ReconnaissancePassive and active information gathering on the agreed scope
Scanning & enumerationPort scans, service fingerprinting, attack-surface mapping
Vulnerability analysisValidate findings, discard false positives, rank candidates
ExploitationControlled attempts to prove which weaknesses are actually exploitable
Post-exploitationPivoting, privilege escalation, blast-radius assessment
ReportingEvidence, severity ratings, business impact, fix guidance
Remediation retestVerify every fix and close the loop with an updated report

Pre-engagement and scoping — agree targets, techniques, timing and written authorisation. 1–3 weeks of calendar time, mostly waiting on approvals.
Intelligence gathering — map the real attack surface: domains, IP ranges, exposed services, technologies, people. 1–3 days.
Threat modelling — decide which assets matter and which attacker profiles are realistic. Half a day to one day.
Vulnerability analysis — automated scanning plus manual verification against the modelled attack paths. 2–4 days.
Exploitation — prove exploitability in a controlled, evidenced way. 2–5 days.
Post-exploitation — establish real impact: privilege escalation, lateral movement, reachable data, then clean up. 1–3 days.
Reporting — findings with CVSS scores, evidence and remediation guidance, plus a review call. 3–5 days after testing ends.
Remediation and retest — your teams fix, the tester verifies. Typically 2–6 weeks later, 1–2 days of testing.

Phase 1

Pre-engagement and scoping

This phase decides whether the rest of the engagement is worth paying for. Scope is agreed asset by asset: which IP ranges, which domains and applications, which user roles, production or staging, and how much prior knowledge the testers are given (black box, grey box or white box). The single most common cause of a disappointing penetration test is a scope written from a stale asset list — the internet-facing box nobody remembered is exactly the one an attacker will find.

The output is a rules-of-engagement document: written authorisation from someone entitled to grant it, in-scope and out-of-scope systems, permitted and prohibited techniques (social engineering, denial-of-service and password spraying should each be an explicit yes or no), agreed test windows, named escalation contacts with out-of-hours phone numbers, and evidence-handling and data-retention terms. If you host on AWS, Azure or GCP, check the provider's testing policy before you commit to dates; for anything running on third-party SaaS you generally need the vendor's written permission, which is the step that most often delays a start date.

You provide: current asset inventory, IP ranges and domains, application URLs and environments, working test accounts for every user role, network diagrams, previous test reports, and named technical and escalation contacts.
Decisions you must make: test type and depth, external, internal or both, production versus staging, whether the SOC is told in advance, and whether destructive or social-engineering techniques are permitted.
Typical duration: 1–3 weeks of calendar time. The actual work is a few hours — the delay is legal review, cloud-provider notification and third-party permissions.
Deliverable: signed rules of engagement, a scope document, a test schedule and a fixed price or day-rate estimate.
Warning sign: a provider that issues a quote without a scoping call, or begins testing without a signed authorisation letter.

Compare the types of penetration testing before you scope →

Phases 2–3

Intelligence gathering and threat modelling

Phases 2 and 3 build the attacker's view of your organisation and decide where the testing hours go: reconnaissance maps the real attack surface, and threat modelling ranks it by what a breach would actually cost the business.

Phase 2: Intelligence gathering

Intelligence gathering, or reconnaissance, builds the picture an attacker would build. Passive work uses sources that never touch your systems: DNS records, certificate transparency logs, WHOIS data, public code repositories, job advertisements that name your internal stack, and credential dumps from past breaches. Active work then fingerprints what is actually listening — port scans, service and version identification, web crawling, virtual-host and directory discovery. In most engagements this phase surfaces at least one host, subdomain or admin interface the organisation did not know was internet-facing.

You provide: fast confirmation of asset ownership (within hours, not days) and written approval to test newly discovered in-scope assets.
Typical duration: 1–3 days.
Deliverable: an attack-surface inventory listing every discovered host, service and technology.
Value beyond the test: the asset list produced here is often more accurate than the organisation's own CMDB — reconcile the two rather than filing it.

Phase 3: Threat modelling

Threat modelling turns that inventory into a plan. The tester ranks assets by business value (payment data, customer PII, source code, the ERP) and maps realistic attacker profiles against them: the unauthenticated attacker on the internet, the compromised low-privilege employee, the contractor with VPN access, the supplier holding an API key. Frameworks such as MITRE ATT&CK help ground those profiles in techniques real adversaries use. Testing hours are then allocated to the paths a real attacker would prioritise. This is the phase that separates a penetration test from a scan, and it is the phase clients most often skip past — resist that, because half a day spent here changes where the following week is spent.

You provide: an honest answer to "which system going down or leaking would hurt most?".
Typical duration: half a day to one day.
Deliverable: a prioritised test plan naming the attack paths that will be pursued.

Phase 4

Vulnerability analysis

Vulnerability analysis identifies weaknesses in the prioritised targets and, critically, verifies them. Automated tooling does the volume work: network and host scanners, web proxies and template-based scanners match observed versions and behaviours against known issues. That matching genuinely needs machines — the CVE Program had published over 11,000 CVEs by March 2026 — but deciding which of those are reachable, exploitable and consequential in your specific environment is manual work.

Two things reliably go wrong here. First, false positives: a scanner that flags a backport-patched package on an enterprise Linux distribution will fill a report with noise unless a human verifies each item. Second, blind spots: broken access control, insecure direct object references, workflow and pricing-logic bypasses and multi-step authorisation flaws produce no scanner signature at all, and are found only by a tester who understands what the application is supposed to do — the OWASP Web Security Testing Guide exists precisely because these classes need structured manual test cases. For web targets, our web application penetration testing checklist lists the manual checks scanners miss. Expect a good tester to spend more time removing findings than adding them.

You provide: credentials that actually work for each role (test them the day before), a decision on whether tester IPs are allowlisted in the WAF and EDR or deliberately not, and a named contact who can restore a test environment if something breaks.
Also agree: whether the SOC suppresses alerts for the test window or treats the engagement as a live detection exercise — both are valid, but decide in advance.
Typical duration: 2–4 days for a mid-size scope.
Deliverable: a validated candidate-finding list with false positives already removed, plus immediate written notification of anything Critical rather than waiting for the report.

Vulnerability assessment vs penetration testing →

Phases 5–6

Exploitation and post-exploitation

Exploitation proves a weakness is real; post-exploitation measures what that proof is worth to an attacker. Together they are the phases that separate a penetration test from a vulnerability assessment, and the ones where discipline matters most.

Phase 5: Exploitation

Exploitation proves that a weakness is genuinely exploitable. The discipline is in restraint: extract one record rather than the database, place a benign marker file rather than a persistent implant, avoid payloads that can crash a production service, and capture evidence as you go — requests and responses, screenshots, command output and timestamps. Exploits carrying a genuine availability risk should be demonstrated only in a staging environment or with explicit written sign-off. Anything Critical goes to your escalation contact the same day, with a recommendation on whether to pause testing on that vector.

You provide: an on-call technical contact reachable during every test window, and agreement on out-of-hours testing for production systems.
Typical duration: 3–8 days combined with post-exploitation for a mid-size scope, depending on how many attack paths reach a foothold.
Deliverable: a proof-of-concept evidence pack per finding, plus same-day notification of Critical issues.
Ask before you start: what happens if an exploit causes an outage, who decides to stop, and how that decision is communicated at 2am.

Phase 6: Post-exploitation

Post-exploitation answers the question your board will ask: so what? The tester escalates privileges, harvests credentials and tokens, moves laterally and establishes what data and systems are reachable from the initial foothold. It ends with clean-up — removing created accounts, shells, scheduled tasks and uploaded files — and a written artefact log of every change made. Insist on that log. Your incident response team needs it to tell tester activity apart from a real intrusion, both during the test and when reviewing logs months later.

You provide: a decision on whether proof of domain-administrator or equivalent access is required or explicitly forbidden.
Deliverable: a clean-up and artefact log signed off at the end of testing.

Phases 7–8

Reporting, remediation and retest

The final two phases convert testing into reduced risk: the report tells you exactly what to fix and why it matters, and the retest proves the fixes actually landed.

Phase 7: Reporting

The report is the deliverable you are actually buying. A usable one contains an executive summary in business language with an overall risk rating; a methodology and coverage section stating what was tested, not only what was found; and, for each finding, a CVSS score, affected assets, reproduction steps, evidence, business impact and specific remediation guidance — "upgrade component X to version Y" rather than "apply vendor patches". Expect a draft within five working days of testing ending, then a review call where you are entitled to challenge severity ratings; ratings should move on evidence, such as a compensating control the tester could not see, not on discomfort.

Phase 8: Remediation and retest

Remediation and retest is the phase most often under-planned. Move every finding out of the PDF and into your ticketing system with an owner, a due date and a severity-based SLA, then group fixes by root cause — a dozen findings frequently trace back to one unpatched base image or one missing authorisation check. Schedule the retest when fixes are genuinely deployed, usually two to six weeks later, and require the retest report to state each finding as fixed, partially fixed or open. If retesting is billed separately, budget for it in the original business case rather than discovering the cost later.

The end-to-end timeline at a glance

Put together, a typical mid-size engagement looks like this from kick-off to attestation:

Weeks 1–3: scoping, legal and cloud-provider approvals, signed rules of engagement.
Week 4: intelligence gathering and threat modelling (2–4 days).
Weeks 4–5: vulnerability analysis, exploitation and post-exploitation (5–10 testing days for a mid-size scope).
Week 6: draft report, severity review call, final report issued.
Weeks 7–12: remediation by your teams, tracked as tickets with owners and due dates.
Weeks 12–13: retest, updated report and — if a customer or auditor needs one — a letter of attestation.
Total: roughly 10–14 weeks from kick-off to attestation for a typical mid-size engagement. Only about two of those weeks are testing; the rest is approvals and fixing.

Infronest

Conclusion

Infronest does not replace the tester. Exploitation and threat modelling are human work, and no platform changes that. What the Security and VAPT module does is run the phases around the testing: engagements with scope and schedule, CVSS-scored findings, evidence upload against each finding, peer review before a report leaves the team, audit-ready PDF report generation, and retest tracking so remediation is closed out rather than assumed. Because it shares one tenant-isolated workspace with the IT assets, patch management and helpdesk modules, your scope list can be drawn from the live asset inventory and each finding can become a ticket with an owner and a due date instead of a row in a spreadsheet.

Being straight about the limits: if you want crowdsourced bug bounty, continuous adversarial testing between engagements, or an in-house exploitation toolchain, a dedicated PTaaS or bug-bounty platform will serve you better. Infronest is built for internal security teams and service providers who run scheduled engagements and need the scoping, evidence, review and retest trail to hold up in front of an auditor or a customer. Start a 14-day free trial at infronest.com — no credit card required.

Explore the Security & VAPT module →

Sources and standards referenced

Every figure and methodology reference in this article comes from the following published standards and reports. We cite them so you can verify the claims rather than take them on trust.

PTES — Penetration Testing Execution Standard — the seven PTES phases this guide follows, extended with the remediation retest that closes the loop
NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
OWASP Testing Guide v4.2 (Web Security Testing Guide)
FIRST — Common Vulnerability Scoring System (CVSS)
MITRE ATT&CK — adversary tactics and techniques knowledge base
IBM Cost of a Data Breach Report 2025 — USD 4.44 million global average breach cost
Gartner — forecast worldwide information security spending of USD 244.2 billion in 2026
MarketsandMarkets — penetration testing market forecast of USD 4.39 billion by 2031, 14.2 per cent CAGR
CVE Program — over 11,000 CVEs published by March 2026

Frequently Asked Questions

How many phases are there in penetration testing?: Eight in practice: the seven PTES phases — pre-engagement, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting — plus the remediation retest that closes the loop. NIST SP 800-115 describes a similar sequence in four broader stages (planning, discovery, attack and reporting), so a provider using either model is on solid ground.
What is the PTES standard in penetration testing?: The Penetration Testing Execution Standard (PTES) is a community-maintained methodology that defines the seven phases of a penetration test, from pre-engagement interactions through reporting. It is the most widely referenced phase model in commercial testing and the structure this guide follows. Because PTES stops at reporting, mature engagements add a remediation retest as an eighth stage to verify fixes.
How long does the whole penetration testing process take?: For a mid-size scope, expect roughly 10 to 14 weeks from kick-off to a completed retest. Only about 7 to 14 days of that is hands-on testing; the rest is scoping and approvals at the front and remediation by your own teams at the back. Cloud-provider notification and third-party SaaS permissions are the most common cause of a delayed start date.
How much does a penetration test cost in India?: In India, a focused web application penetration test typically costs ₹1.5–4 lakh (USD 2,000–5,000). A combined network + web application VAPT for a mid-size environment runs ₹5–15 lakh (USD 6,000–18,000), and large multi-scope programmes covering cloud, API and mobile go beyond ₹25 lakh (USD 30,000+). US/EU-market engagements for comparable scope typically price two to three times higher. The final number depends on scope, asset count and whether a remediation retest is included.
What does the client need to provide before a penetration test starts?: A current asset inventory with IP ranges, domains and application URLs; working test accounts for every user role; network diagrams and any previous test reports; named technical and escalation contacts with out-of-hours numbers; and signed authorisation from someone entitled to grant it. Test the credentials yourself the day before the engagement begins — dead test accounts are the most frequent reason a testing day is wasted.
What is the difference between exploitation and post-exploitation?: Exploitation proves a vulnerability is genuinely exploitable, usually with a minimal, controlled proof of concept and captured evidence. Post-exploitation measures what that foothold is actually worth to an attacker: privilege escalation, credential harvesting, lateral movement and which data becomes reachable. Post-exploitation is what turns a technical finding into a business-impact statement your leadership can act on.
Is a retest included in the price of a penetration test?: It depends on the provider, so ask before signing. Quality providers include at least one retest cycle within scope, because billing separately creates a disincentive to validate fixes properly. If it is priced separately, add it to the original budget and schedule it two to six weeks after the report, once fixes are genuinely deployed.

About the Author