Why are there different pentest phases/stages/methodologies? Which one should be used? Why don't we come out with standard one?


Wikipedia / Cybrary.it

  1. Reconnaissance
  2. Scanning
  3. Gaining Access
  4. Maintaining Access
  5. Covering Tracks


  1. Reconnaissance
  2. Scanning
  3. Gaining Access
  4. Maintaining Access
  5. Clearing Tracks
  6. Reporting

EC-Council, Imperva

  1. Planning and reconnaissance
  2. Scanning
  3. Gaining Access
  4. Maintaining Access
  5. Analysis

PTES @ pentest-standard.org

  1. Pre-engagement Interactions
  2. Intelligence Gathering
  3. Threat Modeling
  4. Vulnerability Analysis
  5. Exploitation
  6. Post Exploitation
  7. Reporting


  1. Intelligence Gathering
  2. Threat Modeling
  3. Vulnerability Analysis
  4. Exploitation
  5. Post-Exploitation
  6. Reporting


  1. Pre-engagement
  2. Information Gathering
  3. Threat Modeling
  4. Vulnerability Analysis
  5. Exploitation
  6. Post-Exploitation
  7. Reporting


  1. Intelligence Gathering
  2. Threat Modeling
  3. Vulnerability Analysis
  4. Exploitation
  5. Reporting

Core Security

  1. Planning and Preparation
  2. Discovery
  3. Penetration Attempt and Exploitation
  4. Analysis and Reporting
  5. Clean Up and Remediation
  6. Retest
  • 7
    There are different ones for different goals and different outcomes and how far they go pre- and post- testing. Can you also see that many of the steps are the same, just using alternate words?
    – schroeder
    May 23, 2020 at 12:15
  • 6
    I don't think any of these phases are meant to be instructive, but descriptive. Some seem to concentrate merely on attacking, while other include more interaction with the client (planning before and reporting afterwards). Threat modeling might also be more on that side. May 23, 2020 at 12:22
  • 2
    To why no one comes out with a "standard": xkcd.com/927 May 24, 2020 at 6:07
  • Re "Why don't we come out with a standard one?" - who do you mean by "we", exactly?
    – Carmeister
    May 24, 2020 at 15:40

3 Answers 3


Let's take a critical look at the collection you have:

  1. The Wiki list is from a Cybrary article. That's basically one author's opinion, and I'm not sure you should include it in a comparison with more general advice. "Maintaining Access" and "Covering Tracks" are odd steps to include, unless you are doing specific testing on the detection capabilities of the target. "Maintaining Access" is often prohibited in pentest engagements because you do not want to introduce backdoors in a system (that could be forgotten).
  2. The Impervia list differs from the rest by including "Maintaining Access" (imitating APTs). This, also, is a highly specific test that should not be included in a general framework of steps.

Taking the common steps together, and eliminating the highly specific steps, you end up with:

  1. [Pre-engagement Interactions]
  2. (Planning and ) Reconnaissance / Intelligence Gathering
  3. Scanning
    1. [Threat Modeling]
    2. [Vulnerability Analysis]
  4. Gaining Access/Exploitation
  5. Post Exploitation
  6. Analysis / Reporting
  7. [Clean Up and Remediation]
  8. [Retest]

The [] items are overhead and managerial items and not about the pentest itself.

Threat modelling and vulnerability analysis steps are explicit steps that enable the common step of "Gaining Access/Exploitation". These two steps do not need to be mentioned, yet for those who have not performed a pentest, it can be helpful to highlight these steps.

So, it's not that the collection of steps you found are very different from each other or that some sort of common, standardised list is required. It all depends on the goal and context of the pentest, and why you need a list of steps to begin with.


Similar to the cyber kill-chain where there are various iterations of it from various organizations. The most prominent one being Lockheed Martin's take on the kill-chain.

There is simply no 'governing body' that publishes frameworks and handles the standardization for these references. (Cyber Kill-chains, Pentesting Phases/Cycles)

Some examples of known Cyber Security Frameworks & Standards,

  • NIST

You brought up a handful iterations of a Pentest 'cycle' and that's great! Based on that we could see in a way how similar and how different it can be from organizations to organizations.

It's in the hands of other companies to,

  • Set the focus to which standards, models & cycles to adhere to
  • It's up to them to determine what is best for their own company
  • Important for them to stay relevant and update their approach/models if need be.

You have to understand that approaching Pentesting can be very 'by-the-book' and this book is in the hands of the practitioners out there. My book, my methods can be different than others!


Short answer: the pentest phases are meant as guidelines. You don't have to apply them strictly. Each pentesting exercise is unique and it is expected that you will tailor the attack to the target. But it is good to have a coherent approach (and a checklist).

  • In reality the different models you presented (interesting comparison BTW) are all quite similar but sometimes use different words to describe the same process
  • So it seems that there is some kind of standard since everybody agrees on the overall process
  • Of course you can deviate from a standard, there may be good reasons
  • There is some overlap between stages
  • Some vendors have included Pre-engagement Interactions in their roadmap, others seem to have decided it was outside the scope of the roadmap because it was not a 'technical' task perhaps. But it goes without saying that you must coordinate with the client, secure permissions and define the scope of the test. The models shown are not complete operating instructions but general guidelines that you have to adapt to your circumstances.

There is no one-size-fits-all, auditing ICS or embedded equipment is different than auditing webservers or mobile devices so the methodology and steps followed will vary.

In fact, if you are a professional pentester/pentesting company I would actually expect you to come up with your own model. Which obviously should be fairly similar to what already exists. Having a consistent roadmap is important.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .