Penetration testing simulates realistic attacks against systems, networks, applications, or people to determine whether security weaknesses can be exploited.
However, the quality of a penetration test depends on more than the tester’s technical ability. The engagement also requires a structured penetration testing methodology that defines how the assessment will be planned, performed, documented, and concluded.
Methodologies help testers maintain consistent coverage, operate within authorised boundaries, gather reliable evidence, and translate technical findings into practical remediation.
Several recognised penetration-testing frameworks are available, including PTES, NIST SP 800-115, the OWASP Web Security Testing Guide, and the Open Source Security Testing Methodology Manual.
This article explains what a penetration testing methodology is, the main testing approaches, how the leading frameworks differ, and how organisations can select an appropriate methodology.
What Is a Penetration Testing Methodology?
A penetration testing methodology is a structured process for conducting an authorised security assessment.
It normally defines:
- How the scope is agreed
- What information is collected
- How vulnerabilities are identified
- When exploitation is permitted
- How business impact is assessed
- Which evidence is retained
- How findings are reported
- How remediation is verified
NIST SP 800-115 provides guidance for planning and conducting technical security tests, analysing findings, and developing mitigation strategies. It is intended to help organisations establish repeatable assessment processes rather than rely on unstructured testing.
A methodology does not replace tester expertise. It provides a framework within which professional judgement can be applied consistently.
Methodology, Framework and Scope
The terms methodology, framework, and scope are related but have different meanings.
A methodology describes the process used to perform the test.
A framework provides organised guidance, phases, techniques, or test cases that can support that methodology.
The scope defines the specific systems, applications, networks, accounts, locations, and techniques included in an individual engagement.
For example, an organisation could use:
- PTES as its overall engagement structure
- OWASP guidance for testing a web application
- NIST guidance for assessment planning and reporting
- A defined scope containing selected domains and APIs
Frameworks are therefore not necessarily competing alternatives. An effective engagement may combine guidance from several sources.
Why Use a Structured Methodology?
Consistent Coverage
A defined methodology reduces the likelihood that important areas will be missed because of time pressure or differences between individual testers.
Controlled Testing
Penetration testing can affect live services. A methodology establishes authorisation, communication routes, restrictions, and escalation procedures before testing begins.
Reproducible Evidence
Findings should be supported by evidence explaining what was tested, how the weakness was exploited, and what impact was demonstrated.
Practical Reporting
Structured testing creates a clearer connection between technical activity, business risk, and recommended remediation.
Quality Assurance
A documented process allows another qualified reviewer to assess whether the work was complete, proportionate, and consistent with the agreed objectives.
Testing Approaches: Black, Grey and White Box
Penetration testing can be performed with different levels of information and access depending on the objectives of the assessment.
- Black box testing gives the tester little or no prior knowledge and is useful for simulating an external attacker approaching the environment from the outside.
- Grey box testing provides limited information or access, such as a standard user account, and can simulate a compromised employee, customer, or other partially trusted user.
- White box testing gives the tester extensive knowledge of the environment, allowing more time to be spent examining controls, configurations and complex attack paths in depth.
No approach is universally better. The appropriate model depends on whether the organisation values external realism, deeper technical coverage, or a balance between the two.
These approaches are explored in more detail in SeCore’s guide to the different types of penetration testing.
The Typical Penetration Testing Process
Different frameworks use different terminology and structures, but most penetration tests follow a broadly similar lifecycle.
A typical assessment includes:
- Pre-engagement planning – defining objectives, scope, authorisation, permitted techniques, exclusions and reporting requirements
- Information gathering – understanding the target environment and identifying potential attack paths
- Vulnerability analysis – examining systems for weaknesses through automated and manual assessment
- Exploitation – safely validating whether selected vulnerabilities can be used to gain unauthorised access or achieve another agreed objective
- Post-exploitation – assessing the potential impact of successful compromise, including privilege escalation, lateral movement and access to sensitive information
- Reporting and remediation – documenting confirmed findings, business impact and recommended corrective action, followed by retesting where appropriate
These stages provide a common foundation, but recognised industry frameworks differ in how they organise, extend and apply them. The full penetration testing methodology and process is covered in SeCore’s introductory guide to penetration testing.
The sections below focus specifically on the major frameworks organisations can use to structure and govern that process.
Penetration Testing Execution Standard
The Penetration Testing Execution Standard, or PTES, provides a broad structure for penetration-testing engagements.
PTES defines seven main sections:
- Pre-engagement interactions
- Intelligence gathering
- Threat modelling
- Vulnerability analysis
- Exploitation
- Post-exploitation
- Reporting
The accompanying technical guidelines provide baseline procedures and tool considerations, while recognising that testers must adapt their approach to the particular engagement.
PTES is useful when an organisation needs an end-to-end structure covering both engagement management and technical testing.
Its threat-modelling stage is particularly valuable because it helps connect discovered assets and weaknesses with the attackers, objectives, and business risks relevant to the organisation.
NIST SP 800-115
NIST Special Publication 800-115 is the Technical Guide to Information Security Testing and Assessment.
It covers:
- Assessment planning
- Review techniques
- Target identification and analysis
- Vulnerability validation
- Assessment execution
- Post-testing activities
The guide discusses the purpose, strengths, and limitations of different security-testing techniques. It can support vulnerability identification, control validation, and assessment against policies or requirements.
NIST SP 800-115 is particularly useful for organisations seeking a formal and risk-based assessment process that integrates with wider security governance.
It is broader than penetration testing alone and also covers activities such as documentation review, log review, network discovery, vulnerability scanning, and configuration assessment.
OWASP Web Security Testing Guide
The OWASP Web Security Testing Guide, or WSTG, is a comprehensive framework for testing web applications and web services.
Its testing areas include:
- Information gathering
- Configuration and deployment
- Identity management
- Authentication
- Authorisation
- Session management
- Input validation
- Error handling
- Cryptography
- Business logic
- Client-side security
- APIs
OWASP describes the WSTG as a framework of testing best practices used by penetration testers and organisations conducting application-security assessments.
The WSTG is most appropriate for web application penetration testing methodology rather than as the sole framework for every type of infrastructure assessment.
It can also be combined with a broader engagement structure such as PTES.
Open Source Security Testing Methodology Manual
The Open Source Security Testing Methodology Manual, or OSSTMM, is maintained by the Institute for Security and Open Methodologies.
ISECOM describes OSSTMM as a methodology for testing, analysing, and measuring operational security. Its scope extends beyond conventional technical penetration testing into areas such as physical, human, wireless, telecommunications, and data-network security.
OSSTMM is distinguished by its emphasis on:
- Operational security
- Defined testing channels
- Trust relationships
- Repeatable measurement
- Evidence-based analysis
It may be useful where an organisation wants a broader operational-security assessment extending beyond a single application or network.
However, OWASP notes that OSSTMM is better used as a supporting operational-security reference than as a hands-on application-testing guide.
Specialised Testing Methodologies
The chosen methodology should reflect the technology and risks being assessed.
Network Penetration Testing Methodology
Network testing focuses on:
- Hosts and services
- Network segmentation
- Authentication
- Directory services
- Privilege escalation
- Lateral movement
NIST SP 800-115 can provide useful structure for infrastructure assessments.
Web Application Penetration Testing Methodology
Web testing focuses on application logic, authentication, authorisation, sessions, input handling, and connected services.
The OWASP WSTG provides the most detailed specialist guidance among the major frameworks discussed here.
API Security Testing Methodology
API assessments should consider:
- Object-level authorisation
- Authentication
- Data exposure
- Rate limiting
- Business workflows
- Machine identities
- Input validation
API testing may use relevant OWASP guidance alongside application-specific threat modelling.
Cloud Penetration Testing Methodology
Cloud testing must address:
- Identity and access management
- Cloud configuration
- Storage
- Workloads
- APIs
- Deployment pipelines
- Shared responsibility
- Provider testing restrictions
Internal Penetration Testing Methodology
Internal testing simulates a compromised user, device, or trusted network position.
It should assess whether an attacker can escalate privileges, move laterally, access sensitive resources, and avoid detection.
Choosing the Right Penetration Testing Framework
The organisation should consider several factors.
Assessment Objective
The methodology should reflect the question the organisation wants answered.
For example:
- Can an external attacker enter the network?
- Can one customer access another customer’s information?
- Can a compromised employee account reach critical systems?
- Can cloud permissions be escalated?
- Will monitoring detect realistic attacker activity?
Target Technology
A web application, internal network, API, cloud environment, and operational-technology system require different technical coverage.
Available Knowledge
The organisation should decide whether black box realism or white box depth provides greater value.
Regulatory and Contractual Requirements
Some standards specify testing scope, frequency, independence, qualifications, or reporting requirements.
The methodology must satisfy those obligations rather than merely reference a recognised framework.
Risk and Business Criticality
High-risk systems may require deeper testing, additional user roles, broader attack-path analysis, or targeted scenario testing.
Time and Resources
The methodology must be achievable within the available testing window without sacrificing critical coverage.
Combining Methodologies
Organisations do not need to select one framework exclusively.
A well-designed engagement might use:
- PTES for the overall engagement lifecycle
- NIST SP 800-115 for planning and assessment governance
- OWASP WSTG for web application test cases
- OSSTMM principles for broader operational-security analysis
The important requirement is transparency.
The testing provider should explain which methodology is being used, how it has been adapted, which areas are covered, and what limitations remain.
Applying Penetration Testing Frameworks in Practice
Recognised penetration testing frameworks help organisations structure assessments so they are consistent, repeatable and aligned with the objectives of the engagement. PTES, NIST SP 800-115, the OWASP Web Security Testing Guide and OSSTMM each provide different forms of guidance, and organisations do not necessarily need to rely on one framework exclusively.
The appropriate framework, or combination of frameworks, should reflect the systems being assessed, the threats they face, the required level of assurance and any relevant regulatory or contractual obligations. Combining recognised frameworks where appropriate can provide broader coverage while allowing the assessment to remain proportionate to the environment.
SeCore applies recognised penetration testing frameworks through its Penetration Testing services to help organisations identify exploitable weaknesses, understand realistic business impact and prioritise remediation. By selecting and adapting the right framework for each environment, organisations can achieve more consistent, transparent and actionable security assurance.
