Level: intermediate. You are assumed to be comfortable with a terminal, browser developer tools and basic Linux administration. This is about the method rather than the tricks: the order of operations, the decisions at each stage, and the documents produced. Starting from nothing? Read our beginner guide to a penetration testing career first.

A penetration testing methodology is the documented, repeatable sequence a tester follows on every engagement, so a second tester working from the same notes would reach the same conclusions. Testing that depends on whoever picked up the keyboard produces inconsistent coverage, and the client cannot tell whether a gap in the report means nothing was there or nobody looked.

What a Penetration Testing Methodology Actually Is

Three properties separate a real methodology from a tool list. It is documented, so the phases and their order are written down rather than remembered. It is repeatable, so the same class of system gets the same treatment whoever tests it. And it is evidence-producing, so every claim traces back to a recorded observation.

Several well-known methodologies describe this shape. The Penetration Testing Execution Standard and the Open Source Security Testing Methodology Manual lay out phases in similar order. NIST SP 800-115 formalises planning, discovery, attack and reporting as a process, and the OWASP Web Security Testing Guide does the same for applications. Adapt one rather than inventing your own on the day.

The five phases below are scoping and rules of engagement, reconnaissance, vulnerability analysis, exploitation and post-exploitation, then reporting and retest. They are not a waterfall: a weakness found in phase four often sends you back to phase three, and a surprising result in phase two can force the scope to change.

Phase 1: Scoping and the Rules of Engagement

Scoping is what makes an engagement lawful and useful at once, and this methodology phase constrains everything after it. NIST SP 800-115 puts planning ahead of technique for the same reason, and the OWASP Application Security Verification Standard gives vocabulary for stating how much assurance the client wants.

A workable rules of engagement document settles the following in writing, before a single packet is sent. If a row is blank, the engagement has not started.

Item	What it settles	Why it exists
Authorised parties	Who signed, who to contact	Consent, and a route to stop
Scope in and out	Domains, ranges, suppliers, production data	What may be touched, and what may not
Test types	External, internal, wireless, physical, social, load	Intrusive kinds need separate consent
Timing	Dates, hours, maintenance windows	Protects business hours and freezes
Data handling	What may be viewed, and deletion after	Privacy rules apply the moment you look
Stop conditions	Who may halt, and on what trigger	Someone must be able to stop you
Reporting	Channel, severity scale, retest timeline	Findings reach someone who can fix them

Three scoping mistakes cause most of the pain: agreeing a scope verbally, leaving suppliers out so your traffic lands on a payment gateway that never consented, and omitting the data handling rules.

Phase 2: Passive and Active Reconnaissance

Passive reconnaissance and open source intelligence

Passive collection touches nothing the client owns. You gather what is already published: DNS records, certificate transparency logs, WHOIS data, job advertisements that reveal technology choices, credentials leaked in earlier breaches, and public source code. The IANA service names and port numbers registry shows what a listening service implies.

The value is not the data but the hypotheses. A job ad naming an outdated framework tells you where to look first. A transparency entry for a forgotten staging host says the scope is incomplete.

Active discovery inside the scope boundary

Active reconnaissance sends traffic to in-scope systems and is the first step defenders can see. That is expected, because the rules of engagement cover it. Stay inside the agreed ranges, keep request rates low enough not to degrade production, and warn the monitoring team in advance.

The output is an inventory: which hosts answer, which ports are open, which versions are visible, and which did not respond. That last group is itself a finding, because a host that drops packets silently may be well firewalled or running something undocumented. This is where scanning and enumeration tooling does the heavy lifting, and where the Network Service Discovery technique in ATT&CK describes the same behaviour from the defender’s side.

Phase 3: Vulnerability Analysis

Now you have an inventory and a pile of candidates, and the work is triage. Raw scanner output is not analysis, it is a heap of possibilities, most of them irrelevant or misidentified. Analysis means deciding, for each: is it real, does it matter here, and is it reachable from a realistic threat position.

Public identifiers help you classify. A finding mapped to a published advisory, with a CVSS base score from the FIRST forum, gives you a shared language for priority. The National Vulnerability Database confirms whether the version you found is affected. Both are references, not decisions: a critical advisory on an isolated appliance holding no data is a different problem from the same one on an internet-facing database, and the impact statement carries as much weight as the number.

For applications, the PortSwigger Web Security Academy is the best free reference, because it explains the mechanism of each weakness class before the tool that finds it. OWASP API security guidance covers interfaces with no user interface at all.

