“We have had a penetration test” can mean very different things depending on who says it.
For one organisation, it may mean that an automated scanner was run and the resulting findings were exported into a colour-coded report. For another, it may describe a structured security assessment in which specialists defined clear objectives, reconstructed the attack surface, validated vulnerabilities manually, combined several weaknesses and demonstrated how far a real attacker could progress.
The difference is not simply the tooling. It is the methodology: the framework that determines what will be tested, how deeply it will be examined, which limits apply and how the conclusions will be supported.
A methodology does not guarantee a good penetration test on its own. Experience, technical judgement and an understanding of the business remain essential. Without a recognisable framework, however, the quality of the engagement can depend too heavily on the individual tester’s preferred tools and techniques. It also becomes difficult to determine whether the assessment was complete, repeatable or comparable with previous tests.
This article examines five of the most influential references used in offensive security: the OWASP Web Security Testing Guide, the Penetration Testing Execution Standard, OSSTMM, NIST SP 800-115 and MITRE ATT&CK.
They are not equivalent, and they do not necessarily compete with one another. Some structure the full engagement. Others provide depth for a particular technology, introduce a measurement model or describe the behaviour of real threat actors.
Professional penetration-testing teams usually combine several of them.
This article complements our guide to the penetration testing tools professionals actually use, which explains the role and limitations of the technical tooling used throughout an engagement.
Why methodology matters more than the tool
A tool answers a specific technical question.
Nmap can identify listening services. Burp Suite can intercept and manipulate an HTTP request. BloodHound can represent control relationships within Active Directory. None of those tools can decide whether the agreed scope has been covered properly, whether the identified issue matters to the business or whether enough evidence has been gathered to support a conclusion.
Methodology first provides coverage. It prevents the engagement from focusing only on the easiest or most familiar attack paths. The quality of the assessment should not depend entirely on whichever tools or techniques a particular consultant happens to prefer.
It also provides repeatability. Two testers may use different commands or utilities, but they should still examine comparable areas, preserve equivalent evidence and apply consistent evaluation criteria.
A third benefit is traceability. The client should be able to connect every finding to an affected asset, a test performed, supporting evidence, a credible impact and a remediation recommendation.
Finally, methodology enables comparison over time. When the scope and approach remain sufficiently consistent, an organisation can compare the current assessment with the previous one and determine whether its exposure and controls have genuinely improved.
Without that framework, a pentest risks becoming a one-off demonstration of technical skill. With it, the assessment becomes a manageable, repeatable security control.
There is no single universal pentesting methodology
The phrase “the penetration testing methodology” can be misleading.
A web application, an internal network, a cloud environment and an adversary-simulation exercise do not require the same approach. Nor do they necessarily pursue the same objective.
A web assessment needs depth in authentication, authorisation, sessions and business logic. An infrastructure pentest places greater emphasis on discovery, exposed services, segmentation and privilege relationships. A red-team exercise focuses on reproducing the behaviour of a plausible adversary and assessing whether the organisation can detect and contain the intrusion.
Professional teams therefore do not usually select one document and apply it word for word.
Instead, they construct an approach based on the target surface, the client’s objectives, the chosen black-box, grey-box or white-box model, the operational risk of the tests, applicable regulatory requirements and whether detection and response are also being assessed.
At Hard2bit, recognised frameworks provide structure rather than a mechanical checklist. The objective is to preserve coverage and traceability while adapting the engagement to the organisation’s actual technology and risk.
What each framework contributes
PTES is particularly useful for structuring the full penetration-testing engagement. OWASP WSTG provides technical depth for web applications and APIs. NIST SP 800-115 strengthens planning, governance and the wider security-assessment programme. OSSTMM introduces a broader operational-security and measurement perspective. MITRE ATT&CK helps describe and emulate the behaviour of real adversaries.
The right question is therefore not which framework is universally best.
It is which combination best supports the purpose of the engagement.
PTES: structuring the complete penetration test
The Penetration Testing Execution Standard, usually referred to as PTES, is one of the most practical references for structuring an engagement from beginning to end.
It was created to give clients and testing providers a shared understanding of what a penetration test should contain. PTES is organised into seven principal sections: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post-exploitation and reporting. (Pentest Standard)
Its main strength is that it does not begin with scanning.
It begins before any testing takes place, when the parties define the purpose of the engagement, its boundaries, authorised activities, communication channels, testing windows, evidence-handling requirements and rules of engagement.
This preparatory stage should address matters such as authorised networks, third-party infrastructure, social engineering, denial-of-service restrictions, emergency contacts and the conditions under which testing must stop.
That work is not administrative overhead. It is part of delivering the assessment safely.
A technically valid test can still create serious problems if it affects systems outside the agreed scope, causes unauthorised downtime, accesses unnecessary personal data or uses techniques that the client did not approve.
Where PTES is particularly strong
PTES encourages the testing team to connect technical activity with the business context.
Its threat-modelling stage considers assets, business processes, relevant threat communities and the capabilities of plausible attackers. This prevents the team from treating every system as equally important and helps focus effort on the attack paths that matter most.
It also distinguishes vulnerability analysis from exploitation.
Identifying a potentially unsafe condition does not prove that the condition can be used to gain access or create an impact. Exploitation is therefore treated as a deliberate, controlled activity rather than the indiscriminate execution of public proof-of-concept code.
Where PTES needs support
PTES remains a useful engagement structure, but its public technical material was explicitly intended as a baseline that would need to evolve with the industry. (Pentest Standard)
It should not be treated as a complete 2026 catalogue for cloud platforms, Microsoft Entra ID, modern APIs, Kubernetes, mobile applications, CI/CD systems or AI agents.
PTES works best as the skeleton of the engagement. Current, technology-specific guidance must provide the technical detail.
OWASP WSTG: depth for web applications and APIs
The OWASP Web Security Testing Guide, or WSTG, is one of the most widely recognised references for structuring security testing of web applications.
Unlike PTES, it is not intended to govern every part of the commercial engagement. Its focus is the technical coverage of the application itself.
The guide addresses areas such as information gathering, configuration, identity management, authentication, authorisation, session management, input validation, error handling, cryptography, business logic, client-side behaviour and APIs.
That depth makes it especially valuable during a web application security assessment or an API security assessment.
The WSTG is not the OWASP Top 10
The OWASP Top 10 and the WSTG are often mentioned together, but they serve different purposes.
The OWASP Top 10 is primarily an awareness document. It groups major categories of web-application risk into a format that is accessible to developers, managers and security teams.
The WSTG is a much broader testing guide. It helps practitioners design and execute test cases.
The OWASP Top 10:2025 keeps Broken Access Control in first place, places Security Misconfiguration second and introduces Software Supply Chain Failures as a dedicated category. (OWASP)
A penetration test limited to the Top 10 would nevertheless be inadequate.
An application may have no obvious textbook injection or configuration flaw and still be vulnerable because an approval stage can be bypassed, a race condition can be exploited, one tenant can reach another tenant’s data or a legitimate business function can be combined with another to produce an unintended result.
The WSTG provides structured coverage. Understanding business logic still requires human analysis.
How WSTG is applied in practice
A professional team does not normally execute every WSTG test case without considering the application.
The applicable tests are selected and adapted according to the technology, user roles, architecture, data sensitivity, business workflows, threat model and time available.
The team should also record which areas were tested, which were not applicable and which were restricted because they could introduce unacceptable risk in production.
The methodology creates coverage. The consultant provides interpretation.
NIST SP 800-115: planning and governing technical assessments
NIST Special Publication 800-115, Technical Guide to Information Security Testing and Assessment, provides guidance for planning and conducting technical security tests, analysing findings and developing mitigation strategies. (NIST Seguridad Informática)
It covers more than penetration testing.
Its scope includes documentation review, configuration review, log analysis, network discovery, vulnerability scanning, password testing, social engineering and controlled penetration testing.
This breadth is one of its main strengths.
Where PTES describes the offensive engagement more directly, NIST SP 800-115 places greater emphasis on assessment policy, planning, technique selection, resources, coordination, legal considerations, data handling and remediation.
It therefore fits well within large organisations, public-sector bodies and regulated environments where penetration testing forms part of a broader assurance programme.
What NIST contributes
NIST helps organisations decide which type of assessment is appropriate for a particular objective.
A penetration test is not always the only—or best—way to obtain assurance. An authenticated configuration review, a firewall ruleset assessment or a detailed architecture examination may provide greater coverage with lower operational risk.
The framework encourages the organisation to choose between review, identification, analysis and active validation rather than defaulting automatically to exploitation.
Its main limitation in 2026
NIST SP 800-115 was published in 2008.
Its core principles remain useful, but it does not natively reflect many contemporary architectures, including cloud-native platforms, federated identities, SaaS, Kubernetes, modern CI/CD environments, non-human identities and enterprise AI systems.
Its primary value today is the governance of technical security testing, not the provision of current attack techniques.
OSSTMM: measuring operational security
The Open Source Security Testing Methodology Manual, developed by ISECOM, approaches security testing as an evidence-based measurement of operational security.
OSSTMM is broader than a conventional network pentest. It considers several channels of interaction, including human, physical, wireless, telecommunications and data-network security.
One of its distinctive concepts is the Risk Assessment Value, or RAV, which attempts to relate operational exposure, controls and limitations in a consistent metric.
What OSSTMM adds
OSSTMM encourages the tester to think beyond lists of vulnerabilities.
Its model considers exposure, trust, controls, limitations and the different channels through which interaction can occur. This can be valuable when an organisation wants to examine physical, human, wireless and technical security under a common structure.
The focus on consistent measurement can also support comparisons between sites or successive assessments.
Practical limitations
OSSTMM 3 was released in 2010, so substantial adaptation is required for contemporary architectures and identity models.
Its RAV model is also less common in mainstream commercial pentesting than CVSS-based severity, contextual risk assessment and business-impact analysis.
A numerical value can suggest precision without necessarily making the result easier to understand. OSSTMM metrics should therefore be accompanied by clear technical evidence and business context rather than presented as a definitive score.
MITRE ATT&CK: adversary behaviour, not a complete pentest methodology
MITRE ATT&CK is frequently discussed alongside penetration-testing methodologies, but it performs a different role.
ATT&CK is a knowledge base of tactics and techniques derived from observed adversary behaviour. It describes how threat actors interact with systems throughout an intrusion.
It does not define how to agree the scope, manage evidence, avoid operational damage, rate findings or structure a penetration-test report.
It therefore does not replace PTES, OWASP or NIST.
Where ATT&CK creates real value
ATT&CK is particularly useful when designing red-team scenarios, emulating a known threat actor, mapping techniques observed during an incident, planning purple-team exercises and assessing detection coverage.
ATT&CK Navigator can be used to visualise selected techniques, represent defensive coverage and record the behaviours exercised during a simulation.
An engagement might select techniques across initial access, persistence, credential access, lateral movement and exfiltration, then determine whether the organisation can detect and respond to them.
This is more than finding vulnerabilities. It is testing security operations against recognisable adversary behaviour.
ATT&CK continues to evolve
Unlike more static publications, ATT&CK is updated regularly.
ATT&CK v19, released in April 2026, divided the former Defense Evasion tactic into two distinct tactics: Stealth and Defense Impairment. MITRE describes Stealth as concealment that leaves defensive systems intact, while Defense Impairment covers activity intended to degrade or disrupt defensive capabilities. (MITRE ATT&CK)
This evolution is one reason why detection programmes and testing plans should not be built around a fixed ATT&CK structure that is never reviewed.
For a more detailed distinction between technical testing and adversary simulation, see our guide to penetration testing, red teaming and breach-and-attack simulation.
The stages of a professional penetration test
Although the terminology varies between frameworks, a serious engagement normally follows a recognisable sequence.
The seven-stage PTES model provides a useful practical structure.
1. Scoping and rules of engagement
Before testing begins, the parties agree which assets are included, which systems are excluded, what techniques are authorised and what credentials or documentation will be provided.
They must also establish testing windows, emergency contacts, evidence-handling requirements, escalation procedures and the conditions that would require the test to stop.
This stage is not bureaucracy.
A poorly defined scope can result in a supplier’s infrastructure being tested without permission, a production service being disrupted or sensitive information being accessed unnecessarily.
The rules of engagement protect both the client and the testing team.
2. Intelligence gathering
The team reconstructs the attack surface available from the agreed starting position.
During a black-box assessment, this may involve public information, DNS, certificates, externally exposed assets and technology identification.
A white-box engagement may additionally use architecture diagrams, inventories, source code and internal documentation.
The goal is not to accumulate as much information as possible. It is to develop credible attack hypotheses.
3. Threat modelling
Not every asset has the same value, and not every plausible attacker has the same objective.
Threat modelling connects critical business functions, sensitive information, likely threat actors, attacker capabilities, access routes and potential impact.
This helps prevent the engagement from spending equal effort on a low-value system and an identity capable of controlling the entire environment.
It also creates a rational basis for deciding where greater testing depth is justified.
4. Vulnerability analysis
The team identifies potentially exploitable conditions through a combination of automation and manual analysis.
The important work lies in distinguishing between a false positive, a genuine but non-exploitable weakness, an exploitable vulnerability, a configuration issue, an informational exposure and an attack path that depends on several separate conditions.
An automated result is a candidate for investigation. It is not a conclusion.
This is one of the key differences between a penetration test and a vulnerability scan.
5. Controlled exploitation
Where authorised, exploitation demonstrates whether the weakness can create a real impact.
The team should apply the principle of minimum necessary proof. There is no need to extract an entire database if a controlled sample already proves that unauthorised access is possible.
Exploitation should answer a defined question. It should not become a competition to cause the greatest possible effect.
The tester must understand the preconditions, possible side effects and recovery implications before proceeding.
6. Post-exploitation and lateral movement
Once access has been obtained, the team determines what that position genuinely enables.
This may involve examining privilege escalation, credential reuse, access to additional network segments, movement towards critical systems or exposure of backup and virtualisation platforms.
This stage reveals the difference between an isolated vulnerability and a meaningful attack path.
A relatively modest initial weakness can become critical when it provides access to a privileged identity, a management network or a system holding sensitive data.
7. Reporting, remediation and retesting
The report must translate technical activity into decisions.
A useful finding explains what was observed, how it was reproduced, which assets are affected, what prerequisites exist, what impact is possible, which evidence supports the conclusion and how the weakness should be corrected.
It should also explain how the organisation can verify that the remediation has worked.
The engagement should not necessarily end when the report is delivered. Clarification, remediation workshops and retesting are often necessary to convert findings into measurable improvement.
Black-box, grey-box and white-box testing
The testing methodology is also influenced by how much information the assessment team receives.
Black-box testing
In a black-box engagement, the tester begins with little or no internal information.
This approximates the position of an external attacker who must discover the target environment independently.
The model is useful for assessing external exposure and, in some engagements, defensive detection. However, a substantial part of the available time may be spent discovering information that the organisation already possesses.
Black-box testing therefore does not automatically provide the greatest vulnerability coverage.
Grey-box testing
A grey-box assessment provides the tester with selected information, credentials or access.
This is frequently the most efficient model for business environments because it combines an external perspective with deeper testing of authenticated functionality.
For an application, the tester may receive accounts representing several roles. This allows the assessment to examine horizontal and vertical authorisation, tenant separation and workflow controls without spending the engagement trying to obtain basic access.
White-box testing
A white-box assessment provides extensive knowledge, which may include architecture, credentials, inventories and source code.
It does not attempt to replicate an uninformed attacker exactly. Its objective is to maximise coverage and identify weaknesses efficiently.
White-box testing is often appropriate for critical systems, complex applications and assessments where finding as many relevant weaknesses as possible is more important than recreating a single external threat scenario.
The choice should follow the engagement objective, not the assumption that one model is always more realistic.
Our guide to penetration testing types and methodology explores these models in greater detail.
Penetration testing, red teaming and BAS need different approaches
A penetration test seeks to identify and validate vulnerabilities within an agreed scope and time window.
A red-team exercise works towards defined objectives while reproducing the behaviour of a plausible adversary. It normally places greater emphasis on stealth, attack chaining, detection and response.
Breach-and-attack simulation automates repeatable security-control validation. It is intended to provide continuous or frequent testing rather than the contextual analysis of a human-led pentest.
PTES and OWASP are particularly relevant to penetration testing. MITRE ATT&CK contributes more directly to red-team and purple-team planning. BAS platforms often use catalogues of adversary techniques to automate repeatable controls.
TIBER-EU introduces a more formal framework for threat-led testing within relevant financial-sector contexts.
These exercises overlap, but they are not interchangeable. An organisation should not purchase one and assume that it will answer the questions addressed by another.
How a professional provider combines methodologies
In practice, a mature testing approach may use PTES to structure the engagement, OWASP WSTG to provide web and API depth, NIST SP 800-115 to strengthen planning and assurance, OSSTMM where broader operational measurement is relevant, and MITRE ATT&CK to map adversary behaviour and defensive visibility.
The team may also use specific references for mobile applications, cloud platforms, Kubernetes, Active Directory, source code or operational technology.
The value does not lie in filling a proposal with acronyms.
The combined methodology should be visible in the actual delivery through clear rules of engagement, coverage records, reproducible evidence, severity criteria, documented limitations, remediation guidance and retesting.
At Hard2bit, the approach changes according to the technology and objectives, but one principle remains constant: automation provides initial coverage, while specialists perform manual validation, attack chaining and impact analysis.
The result should be a defensible technical assessment, not a collection of scanner outputs.
When regulation influences the testing methodology
In some industries, the organisation does not have complete freedom to decide how testing should be performed and documented.
Regulation or industry standards may define frequency, independence, evidence, tester requirements, scope and remediation expectations.
DORA, TLPT and TIBER-EU
The EU Digital Operational Resilience Act requires financial entities to maintain digital operational resilience testing programmes.
It also establishes a more advanced form of threat-led penetration testing, or TLPT, for financial entities identified by the competent authorities.
It is therefore inaccurate to state that every financial organisation must perform a TLPT every three years.
The requirement applies to selected entities under the relevant regulatory criteria. For those entities, DORA generally requires TLPT at least every three years, although the competent authority may adjust the frequency according to the organisation’s risk profile.
Commission Delegated Regulation (EU) 2025/1190 defines the criteria for identifying relevant financial entities and sets requirements covering scope, testing methodology, internal testers, test phases, results, closure and remediation. The regulation was published on 18 June 2025 and was developed in alignment with TIBER-EU. (EUR-Lex)
The European Central Bank also updated the TIBER-EU framework in February 2025 to align it with DORA’s regulatory technical standards. (European Central Bank)
A TLPT is not simply a larger penetration test. It is an intelligence-led exercise covering critical or important functions and operating within a formal governance and supervisory structure.
Further information is available through our DORA compliance and operational resilience service and our financial-sector cybersecurity services.
PCI DSS 4.0.1
PCI DSS provides a global baseline of technical and operational requirements for protecting payment-account data. (PCI Security Standards Council)
Version 4.0.1 was a limited revision that clarified existing requirements without adding or removing requirements. (PCI Perspectives)
Requirement 11.4 covers internal and external penetration testing, testing after significant changes and testing of segmentation controls where segmentation is used to reduce the cardholder-data environment.
A scanner report alone is not sufficient.
The methodology must cover the relevant external and internal attack surface, consider applicable threats and vulnerabilities and retain evidence demonstrating how the conclusions were reached.
Hard2bit provides dedicated PCI DSS assessment and compliance support.
NIS2
NIS2 requires in-scope entities to adopt proportionate technical, operational and organisational risk-management measures. It also requires policies and procedures for assessing the effectiveness of those measures.
The Directive does not prescribe one universal penetration-testing methodology or an identical testing frequency for every organisation.
Independent technical testing can nevertheless provide strong evidence regarding external exposure, vulnerability handling, access control, segmentation, supplier risk and defensive effectiveness.
The selected approach should be proportionate to the organisation’s risk and to the systems supporting its essential or important services.
Our guide to the practical NIS2 obligations affecting suppliers and SMEs provides further context, while our NIS2 compliance service addresses implementation and assurance.
Spain’s National Security Framework
For organisations operating in Spain’s public-sector ecosystem, the Esquema Nacional de Seguridad, or ENS, can also affect testing and assurance requirements.
Royal Decree 311/2022 requires regular security audits for information systems within its scope, generally at least every two years. (BOE)
This does not mean that every system must undergo the same penetration test.
The appropriate technical testing should follow the system category, risk analysis, statement of applicability, architecture, exposure and services being delivered.
A penetration test can provide important evidence within an ENS audit or improvement programme, particularly for exposed or critical systems, but it should be justified as part of the wider assurance model rather than treated as an isolated universal requirement.
Hard2bit supports organisations through ENS audit readiness, ENS-aligned vulnerability management and professional penetration-testing services.
How to tell whether a provider uses a real methodology
A client does not need to ask the provider to recite every section of OWASP, NIST or PTES.
The provider should, however, be able to explain how the scope is defined, which areas will be tested, how the methodology is adapted to the technology and which activities are automated.
It should also explain how findings are validated, how exploitation risk is controlled, how attack chains are documented, which limitations affected the engagement and whether remediation testing is included.
A proposal that only lists tools such as Nmap, Nessus, Burp Suite and Metasploit does not demonstrate a methodology.
The tool list shows what the provider can run.
The methodology shows how the provider thinks.
It should also be clear whether the proposed service is a vulnerability scan, a security audit, a penetration test, a red-team exercise or continuous control validation.
Our comparison of a security audit and a penetration test explains this distinction in more detail.
The point that matters
Methodology is what turns a collection of offensive techniques into a serious security control.
It determines what will be tested, how deeply it will be examined, which rules apply, how evidence will be retained and whether the results can be compared with previous assessments.
PTES provides a structure for the full engagement. OWASP WSTG adds depth for web applications and APIs. NIST SP 800-115 strengthens planning and governance. OSSTMM introduces an operational measurement model. MITRE ATT&CK connects testing with observed adversary behaviour.
No single framework solves every scenario.
A good provider selects the appropriate references, adapts them to the organisation’s environment and documents its decisions and limitations clearly.
If the provider cannot explain which methodology it follows, what coverage it offers and how its conclusions are validated, the organisation may not be purchasing a professional penetration test.
It may simply be purchasing the execution of tools.
Need a penetration test built around evidence rather than scanner output?
Hard2bit performs penetration testing across web applications, APIs, infrastructure, internal networks, Active Directory, cloud platforms, wireless networks, mobile applications and other critical environments.
Our consultants combine recognised frameworks, automation and manual testing to define a risk-based scope, preserve traceable coverage, remove false positives, validate exploitability, build realistic attack paths and prioritise remediation.
The result is not an automated report. It is a defensible and reproducible technical assessment designed to support real security decisions.
Request a penetration-testing proposal tailored to your environment and objectives.