Skip to content
Lesson 2 of 8

Pentest Methodology

8 min read

Why Methodology Matters

A pentest without methodology is just a set of random tests. Methodology gives you a repeatable, measurable, and defensible process that guarantees full coverage and consistent results. When you follow a recognized framework, you can explain to your client exactly what you did, why, and how, which increases trust and the quality of the deliverable.

Methodology also protects you. If you document each phase and each decision, you can demonstrate that you acted professionally and within scope. In case something goes wrong — a service goes down, a piece of data is exposed — your methodical record is the evidence that you followed a responsible process.

In addition, consistency allows you to compare assessments over time. If the client repeats the test each year with the same methodology, they can measure their security progress objectively.

Ethical framing: methodology also documents that you operated within the authorized scope and the rules of engagement.

The Classic Phases

Although names vary by standard, almost every pentest follows the same logical phases. The first is reconnaissance, where you gather information about the target with no (or minimal) direct interaction. It is followed by scanning and enumeration, where you identify live hosts, open ports, services, and versions.

Next comes vulnerability analysis, where you correlate what you discovered with known flaws and misconfigurations. Then exploitation, where you attempt to leverage those vulnerabilities in a controlled way to demonstrate real impact. After gaining access, post-exploitation assesses how far an attacker could go: privilege escalation, persistence, and lateral movement, always within scope.

Finally, reporting consolidates everything into a professional document with findings, evidence, severity, and remediation recommendations. This last phase is usually the one that delivers the most value to the client, because it turns the technical effort into concrete improvements.

Pre-engagement: The Work Before the Work

Before the technical phase there is a critical pre-engagement stage. Here the scope is defined, authorizations are signed, the rules of engagement are established, and objectives are agreed. The modality is also determined — black box, grey box, or white box — and emergency contacts are exchanged.

This stage includes setting realistic expectations. A pentest has limited time; it is not an infinite exhaustive audit. Agreeing on what is prioritized, what is considered out of bounds, and how critical findings will be handled in real time avoids friction later. For example, if you find an actively exploitable critical vulnerability, do you wait for the final report or notify immediately? That is decided here.

A well-done pre-engagement saves hours of confusion and protects both the pentester and the client. It is the foundation on which the rest of the process rests.

The PTES Standard in Detail

The PTES (Penetration Testing Execution Standard) is one of the most widely used frameworks in the industry. It defines seven phases worth developing one by one, because each answers a different question of the engagement.

  1. Pre-engagement interactions. Scope, rules of engagement, time windows, contacts, and written authorization are agreed. Without this phase there is no legal pentest: it is what turns a test into authorized work.
  2. Intelligence gathering. Information about the target is collected (OSINT, footprinting, enumeration) to understand the real attack surface before touching anything. The better the reconnaissance, the more accurate everything else.
  3. Threat modeling. Valuable assets and plausible adversaries are identified, and vectors are prioritized by business impact. Here you stop "testing everything" and start testing what matters.
  4. Vulnerability analysis. What was enumerated is correlated with vulnerabilities and weak configurations, validating manually to rule out scanner false positives.
  5. Exploitation. Real impact is demonstrated by exploiting in a controlled, reversible way, avoiding denial of service unless the scope explicitly authorizes it.
  6. Post-exploitation. The value of the access is assessed: what data it reaches, whether there is privilege escalation or lateral movement, and how long an attacker would go unnoticed.
  7. Reporting. Everything is translated into language the client can act on: prioritized findings, reproducible evidence, and concrete remediation.

PTES is not a rigid recipe but a structured guide. Its value lies in offering a common language and a level of technical detail that guides the pentester through each stage, and in modeling threats relevant to the client's business instead of firing off tools without judgment.

Other Standards and When to Choose Them

No framework is universal; choosing well is part of methodology.

  • OSSTMM (Open Source Security Testing Methodology Manual) brings a measurable, scientific approach. It defines metrics like the RAV (Risk Assessment Value) to quantify the attack surface, and separates operational controls from vectors. It fits when you need numeric, comparable, auditable results rather than a narrative.
  • NIST SP 800-115 is the U.S. government's technical guide to security testing. It is lighter than PTES and very useful as an official reference in compliance-driven environments; it structures the work into planning, discovery, attack, and reporting.
  • OWASP WSTG (Web Security Testing Guide) is the reference for web applications: it offers detailed per-category checklists to test systematically without improvising.
  • OWASP Top 10 lists the most critical risk categories — injection, broken authentication, broken access control, insecure configurations — and serves as a shared risk-communication framework with developers. For APIs, the OWASP API Security Top 10 covers risks specific to modern interfaces.

