Skip to content

Methodologies and Frameworks

This page is a map of the frameworks people talk about when they mean "professional, repeatable pentesting."
I do not treat them as gospel. They are tools for thinking, not a box to hide in. These are notes for future-me about what they are, why they matter, and how I usually fold them into my own approach.

Why bother with a methodology

Frameworks give a backbone to an engagement. They help me avoid blind spots and explain to others why I did things in a certain order. They are as much about communication and reproducibility as they are about coverage. That said, they are not a substitute for judgement. I use them to guide, not to dictate.

Core methodologies I care about

PTES (Penetration Testing Execution Standard)

The one people reference a lot. PTES breaks testing into seven phases: pre-engagement, intelligence, threat modeling, vulnerability analysis, exploitation, post-exploitation, and reporting. I like PTES for mapping an engagement end-to-end. It gives a readable flow without being too prescriptive.

NIST

More formal and broad. Not a pure pentest playbook, but great for assessments that need a rigorous structure, especially when clients expect compliance-aligned language. Useful when working with larger orgs or public sector types.

OWASP Testing Guide

Focused on web apps. Very practical and community driven. It contains concrete checks and examples for web-specific problems. When I work on web targets this is the quick reference I turn to for test ideas and validation steps.

MITRE ATT&CK

Not a process so much as a language of adversary behavior. ATT&CK is useful for thinking in terms of tactics and techniques and for building realistic scenarios. I use it when I want my tests to look a bit more like an actual adversary, or when mapping detections back to observable behavior.

How I pick an approach

I do not pick a single framework and stick to it by faith. I pick what fits the question and the audience.

  • Need broad, end-to-end engagement for a client who wants a report they can act on? Lean PTES with a NIST-friendly appendix.
  • Web app only? Start with OWASP, layer in PTES phases for structure.
  • Want to simulate an adversary and test detection? Use ATT&CK for scenarios and mapping.
  • Black box vs white box changes effort and where I focus my time. Access level informs the methods, not vice versa.

Most real engagements are hybrids. The best frameworks are the ones you bend until they fit the problem.

Personal methodology, in a sentence

Start with a known framework, test hypotheses fast, document everything so it is reproducible, and fold lessons back into the framework. Over time the framework becomes a living thing shaped by experience.

A few notes on that living aspect: - Keep a short canonical checklist for each phase so I do not forget low-effort, high-value checks.
- Keep a separate set of "creative prompts" to force divergent thinking when progress stalls.
- Maintain a small library of PoC patterns and escalation chains I have actually used.

How to evolve your own methodology

This is iterative work. A rough recipe that works for me, written as a thought exercise rather than a to-do list:

  • Learn the frameworks enough to translate between them. Know PTES phases, OWASP chapters, and the high-level ATT&CK tactics.
  • Try them in the lab. See what feels repetitive, and note which checks are always useful.
  • After a few engagements, extract the things you do every time into a tiny checklist. Put the checklist somewhere obvious.
  • Keep one file of "quirks and gotchas" from real engagements. These are the tactical rules you only learn from doing.
  • Revisit and prune. Every 3 months remove what no longer helps and add any new technique that proved useful.

Short comparison, in my language

  • PTES = flowchart for an engagement. Good for structure.
  • NIST = formal assessment language. Good for compliance and rigor.
  • OWASP = practical web testing playbook. Good for web work.
  • MITRE ATT&CK = adversary technique language. Good for scenario thinking and detection mapping.

Mix and match based on target and client needs.

Final, small thoughts

Methodology is worth learning but not worshipping. Use frameworks to create consistent work, not to avoid thinking. The useful frameworks are the ones that help you explain what you did, why you did it, and what the impact really is. Your personal methodology will end up being a stitched-together thing that is heavier on your experience than any book.

If I want to expand this later I will add a tiny reference matrix that maps PTES phases to OWASP sections and ATT&CK tactics for quick lookup. For now I will try to keep this short. This is mainly for my own reference and need to be revisited.