Penetration Testing Methodologies and Frameworks

It is tempting to equate penetration testing with a toolkit — a scanner, an exploitation framework, a set of scripts. In reality, the tools are interchangeable; the methodology is what separates a professional assessment from an amateur one.

Repeatability and comparability

A documented methodology means two things. First, that a test can be repeated — by the same tester next quarter, or by a different tester next year — and produce comparable coverage. Second, that findings can be tracked over time, so an organization can see whether its security posture is improving. Ad hoc testing offers neither.

Coverage and completeness

Without a method, testers gravitate toward what they know and miss entire categories of weakness. A structured methodology forces consideration of authentication, authorization, session management, injection, configuration, and business logic — even when the obvious vulnerabilities appear first.

Defensibility

When a test underpins a compliance attestation or a board-level risk decision, the methodology is what makes the result defensible. "We followed PTES and the OWASP WSTG across the defined scope" is a stronger statement than "we ran some tools and reported what we found."

The goal of a methodology is not to constrain skilled testers — it is to guarantee a floor of coverage so that skill is spent on depth, not on remembering the basics.

GuardsArm penetration testing engagements are built on recognized methodologies precisely so that clients receive results they can trust, repeat, and act on.

The Penetration Testing Execution Standard (PTES) is one of the most widely referenced end-to-end methodologies. It defines seven phases that carry an engagement from initial conversation to final report.

The seven phases

• Pre-engagement interactions. Define scope, rules of engagement, objectives, timelines, and legal authorization. This is where a test succeeds or fails before any packet is sent.
• Intelligence gathering. Collect open-source and technical information about the target — the reconnaissance foundation for everything that follows.
• Threat modeling. Identify the assets that matter and the adversaries likely to target them, shaping where effort is focused.
• Vulnerability analysis. Discover and validate weaknesses across the in-scope surface.
• Exploitation. Prove that a vulnerability is real and exploitable, not just theoretically present.
• Post-exploitation. Determine the actual business impact — what data, systems, and privileges the foothold yields.
• Reporting. Communicate findings, impact, and remediation to both technical and executive audiences.

Why PTES endures

PTES is popular because it is comprehensive and technology-agnostic. It applies equally to a network test, an application test, or a red-team exercise. Its emphasis on pre-engagement and threat modeling — the phases inexperienced testers skip — is what keeps engagements focused on real business risk rather than noise.

The phases most often rushed, pre-engagement scoping and post-exploitation impact analysis, are exactly the ones that determine whether a test produces actionable results.

NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, is the reference many organizations and auditors treat as authoritative — particularly in regulated and government-adjacent contexts.

A four-phase model

NIST SP 800-115 frames security testing around four phases: planning, discovery, attack, and reporting. The discovery and attack phases form a feedback loop — information learned during exploitation feeds back into further discovery, mirroring how real assessments actually unfold.

Broader than penetration testing

One strength of SP 800-115 is that it situates penetration testing within a wider assessment toolkit that also includes vulnerability scanning, security configuration review, and log analysis. It makes clear that penetration testing is one technique among several, best used to validate and demonstrate impact rather than to catalog every weakness.

Techniques and cautions

The guide covers technical review techniques, target identification and analysis, and target vulnerability validation. Crucially, it also emphasizes safety and legal considerations — handling of sensitive findings, avoiding disruption, and coordinating testing windows.

Where it fits

Because it is published by NIST, SP 800-115 is frequently cited to satisfy compliance obligations that require an independent assessment. It pairs well with control frameworks and is often used as the methodological backbone for infrastructure and network penetration tests where auditors expect a recognized standard.

When the target is a web application, API, or mobile app, the Open Worldwide Application Security Project (OWASP) provides the most detailed and widely adopted guidance.

The OWASP Testing Guide (WSTG)

The Web Security Testing Guide (WSTG) is an exhaustive catalog of test cases organized by category — information gathering, configuration, identity management, authentication, authorization, session management, input validation, error handling, cryptography, business logic, and client-side testing. Each test case describes how to identify and validate a specific class of weakness.

The OWASP Top 10 as a lens

The OWASP Top 10 distills the most critical web application risks — including broken access control, cryptographic failures, injection, and security misconfiguration. It is not a testing methodology on its own, but it provides a risk-ranked lens that keeps testing focused on what matters most.

API and mobile coverage

OWASP maintains parallel resources for modern surfaces: the API Security Top 10 addresses risks unique to APIs such as broken object-level authorization, while the Mobile Application Security Verification Standard (MASVS) and Application Security Verification Standard (ASVS) provide graded requirements for verifying application security depth.