In practice they combine: PTES for the engagement flow, WSTG for web detail, and OSSTMM or NIST when the client requests metrics or formal compliance.

OWASP and Web Application Testing

When the target is a web application, the WSTG and the OWASP Top 10 guide coverage. The WSTG offers detailed checklists to test each risk category systematically, so you don't rely on memory or luck.

Tools like Burp Suite and OWASP ZAP are central in this phase: they act as a proxy between your browser and the application, allowing you to intercept, analyze, and manipulate requests in a controlled way. Combined with the OWASP guide, they ensure you cover the most relevant web vectors without improvising.

MITRE ATT&CK and the Cyber Kill Chain

Beyond process frameworks, the modern pentester uses threat modeling frameworks to think like the adversary.

MITRE ATT&CK is a knowledge base of real attacker behaviors, organized into tactics (the why — the goal, such as Initial Access, Privilege Escalation, Lateral Movement, Exfiltration) and techniques (the how — the concrete method, each with an identifier like T1078). Mapping your findings to ATT&CK techniques gives the client a standard language to understand risk and to verify whether their defenses detect that technique.

The Cyber Kill Chain (from Lockheed Martin) models an attack as a sequence of stages — reconnaissance, weaponization, delivery, exploitation, installation, command & control, and actions on objectives. It is more linear than ATT&CK and useful for communicating at what point in the chain a defense could cut the attack.

The pentester uses them in the threat modeling phase: instead of testing at random, you choose vectors a real adversary would use against that business, and then, in the report, you express each finding in terms of the tactic and technique it enables.

Mini-scenario: Applying the Methodology

Imagine an authorized, in-scope engagement against an internal application. During enumeration you discover that an admin panel accepts default credentials that were never changed. Instead of noting "weak login," you apply the methodology:

  • Phase: the finding surfaces in vulnerability analysis and is validated (without causing harm) in exploitation.
  • ATT&CK mapping: it corresponds to Valid Accounts (T1078), under the Initial Access / Privilege Escalation tactic.
  • Kill Chain: it enables the exploitation stage and, potentially, actions on objectives if those credentials grant access to sensitive data.
  • Business impact: you document what an attacker would reach with that access, respecting scope and without exfiltrating real data.
  • Remediation: rotate credentials, force a change on first login, and enable MFA.

That same finding, expressed with phase, technique, and kill chain, is far more actionable than a loose line in a checklist.

Engagement Structure and Continuous Documentation

A solid methodology requires documenting while you work, not afterward. Every command executed, every finding, every screenshot, and every decision should be recorded in real time. An orderly folder from day zero makes the report almost write itself. An illustrative layout, not an attack:

# Base engagement structure (organization only, nothing offensive)
mkdir -p engagement/{recon,scans,loot,report,notes}

# Record context and authorization alongside the evidence
echo "Client: ACME | Scope: 10.0.0.0/24 | Authorized: 2026-07-01" > engagement/notes/scope.txt

# Timestamped activity journal (traceability)
echo "$(date -u +%FT%TZ) - started service enumeration" >> engagement/notes/activity.log

Tools like CherryTree, Obsidian, or dedicated pentesting platforms help organize notes, evidence, and timeline. Tagging each finding with its host, service, severity, and proof of concept from the start makes the report almost write itself. The discipline of documenting is what separates a professional pentester from a talented amateur.

Closing Checklist

Before considering a phase — or the whole engagement — finished, verify that coverage and documentation are up to date:

  • [ ] Every PTES phase has associated notes, commands, and evidence.
  • [ ] Every finding is tagged with host, service, severity, and proof of concept.
  • [ ] Relevant findings are mapped to an ATT&CK tactic and technique.
  • [ ] No action went out of scope or violated the rules of engagement.
  • [ ] Critical findings were communicated as agreed in the pre-engagement.
  • [ ] The timeline (activity log) makes it possible to reproduce what was done and when.
  • [ ] The deliverable includes business impact and concrete remediation, not just the technical finding.