Penetration Testing Methodology: 7 Phases and 6 Standards

Last updated: August 2026. Written by Josh Hutcheson, OnlineCourseing editor. Every standard named below was loaded and date-checked before publication — one of the six turned out to be abandoned, and its former home now sells legal forms. See our review methodology.

QUICK VERDICT

A penetration testing methodology is the part of the job that does not change between engagements. The tools change constantly — the sequence does not. It is also the thing that separates a professional assessment from an expensive scan: a methodology is what lets you say a system was tested completely rather than tested until something interesting turned up.

This guide covers the seven phases in the order they actually run, then does something the competing guides do not: it checks the publication status of every standard it names. That check produced the most useful finding on this page, and it is not a flattering one for the field.

What a penetration testing methodology is

A penetration testing methodology is a documented, repeatable sequence of phases that governs how a security assessment is scoped, executed, evidenced and reported. It defines what must happen before testing begins, in what order the technical work proceeds, and what the deliverable has to contain. It is a process standard, not a tool list.

Two things follow from that. First, the methodology is what makes a test defensible — if a client or an auditor asks why a particular system was not examined, “it was out of scope, agreed in writing at pre-engagement” is an answer and “we ran out of time” is not. Second, it is what makes results comparable between two tests a year apart, which is the entire point of retesting.

The seven phases

This sequence comes from the Penetration Testing Execution Standard, and it is the shape almost every commercial engagement follows regardless of which document the firm formally cites.

1. Pre-engagement

The paperwork phase, and the one amateurs skip. You agree the scope in writing: which systems, which IP ranges and domains, which techniques are permitted, the testing window, and who to call when something breaks. You agree the rules of engagement — whether social engineering is in scope, whether denial of service is permitted (almost always not), whether testing happens against production or a staging environment.

You also establish the authorisation itself. Without a signed document naming the systems and the window, the technical work in every phase below is a criminal offence rather than a service. This is not a formality to be cleared quickly; it is the phase that makes the other six lawful.

2. Reconnaissance and intelligence gathering

Building a picture of the target before touching it. Passive reconnaissance uses sources that never contact the target: DNS records, certificate transparency logs, WHOIS data, public code repositories, job listings that name the internal technology stack, and employee details useful for later social engineering. Active reconnaissance does contact it — port scanning, service banner grabbing, directory enumeration.

The output is an inventory of the attack surface: hosts, open ports, running services and versions, subdomains, technologies and people. Almost every finding later in the test traces back to something catalogued here, which is why an under-invested recon phase is the most common reason a test comes back thin.

3. Threat modelling

Turning the inventory into priorities. You identify what is actually worth attacking — where the valuable data sits, which systems would cause the most damage if compromised, which components are exposed to the least-trusted networks — and you model who would realistically attack it and how.

This phase is what stops a test from being an undirected sweep. A payment system reachable from the internet and a printer on an internal VLAN both have vulnerabilities; only one of them is worth the engagement’s remaining hours.

4. Vulnerability analysis

Identifying the weaknesses in the prioritised targets. Automated scanners do the broad pass — known CVEs, missing patches, weak configurations — and manual analysis does the part scanners cannot: business logic flaws, chained weaknesses that are individually harmless, and access-control gaps that require understanding what the application is supposed to do.

The critical discipline here is validation. A scanner reports what a version banner implies, not what is true. Every candidate finding is a hypothesis until the next phase confirms it, and a report full of unvalidated scanner output is the single clearest sign of a test that was not really performed.

5. Exploitation

Proving the vulnerability is real by using it. The purpose is not damage; it is evidence. Successfully obtaining a shell, reading a record you should not be able to read, or authenticating as another user turns “this version is reportedly vulnerable” into “we did this, at this time, and here is the proof.”

Exploitation is bounded by the rules of engagement agreed in phase one. Restraint is part of the craft — demonstrating access to a database is the finding; extracting the database is usually a breach of scope.

6. Post-exploitation

Determining what the access is actually worth. From an initial foothold: what data is reachable, which credentials can be recovered, which other systems trust this one, can privileges be escalated, and can access be maintained across a reboot.

