The Phases of a Penetration Test

Every published penetration testing methodology describes the same arc. The Penetration Testing Execution Standard names seven phases; NIST SP 800-115 compresses them to four; the OWASP Web Security Testing Guide covers the same ground organised by what is being tested rather than when.

The names differ. The work does not. What follows is that arc, with what actually happens in each phase and roughly what share of the engagement it consumes.

1. Scoping and authorisation

Before any testing. What is in scope and what is explicitly out, which testing perspectives will be used, when testing may occur, who is told, and what happens if something breaks.

The output is a written authorisation — the document that separates a penetration test from an offence. It names the systems, the dates, and the signatory, and it should be held by both parties before work begins. Where third parties host anything in scope, their permission is separate and also needs to exist in writing.

This phase produces no findings and is the one most often rushed. Almost every dispute about a test resolves to something not agreed here. What to settle is covered in preparing for your first VAPT.

2. Reconnaissance

Gathering what can be learned without touching the target: domains and subdomains, address ranges, technology in use, published credentials, exposed code repositories, and what the organisation has disclosed about its own architecture in job advertisements and conference talks.

How much of this applies depends on the perspective. A black box external test leans on it heavily; an authenticated application test where you have handed over the specification needs comparatively little.

3. Mapping

Building a model of the target. For an application, that means walking every function, cataloguing every parameter, understanding the roles and what each is supposed to reach. For a network, identifying live hosts, open ports, services and versions.

This phase determines the quality of everything after it. A tester who has not understood how your application works cannot tell an authorisation flaw from intended behaviour, and will either miss it or report normal function as a defect. If a tester asks a lot of questions in the first few days, that is the phase working correctly.

4. Discovery

Identifying candidate weaknesses across the mapped surface. Automated tooling does real work here — it is fast, it is thorough on known issues, and it frees the tester's attention for the parts that need judgement. It is a stage of the process, not a substitute for it; the division of labour is set out in what a scanner finds, and what it cannot.

The manual half of this phase is where authorisation testing, business logic analysis and anything requiring an understanding of context takes place.

5. Exploitation

Confirming which candidates are real by exploiting them. This is what separates a penetration test from a vulnerability assessment: a scanner reports that a flaw appears to be present, a tester demonstrates that it is.

The purpose is verification and impact, not damage. A tester proving database access retrieves a row that demonstrates it, not the table. Destructive techniques, denial of service and anything affecting availability are normally excluded unless specifically agreed, and that exclusion belongs in the scope document from phase one.

This is also where chains appear — three findings that are individually moderate and jointly critical, because one supplies what the next requires. Chaining is a manual activity by definition.

6. Post-exploitation

Establishing what a confirmed flaw actually reaches. Having gained a foothold, what data is accessible? Can privileges be raised? Can other systems be reached from here? Would access survive a reboot?

This is the phase that converts "an attacker could run commands on this host" into "an attacker could reach the customer database from this host", which is the sentence that determines the severity and, usually, whether anything gets fixed quickly.

7. Reporting

Typically a fifth to a quarter of the total engagement, and a legitimate share — the report is the deliverable. Findings written up with reproduction steps and evidence, severities assigned and contextualised, remediation guidance made specific, and the whole thing reviewed by someone other than the person who wrote it.

What the document should contain, and the specific thing to check in each section, is in what is actually inside a VAPT report.

8. Retest

After you have fixed things, verifying that they are fixed. Frequently omitted from proposals and frequently assumed by buyers, which is a bad combination.

Settle three points before signing: whether retesting is included or billed separately, how long the window stays open, and whether it produces its own dated document. That last one is what an auditor will ask for.

How the time divides

As a rough shape for a typical application engagement: scoping and reconnaissance a small fraction, mapping and discovery around a third, exploitation and post-exploitation around a third, reporting the remainder.

The useful thing about that shape is what it implies. Roughly half the engagement produces no findings at all — it is spent understanding the target and writing up the result. A proposal priced as though the entire period is spent finding vulnerabilities has either omitted the rest or intends to skip it.

Judging a methodology in a proposal

Nearly every proposal contains a phase diagram, and they all look similar. Four questions separate the ones with substance behind them:

• Is a published standard named specifically? PTES, NIST SP 800-115, OWASP WSTG, OWASP MASTG, OSSTMM. "Industry best practice" is not a methodology.
• Does the phase breakdown allocate real time to mapping and reporting? If the plan is five days of testing and the report appears the same evening, one of those two was not done.
• Is retest addressed explicitly, with a window and a deliverable?
• Does the methodology change with the target? The same arc applies to a web application, an API and an internal network, but the mapping and discovery phases look completely different. A proposal that describes them identically has been copied forward.

Applying these side by side is the substance of comparing two empanelled vendors.