Business logic testing

Scanners find injection and misconfiguration; they rarely find flawed business logic. OWASP's structured test cases push testers to probe workflows — price manipulation, privilege escalation through intended features, and abuse of legitimate functionality — where the most damaging application flaws hide.

For application assessments, GuardsArm maps engagements to the WSTG and ASVS so that coverage is explicit and verifiable against a recognized standard.

Beyond the mainstream frameworks, specialized methodologies address particular testing philosophies and target types.

OSSTMM

The Open Source Security Testing Methodology Manual (OSSTMM), maintained by ISECOM, takes a scientific, metrics-driven approach. Rather than a checklist of vulnerabilities, it focuses on measuring operational security across channels — human, physical, wireless, telecommunications, and data networks — and expresses results through a repeatable trust and controls metric. Organizations that want quantifiable, comparable security measurements over time often adopt OSSTMM concepts.

Domain-specific guidance

• Wireless and IoT. Testing radio, embedded, and hardware targets requires methods that account for physical access, firmware analysis, and protocol-level weaknesses.
• Cloud. Cloud assessments follow shared-responsibility boundaries and provider rules of engagement, focusing on identity, configuration, and exposed services rather than traditional network exploitation.
• Red teaming. Full-scope adversary emulation blends technical exploitation with social engineering and physical access, and is often governed by frameworks like TIBER-EU or CBEST in regulated sectors.

Combining methodologies

Most real engagements blend frameworks. A web application test might use the WSTG for coverage, PTES for overall structure, and the OWASP Top 10 for risk ranking. The methodology should be assembled to fit the target, not forced onto it.

Methodologies are not rivals to choose between. The mark of an experienced tester is knowing which parts of each to combine for a given scope.

Traditional methodologies describe how to test. MITRE ATT&CK describes how real adversaries behave — and increasingly, modern penetration tests are built around it.

A knowledge base of adversary behavior

ATT&CK is a curated matrix of the tactics, techniques, and procedures (TTPs) that real threat actors use, observed across thousands of intrusions. Tactics represent adversary goals (initial access, persistence, lateral movement, exfiltration); techniques describe how those goals are achieved.

From methodology to scenario

Mapping a test to ATT&CK transforms it from a generic vulnerability hunt into a threat-informed scenario. Instead of asking "what is vulnerable?", the tester asks "could an adversary using these specific techniques achieve their objective against us?" This aligns testing with the real threat landscape and with the defensive controls the blue team is trying to build.

Coverage and gap analysis

Because ATT&CK is a shared taxonomy, findings can be mapped to specific techniques — making it clear which adversary behaviors were tested, which succeeded, and which detection gaps exist. This is far more actionable to a defender than an unmapped list of issues.

Bridging offense and defense

ATT&CK gives testers and defenders a common language. A finding expressed as "lateral movement via technique T1021 went undetected" tells the SOC exactly what to build next.

GuardsArm uses ATT&CK to design threat-informed engagements and to map results back to detection and response capabilities, turning a penetration test into concrete improvements for the defensive team.

With multiple frameworks available, the practical question is which to apply. The answer depends on the target, the objective, and the compliance driver.

Match method to target

• Web apps, APIs, mobile — OWASP WSTG, ASVS, API Security Top 10.
• Networks and infrastructure — NIST SP 800-115 and PTES.
• Full-scope adversary emulation — PTES structure plus MITRE ATT&CK scenarios, and regulated red-team frameworks where applicable.
• Quantified, repeatable measurement — OSSTMM concepts.

Let the objective lead

A compliance-driven test (for PCI DSS, SOC 2, or ISO 27001) should map explicitly to a recognized standard so the result satisfies the auditor. A risk-reduction test should be threat-informed, prioritizing the scenarios most damaging to the business. A validation test after remediation should re-run the exact prior cases to confirm fixes.

Define rules of engagement first

Whatever the methodology, the engagement must begin with clear scope, authorization, and rules of engagement — in-scope systems, testing windows, prohibited actions, and escalation contacts. This is non-negotiable and precedes any technical work.

The consistent thread

Every credible methodology shares the same backbone: plan, gather intelligence, discover, exploit, assess impact, and report. Mastering that arc — and knowing which framework sharpens each phase — is what makes testing repeatable and trustworthy. GuardsArm scopes each engagement to the methodology that best fits the client's targets and compliance obligations.