Written by the Infronest Security Research Team — certified security professionals (CEH, OSCP, GPEN, ISO 27001 Lead Auditor) with 10+ years of hands-on delivery. Reviewed against PTES, NIST SP 800-115 and the OWASP Testing Guide v4.2.
Security & Compliance
The 8 Phases of Penetration Testing: A Step-by-Step Guide
A project-management walkthrough of every phase of a penetration test, aligned to PTES — what happens in each phase, what you need to provide, how long it takes, and the deliverable you should receive.
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 phases of penetration testing are pre-engagement and scoping, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting — the seven phases defined by the Penetration Testing Execution Standard (PTES). Most commercial engagements add an eighth stage, remediation and retest, 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.
- 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, 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.
Phases 2–3
Intelligence gathering and threat modelling
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.
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. 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: fast confirmation of asset ownership (within hours, not days), written approval to test newly discovered in-scope assets, and an honest answer to "which system going down or leaking would hurt most?".
- Typical duration: 1–3 days for reconnaissance, half a day to one day for threat modelling.
- Deliverable: an attack-surface inventory listing every discovered host, service and technology, plus a prioritised test plan naming the attack paths that will be pursued.
- 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 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. 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.
Phases 5–6
Exploitation and post-exploitation
Exploitation proves that a weakness is real. 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.
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: an on-call technical contact reachable during every test window, agreement on out-of-hours testing for production systems, and a decision on whether proof of domain-administrator or equivalent access is required or explicitly forbidden.
- Typical duration: 3–8 days combined for a mid-size scope, depending on how many attack paths reach a foothold.
- Deliverable: a proof-of-concept evidence pack per finding, same-day notification of Critical issues, and a clean-up and artefact log signed off at the end of testing.
- Ask before you start: what happens if an exploit causes an outage, who decides to stop, and how that decision is communicated at 2am.
Phases 7–8
Reporting, remediation and retest
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.
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.
- 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.
Sources and standards referenced
- PTES — Penetration Testing Execution Standard, seven-phase methodology
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
- OWASP Testing Guide v4.2
- 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?
- PTES defines seven phases: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. Most commercial engagements treat remediation and retest as an eighth phase, since an unverified fix is not a closed risk. 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.
- 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.
- 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.