A penetration testing methodology is the documented process a tester uses to plan, run and report an authorised attack on your systems.
It controls three things: what gets checked; how impact is proven; and whether the report supports remediation, client reviews, PCI DSS or cyber insurance.
The right approach depends on the system and the question you need the test to answer.
If you define both before you book, your provider can test the attack paths that matter and report the evidence your next review requires.
Let’s have a look at it.
What Is a Penetration Testing Methodology?
A penetration testing methodology sets the stages, techniques and evidence rules that guide a penetration test from scope to report.
It gives your tester a repeatable process and gives you a clear basis for judging the result. Those responsibilities sit across three parts of the engagement:
| Engagement element | Question it answers | Why you need it |
|---|---|---|
| Methodology | How will the test be performed? | Shows how the tester will investigate and prove weaknesses. |
| Scope | What will be tested? | Defines the systems, applications, APIs, roles and exclusions. |
| Rules of engagement | What is allowed, when and under which limits? | Sets testing windows, permitted techniques, stop conditions and escalation contacts. |
It matters in practice when a client asks whether a specific system was tested.
For reference, PTES pre-engagement guidance separates scope from the rules of engagement because each controls a different part of the test.
If the client needs evidence about your customer portal, the scope should name the portal, supporting APIs and relevant user roles.
Why Does a Penetration Test Follow a Documented Methodology?
A documented methodology gives your penetration test four things:
- Planned coverage: The tester checks the agreed controls and attack paths.
- Traceable findings: The report links each conclusion to evidence and testing limits, which also makes later tests easier to compare.
- Controlled testing: The tester works within approved systems, times and stop conditions.
- Business evidence: A customer, assessor or insurer can see what was tested, how it was tested and what your team did next.
This makes your penetration test systematic, traceable and useful after testing ends.
Because offensive security uses attacker-style techniques, each action must connect to an agreed objective and boundary.
Together, these elements make the report easier for a buyer or assessor to rely on.
If the coverage stays vague, a tender or customer onboarding can stall while the buyer confirms whether the system they rely on was tested.
What are the Main Penetration Testing Methodologies?
The five common penetration testing methodologies are OSSTMM, OWASP WSTG, PTES, ISSAF and NIST SP 800-115.
Because they cover different parts of the job, choose your target first and use the sections below to match the reference.
Open Source Security Testing Methodology Manual (OSSTMM)
OSSTMM can suit a broader assessment when you need to test more than your IT systems, such as wireless networks, physical sites, people or telecommunications. OSSTMM moves through four phases:
- Induction: Agree the purpose, scope and limits of the test.
- Interaction: Map targets, access points, trust relationships and existing controls.
- Inquest: Investigate processes, configurations and information that may be exposed.
- Intervention: Test whether those controls hold up under authorised conditions.
Because OSSTMM can apply across several channels, the ISECOM manual records both what was tested and what was left out.
Consider when you review a quote; check which channels are included so you know where the testing will actually happen.
OWASP Web Security Testing Guide
OWASP WSTG is a practical guide for testing your web application.
It helps the tester check the areas attackers commonly target, including configuration, identity, login controls, permissions, sessions, input handling, cryptography and business logic.
You can review the WSTG test areas to see the depth it can bring to an application test.
If your app also exposes an API, ask how the provider will extend the test to cover API-specific risks.
It is also worth confirming the WSTG version and test cases in the proposal, because OWASP updates its guidance over time.
Penetration Testing Execution Standard (PTES)
PTES is useful when you need a clear process for the whole penetration test, from setting the scope through to reporting the findings. It breaks the engagement into seven stages:
- Pre-engagement: Agree the scope, authority and rules for testing.
- Intelligence gathering: Collect information about the target.
- Threat modelling: Identify the attack paths most worth testing.
- Vulnerability analysis: Find and validate weaknesses.
- Exploitation: Safely prove what a weakness could allow.
- Post-exploitation: Assess what an attacker could reach after gaining access.
- Reporting: Document the findings, impact and fixes.
That structure gives you a simple way to check whether a proposal covers the full job.
For instance, a tester can use OWASP WSTG for the web application work within the PTES structure, while your agreement should separately set out the retest scope, timing and fee.
Information System Security Assessment Framework (ISSAF)
ISSAF is a detailed reference for network, system and application testing, although the public manual is now a legacy draft.
It groups the work into three broad phases: planning and preparation; assessment; then reporting, cleanup and removal of test artefacts.
If a provider refers to the ISSAF manual, ask how they have updated its procedures for your current environment.
That matters if you rely on cloud services, modern identity tools or SaaS applications that the original manual does not fully reflect.
NIST SP 800-115
NIST SP 800-115 is a good fit when you need a wider technical assessment that combines penetration testing with reviews and vulnerability scanning.
Its penetration testing model has four stages: planning, discovery, attack and reporting.
The stages are not a strict one-way sequence. Reporting continues throughout the engagement, while a finding during the attack stage may send the tester back to discovery.
We recommend using NIST SP 800-115 as a way to understand the process, then ask your provider which of those activities their quote includes.
What Stages Does a Penetration Testing Methodology Cover?
A penetration test usually follows five stages: agreeing what can be tested, finding likely attack paths, validating weaknesses, reporting the impact and checking the fixes.
Methodology names differ, but these stages let you compare quotes properly and see whether important work has been left out.
Pre-engagement and scoping
Before testing starts, you and your provider need to agree exactly what the tester can do, where they can do it and when they must stop.
That gives the tester the authority to work safely, while helping your team avoid surprises during the engagement.
To turn that authority into practical instructions for the test, your scope should record:
- Targets and access: The systems, user roles and information the tester will use, plus any exclusions.
- Testing rules: Permitted techniques, testing windows and stop conditions.
- Contacts: Who the tester calls if they find something urgent, cause disruption or need a scope decision.
- Data and third parties: Data-handling rules and any approval your cloud or hosting provider requires before cloud penetration testing can begin.
These details decide whether the test is safe and whether the report answers the question you booked it to answer.
We suggest treating this preparation as part of the test because unclear authority can create legal and operational problems.
Let’s say like share any tender requirement, client questionnaire or PCI DSS obligation now, so the scope produces evidence your team can actually use later.
Reconnaissance and Threat Modelling
Reconnaissance shows the tester what is exposed, while threat modelling helps them decide which attack paths are worth your testing time.
They look at your services, application features, identities and trust relationships, then connect those technical details to what could happen in your business.
For instance, if you run a customer portal, the important question may be whether one customer can access another customer’s records.
That question gives the tester a clear path: test user roles, permissions and data boundaries rather than treating every feature as equally important.
Vulnerability Analysis and Exploitation
Vulnerability analysis finds weaknesses that may matter, while controlled exploitation checks what an attacker could actually achieve with them.
A vulnerability assessment can flag potential issues, but a penetration tester uses manual judgement to validate them and follow the attack paths they may create.
That distinction matters because a scanner alert and a proven security issue are not the same thing.
Because each result gives your team a different level of confidence and calls for a different response, the report should distinguish between:
- Confirmed impact: The tester proved the result within the agreed scope.
- Potential impact: The evidence supports the risk, although the tester could not safely or lawfully complete the exploit.
- Unconfirmed alert: The automated finding did not stand up to manual validation.
Be aware that each result calls for a different response from your team. Ask the provider to explain any limit on proof, so you know whether to fix, investigate further or close the alert.
Post-exploitation and Reporting
Once the tester gains authorised access, post-exploitation checks how far that access could reach.
It may show whether a foothold could lead to sensitive data, higher privileges or another system, provided those actions sit within your agreed scope.
The penetration testing report should then turn that evidence into work your team can own:
- What was affected: The assets, attack path and supporting evidence.
- Why it matters: The business effect and severity reasoning.
- What remains uncertain: Testing limits, exclusions and unanswered questions.
- What to do next: Remediation guidance and retest priorities.
Your technical team needs enough detail to reproduce and fix the issue, while your leaders need enough context to assign budget and ownership.
Also, agree how the tester will notify you of critical findings during the test, rather than waiting for the final report.
Remediation and Retesting
Remediation fixes the finding, while retesting checks whether the fix actually breaks the attack path the tester demonstrated.
You will get a cleaner hand-off if you agree to the retesting terms before the engagement starts.
To avoid a dispute over what happens after your team fixes an issue, the proposal should state:
- Eligible findings: Which fixes the provider will retest and when you need to submit them.
- Cost: Whether Retesting is included or charged separately, since a retest fee often sits outside the quoted penetration testing cost.
- Evidence: What the updated report will show once the fix passes.
- Changed systems: When an application or architecture change needs a newly scoped test.
With those terms agreed, your team can assign each finding to an owner and deadline without debating the next step later.
A focused retest checks specific fixes; if the system has changed substantially, it may need a fresh scope.
What are Black Box, Grey Box and White Box Testing?
Black box, grey box and white box describe how much knowledge and access you give the tester.
They are access models within a methodology, and your choice affects how the tester spends the available time.
The following comparison shows what each starting position lets the tester prioritise:
| Testing model | What you provide | Best used when you need to know |
|---|---|---|
| Black box | Minimal technical information and usually no credentials | What an external attacker can discover and reach with little prior knowledge |
| Grey box | Selected accounts, documents or architecture details | What a customer, employee or partner could do with defined access |
| White box | Extensive internal information, potentially including code and privileged access | Whether controls and implementation hold up under detailed inspection |
Use that trade-off against your main concern.
Let’s say, if you need to know whether users can cross permission boundaries, grey box testing with each relevant role lets the tester spend more time on that problem.
Also, always remember that every model still needs written authorisation, scope and rules of engagement.
Which Methodology Suits Which Type of Test?
Match the methodology to the asset and evidence you need because no single reference covers every test equally well.
The table that follows connects each test with a practical starting point and the scope question you still need answered:
| You need to test | Starting point | Confirm before you book |
|---|---|---|
| Web application | PTES for the engagement and OWASP WSTG for test coverage | User roles, business logic, authentication, sessions and client-side functions. |
| API | PTES plus WSTG and API-specific OWASP guidance | Endpoints, object-level authorisation, tokens, rate limits and workflow abuse. |
| Internal or external network | PTES with NIST SP 800-115 or relevant OSSTMM guidance | Starting position, reachable systems, privileges, segmentation and lateral movement. |
| Wider technical security assessment | NIST SP 800-115 | Which reviews, scans and penetration tests contribute to the objective. |
| Human, physical, wireless or telecommunications environment | Relevant OSSTMM channels | Locations, participants, interactions and explicit authority. |
| Mobile application | An engagement structure plus OWASP MASVS and MASTG | Platform versions, app build, backend APIs, local storage and device conditions. |
| Assessment using ISSAF procedures | ISSAF as a supporting reference | How legacy procedures have been updated for your deployed technology. |
Applied to an Australian SMB customer portal, that logic points to PTES for the engagement, WSTG for application coverage and grey box access for each user role.
What do Australian Compliance and Insurance Requirements Expect from a Methodology?
Australian cybersecurity compliance and insurance reviews are easier to satisfy when your penetration testing methodology shows what was tested, how it was tested, and how findings were fixed.
That turns the report into evidence your team can give a client, insurer or assessor, rather than a technical document they must interpret.
Although written for PCI DSS, the PCI SSC Penetration Testing Guidance v1.1 is a useful reference for methodology basics: agreed scope, suitable testing, clear reporting and retesting.
But, be careful; it does not mean PCI DSS applies to your business. Those basics produce different evidence depending on what your review needs.
Essential Eight
The Essential Eight is a recommended baseline for reducing common cyber threats, while a penetration test can check how selected systems and controls hold up against realistic attack paths.
It does not prove a maturity level by itself, so give the provider your target maturity level, systems in scope and any control exceptions.
Cyber insurance
Your insurer’s application sets the requirement because questions and evidence needs vary.
One Australian cyber insurance form, for example, asks how often you test your network architecture and which provider conducts the work, so share the actual form before scoping.
SMB1001:2026
The SMB1001:2026 gives your business a tiered path for demonstrating security maturity.
If you are working towards Diamond, the methodology needs to support annual external penetration, vulnerability and social-engineering testing, with evidence of the findings and remediation.
Hence, ask the reviewer to confirm the scope, report age and remediation evidence they need. You can then book a test that supports the certification, insurance renewal or customer review in front of you.
How Do You Check a Provider’s Methodology Before You Engage Them?
You check a provider’s methodology by matching its proposed scope and sample report against the outcome you need from the test.
A provider should be able to show how their approach turns your systems, user roles and review requirements into defined testing and usable evidence.
That is where the following questions help you test whether the proposal covers the work, proof and follow-up your team will rely on:
- Which references and versions guide the test? Ask how they become test cases for your systems.
- Which assets, functions and user roles are included? Require a written list of exclusions and access assumptions.
- Where will the tester use manual judgement? Ask how they validate scanner results, test business logic and investigate linked weaknesses.
- Who will perform the work? Check the assigned testers’ relevant experience, credentials and required independence.
- What will the report prove? Look for reproducible evidence and explained severity, plus business impact, testing limits and urgent escalation.
- How will retesting work? Confirm the included findings, fee, deadline and updated evidence.
Once those six answers are defined, attach the requirement the report must satisfy.
For cyber insurance, use the insurer’s questionnaire; for a tender or client review, use the buyer’s requirement.
Ask the provider to mark anything the scope will not answer before it becomes a late procurement problem.
Test Your Defences with Redscale
A penetration test without a defined methodology can leave you with a report that does not answer a client, insurer or SMB1001 assessor’s question.
When the scope misses a customer-facing application, key user role or retest arrangement, your team may have to commission more testing while a tender or renewal waits.
Redscale penetration testing services turn the requirement into a scoped test, validated findings and evidence your team can act on.
Our pen test services are delivered by practitioners with CREST Registered Penetration Tester (CRT) and CREST Practitioner Security Analyst (CPSA) credentials.
Book a free discussion with Redscale to scope the proof your next review needs.