This is where a test becomes genuinely valuable to a client. “A low-privilege web shell on a DMZ host” is a medium-severity finding on its own; “a low-privilege web shell that yields domain administrator in two steps” is the one that changes budgets. Post-exploitation is also the phase most often cut when an engagement runs short, which is why scoping realistic time for it in phase one matters.

7. Reporting

The deliverable, and the only part of the work most of the client will ever see. A usable report carries an executive summary written for people who will not read the technical body, and per-finding entries with a severity rating, the business impact in plain language, reproduction steps precise enough for a developer to follow, the evidence captured during exploitation, and a specific remediation.

Severity should be justified rather than asserted — a documented rating system such as CVSS makes the number arguable in a productive way. And a good report distinguishes what was tested and found secure from what was never tested at all, because a reader will otherwise assume silence means safety.

Learn this methodology properly →

The published standards, and how current each one really is

Most articles on this topic present five or six methodologies as equally live options. They are not. We loaded each one on 30 August 2026 and checked its publication date. Here is what came back.

WHY THIS MATTERS MORE THAN IT SOUNDS

Which standard to actually use

The practical answer is that you use two at once: one for the shape of the engagement and one for the test cases inside it.

• Any commercial engagement: PTES for the phase structure and the report outline. It is frozen, it is still the clearest description of the process, and clients recognise it.
• A web application: the OWASP Web Security Testing Guide for the actual checks. It is maintained, and it is organised as test cases you can work through and evidence.
• A mobile application: the OWASP MASVS for what to verify and the MASTG for how — see our mobile app security testing guide and the iOS-specific workflow.
• A US federal or federally-adjacent system: NIST SP 800-115, because the requirement will name it regardless of its age.
• A cardholder data environment: the PCI Security Standards Council publishes its own penetration testing guidance, and the requirement is contractual — read the current document from the council rather than a summary of it.

The methodology is the same; the target type changes what you do inside it

The seven phases hold across every engagement type. What changes is the content of phases two through six — the reconnaissance sources, the vulnerability classes worth hunting, and what exploitation even means. Most firms scope an engagement by target type first, then apply the phases.

• Network penetration testing — internal and external infrastructure: exposed services, patch levels, authentication, segmentation, and lateral movement once inside. See our network penetration testing guide.
• Web application testing — injection, authentication and session handling, access control, business logic. The OWASP WSTG is the reference here, and the web application tooling is distinct.
• Mobile application testing — local storage, network interception, platform controls and anti-tampering, verified against the OWASP MASVS. Covered in our mobile app security testing guide.
• Wireless testing — encryption, rogue access points and client-side attacks, which changed shape with WPA3. See WiFi penetration testing.
• Social engineering — phishing, pretexting and physical access. Requires explicit written permission of its own, and often a separate legal review, because it targets people rather than systems.
• Cloud testing — identity and access policy, storage exposure, and workload configuration. Note that the major cloud providers publish their own rules about what customers may test on shared infrastructure; read those before scoping, not after.

One consequence worth planning for: a test scoped as “our infrastructure” will almost always turn out to span several of these, and the phases have to be run per target type rather than once across the whole estate. That is a scoping conversation for phase one, not a discovery to make in week two.

Black box, grey box and white box

Orthogonal to the methodology is how much you are told before you start, and it changes what the test can realistically prove.

Grey box wins most of the time for a simple reason: the discovery work a black box test spends its first days on is work the client could have handed over for free, and hours spent rediscovering the network are hours not spent testing it.

Scoping and rules of engagement

Most engagements that go badly go badly here, not during the technical work. A scope document that actually protects both sides names each of these explicitly:

1. The targets, by identifier. IP ranges, domains, application URLs, API endpoints. “The company’s infrastructure” is not a scope.
2. Third-party systems, and their exclusion. Authorisation from your client does not extend to their payment processor, their cloud provider or their SaaS vendors. Those need separate permission or explicit exclusion.
3. Permitted techniques. Social engineering, physical access, denial of service and password attacks against production accounts each need a separate yes or no.
4. The testing window and escalation path. A named person reachable during testing, and an agreed procedure for when something breaks or a live compromise is discovered.
5. Data handling. What happens to anything sensitive you encounter, how evidence is stored, and when it is destroyed.