Phase 4: Exploitation and Post-Exploitation

Exploitation answers one question: is this finding real, and how far does it go? The standard is the minimum demonstration that proves impact. Proving remote code execution does not require running commands; it requires showing the request that reached an interpreter and the response that came back. Destructive payloads and anything that alters data belong in a written agreement or not in the engagement at all.

Post-exploitation turns a bug into a business finding. If you have authenticated to one host, can you reach the rest of the segment? If you have read one table, is it the one holding personal data? The initial access tactic page in MITRE ATT&CK lets you express this as a chain rather than a single bug, and our guide to how an attack chain unfolds covers the defensive view.

Three rules hold throughout, and they are where a good methodology earns its keep. Capture the minimum evidence needed to prove impact, and no more. Never take data out of the environment: demonstrate access, describe what you saw, let the client retrieve it. Clean up after yourself, because artefacts you leave behind become an incident. Where a finding falls outside scope, record it rather than exploring it.

Phase 5: Reporting, Remediation and Retest

The report is the deliverable, and it is judged more heavily than testers expect. It needs two layers: a summary a director can read, and enough detail that the engineer who must fix the issue can reproduce the problem without asking you anything.

Each finding should carry a title naming the weakness and its location, the affected asset, reproducible steps, evidence, an impact statement in business terms, a remediation that names the specific change rather than saying “improve security”, and a reference. Write each finding as you confirm it, because notes reconstructed later are not accurate.

Remediation advice is where many reports fail. “Upgrade the software” is not advice if the client cannot patch without taking a revenue system offline. Give the interim control, the permanent fix, and what to verify afterwards. If the likely consequence is extortion, see ransomware and small business.

Retest closes the loop: the same weakness, asset and conditions, with a pass or fail result and a date. Without it the engagement holds no evidence that anything improved, which is why this phase belongs inside the methodology rather than being bolted on.

Severity Ratings and the Honest Limits

Two ratings are worth separating. A technical score such as CVSS describes a weakness in the abstract. A business risk rating describes the consequence here, given what the system holds and who can reach it. Report both, and never let the higher number win silently.

Two honest limits. No methodology produces a clean bill of health, only a statement of what was tested, how, and when. And testing is a sample rather than an audit, so absence of findings is weak evidence of absence of problems. A proper penetration testing methodology says where you looked, not that nothing else is there.

One boundary never bends. Every phase here applies only to systems the client owns or has explicitly authorised. Section 1 of the UK Computer Misuse Act 1990 and the Nigerian Cybercrimes (Prohibition, Prevention, Etc.) Act 2015 make unauthorised access an offence, and no methodology confers permission. This is not legal advice: an agreement signed by the wrong person is not authorisation.

Frequently Asked Questions

Which penetration testing methodology should I use?

Pick one matching the system class and write it into the rules of engagement. PTES and OSSTMM suit general infrastructure, the OWASP Web Security Testing Guide suits applications, and NIST SP 800-115 gives a process-level frame.

What are the phases of a penetration test?

Five, in the order used here: scoping and rules of engagement, reconnaissance, vulnerability analysis, exploitation and post-exploitation, then reporting and retest. The order is not rigid, but each phase should produce the same artefacts on every engagement.

Should a penetration test include denial of service testing?

Rarely, and never by default. Availability testing can take a production system offline, and the cost usually exceeds the assurance gained. Where clients want it, the methodology should scope it separately, schedule it out of hours, cap it, and set an abort threshold.

How long does a penetration test take?

It depends on scope, depth and team size. A focused external assessment of a small estate takes days; an internal network and application review takes weeks. A fixed date on a fixed scope is how quality gets sacrificed.

Key Takeaways

• A methodology is documented and repeatable, not a list of tools.
• Scoping comes first. No signed rules of engagement means no lawful work.
• Passive reconnaissance changes the plan; active discovery is where defenders see your traffic.
• Scanner output is not analysis. Triage to real, relevant and reachable first.
• Prove the minimum that demonstrates impact. Destruction is not validation.
• Write findings as you confirm them, remediate specifically, and retest for a pass or fail.

For the practical sequence on a home lab, follow network penetration testing step by step. To see which tools map to which phase, read our guide to the 15 tools beginners should learn.

Sources: NIST SP 800-115; OWASP Web Security Testing Guide; FIRST, CVSS; MITRE ATT&CK; PortSwigger Web Security Academy.