The legal position

Every technique in this methodology is lawful with written authorisation covering the specific systems, and a criminal matter without it. In the United States that is the Computer Fraud and Abuse Act; in the United Kingdom the Computer Misuse Act 1990; most jurisdictions have a close equivalent. The technical act is identical either way. Authorisation is the entire difference, which is why pre-engagement is phase one rather than paperwork to be caught up on later.

If you want to practise the full sequence without any of that exposure, use a deliberately vulnerable environment built for it rather than a live target.

Learning to run this end to end

Reading the phases takes ten minutes; executing them under time pressure, with a client waiting and a report due, is a different skill. The part that takes longest to develop is not exploitation — it is scoping accurately, judging severity defensibly, and writing findings a development team can act on without a follow-up call.

We rank and review the training options: the best penetration testing courses covers the hands-on end and the certifications employers recognise, while ethical hacking courses and cyber security courses are the better entry points if you are earlier in the journey.

For the tooling that sits inside each phase, see our guides to penetration testing tools, web application testing tools, Kali Linux tools and the network penetration testing checklist.

Compare pentesting courses and certifications →

Browse cyber security courses →

Frequently asked questions

What are the seven phases of a penetration test?

Pre-engagement, reconnaissance and intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation, and reporting. The sequence comes from the Penetration Testing Execution Standard (PTES) and is the shape most commercial engagements follow regardless of which document a firm formally cites.

Is PTES still maintained?

No. The Penetration Testing Execution Standard wiki reads ‘This page was last edited on 16 August 2014’, which the site’s own API confirms, and the domain does not support HTTPS at all. That does not make it useless — the seven-phase engagement structure it describes has not changed. But it cannot tell you how to test modern targets, so pair it with the OWASP guides for actual test cases.

What is the difference between a penetration testing methodology and a standard?

A methodology is the sequence of phases you follow; a standard is a published document that defines one. In practice most teams combine two: a process standard such as PTES for the shape of the engagement, and a technical standard such as the OWASP Web Security Testing Guide or the Mobile Application Security Testing Guide for the specific checks performed inside it.

Which penetration testing standard should I use?

Use two. PTES for the engagement structure and report outline, plus a technical guide matched to the target: OWASP WSTG for web applications, OWASP MASVS and MASTG for mobile, NIST SP 800-115 where a US federal requirement names it, and the PCI Security Standards Council’s own guidance for cardholder data environments. OWASP’s guides are the only ones in that list under active development.

Is ISSAF still a valid framework?

No. The Information Systems Security Assessment Framework is abandoned, and the OISSG domain that hosted it now redirects to a website selling legal PDF forms. Plenty of methodology articles still list it as a live option, which is a good indication those articles have not been rechecked.

How old is NIST SP 800-115?

It was published in September 2008, superseding SP 800-42. Despite its age it remains NIST’s current technical guide to information security testing and assessment, and it is still named in federal and federally-adjacent requirements — so it is old but not obsolete, which is an unusual combination worth knowing before you dismiss it.

What is the difference between black box, grey box and white box testing?

It is how much the tester is told beforehand. Black box means nothing beyond the target identifier, simulating an external attacker. White box means full access including source code, simulating an insider. Grey box sits between — typically credentials and some architecture notes — and is the usual commercial default because it delivers the best coverage per paid hour.

Do I need written permission to run a penetration test?

Yes, always, and it needs to name the specific systems and the testing window. Without it the same actions fall under the Computer Fraud and Abuse Act in the US, the Computer Misuse Act 1990 in the UK, or the local equivalent. Note also that permission from your client does not extend to their third-party providers — those need separate authorisation or explicit exclusion from scope.

Related reading: network penetration testing · penetration testing tools · web application pentesting tools · mobile app security testing tools · Kali Linux tools · best penetration testing courses

Related guides

For the tools that execute this methodology on a Windows host, see pentest tools for Windows. The network-specific walkthrough lives in network penetration testing. The vocabulary these phases rely on is defined in our glossary of hacking terms. The categories of adversary a test is emulating are set out in types of hackers.