What is a penetration testing methodology?
A penetration testing methodology is the set process a tester follows, from agreeing the scope to the final report. It makes sure nothing important is skipped and testing stays inside agreed rules. It also lets you compare results across testers and years. The most widely used general framework is PTES, the Penetration Testing Execution Standard. It splits a test into seven stages.
Methodology is also how you tell a real penetration test from a scan with a cover page. If a provider cannot explain their process, treat that as a warning sign. Not sure whether you need a full test or a scan? See vulnerability assessment vs penetration testing.
The seven PTES penetration testing stages
A group of security experts wrote PTES to define what a penetration test should include. Its seven stages are:
| Stage | What happens | Output |
|---|---|---|
| 1. Pre-engagement interactions | Scope, goals, timing, contacts, rules of engagement and written authorization are agreed | Signed scope and rules of engagement |
| 2. Intelligence gathering | The tester collects information about the target: domains, IP ranges, technologies, people and exposed services | A map of the attack surface |
| 3. Threat modeling | Identify the valuable assets, the likely attackers and the paths they would take | A prioritized list of attack scenarios |
| 4. Vulnerability analysis | Find weaknesses through scanning, manual review and research | Candidate vulnerabilities |
| 5. Exploitation | Attempt to exploit the weaknesses to prove they are real and gain access | Confirmed vulnerabilities with evidence |
| 6. Post-exploitation | Work out what the access is worth: sensitive data, privilege escalation, lateral movement, persistence | Demonstrated business impact |
| 7. Reporting | Document findings, impact, evidence and remediation for executives and engineers | Final report and debrief |
In practice, stages 2 to 6 repeat. A foothold gained during exploitation often reveals new systems. That sends the tester back to intelligence gathering.
What happens in the key penetration test stages
Pre-engagement is where many tests go wrong. The scope must name exact targets, such as domains, IP ranges, apps and cloud accounts. It must say what is off limits and when testing can happen. It must say whether social engineering (tricking staff) or denial of service (overloading systems) is allowed. It must also name who to call if something breaks or a real break-in is found. Written approval from someone who owns the systems is a must. Hosting and cloud providers' testing rules must be respected too.
Intelligence gathering and threat modeling separate a targeted test from a generic one. Say a tester knows your most valuable assets are a payments API and a customer database. They will spend time there, not on the marketing site.
Exploitation and post-exploitation are what make it a penetration test. A scanner reports that a weakness may exist. A tester proves it, then shows what it leads to. For example, they might read another tenant's (customer account's) records or take over an admin account. Good testers do this with care. They avoid harmful actions, keep evidence and stop to tell you if they find something critical.
How OWASP WSTG, OSSTMM and NIST SP 800-115 relate to PTES
PTES describes the whole engagement. Other frameworks cover the same ground from a different angle, or go deeper on one type of target. Most providers combine them.
| Framework | Published by | What it is for |
|---|---|---|
| PTES | A community of security practitioners | End-to-end engagement structure, from scoping to reporting |
| OWASP WSTG (Web Security Testing Guide) | OWASP | Detailed test cases for web applications, covering areas such as authentication, session management, authorization and input validation |
| OSSTMM (Open Source Security Testing Methodology Manual) | ISECOM | A measurement-focused methodology for operational security across human, physical, wireless, telecommunications and data network channels |
| NIST SP 800-115 | US National Institute of Standards and Technology | The Technical Guide to Information Security Testing and Assessment, with a four-phase model: planning, discovery, attack and reporting |
A typical web app test follows PTES for the engagement and the OWASP WSTG for test cases. OWASP is a nonprofit that publishes free web security guides. An internal network test might follow NIST SP 800-115. It might also map attacker techniques to MITRE ATT&CK, a public catalog of how real attackers work. Mobile apps are usually tested against the OWASP MASTG. PCI DSS, the card payment security standard, also requires pentests to follow a defined method based on industry-accepted approaches. So it is fair to ask which one your provider uses.
Black box, gray box and white box testing
The "box" describes how much the tester knows about your systems before they start.
| Approach | What the tester gets | Best for |
|---|---|---|
| Black box | Nothing beyond the target names, like an outside attacker | Testing external exposure and detection; least coverage per day of effort |
| Gray box | User accounts for each role and some documentation, such as an API spec | Most web app and API tests; a good balance of realism and coverage |
| White box | Full access: source code, architecture diagrams, admin accounts and configuration | Maximum coverage in limited time and code-heavy reviews of critical systems |
Black box sounds more realistic. But real attackers have months, and you are paying for days. Gray box usually finds more for the same budget, because the tester does not spend half the time trying to get past a login screen. It is also the only practical way to test access control between user roles.
What a good penetration test report contains
The report is the part you keep. A useful one includes:
- Executive summary in plain language: overall risk, the most important findings and what they mean for the business.
- Scope and methodology: exactly what was tested, when, from where, with what access and which frameworks were used.
- Findings, each with a severity rating (often CVSS, a 0 to 10 score) and the affected systems. Each needs a clear description, steps to repeat it and evidence such as requests, replies or screenshots.
- Business impact for each finding, not just technical severity.
- Remediation guidance clear enough for an engineer to act on, plus longer-term advice.
- Attack narratives showing how findings were chained, where relevant.
- Retest results confirming which issues were fixed and checked.
What to prepare before a penetration test
Good preparation saves paid testing days for actual testing. Before kickoff, have these ready:
- A precise scope: URLs, IP ranges, API definitions, cloud accounts and anything that is off limits.
- Test accounts for every user role, ideally in a staging (test) environment with realistic data.
- Written approval, plus sign-off from hosting providers or other third parties if their rules require it.
- A decision on protections. You can allow-list tester IPs to test the app rather than your WAF (web application firewall). Or you can leave protections on deliberately.
- A technical contact during testing hours and an emergency contact for critical findings.
- Notice to your SOC or MDR provider, the team that watches your systems for attacks. Skip this only if testing their detection is part of the goal.
- Backups and a rollback plan if any testing touches live systems.
- A clear goal: compliance evidence, a customer request, a new release or a specific concern.
Scope and preparation also drive price. Our guide to how much a penetration test costs explains the main factors.
How NextGarrison helps
NextGarrison penetration tests follow PTES and OSSTMM, with attacker techniques mapped to MITRE ATT&CK. Every report includes steps to repeat each finding, business impact and fix guidance. We also retest your fixes. Tell us what you need tested and we will send a scoped quote.
Need a hand with this?
Talk to a senior consultant. We reply within one business day with clear next steps and a scoped quote.
Written by
NextGarrison Security TeamPenetration testers, SOC analysts and compliance consultants
Our consultants test applications and networks, run 24/7 security monitoring and prepare companies for SOC 2, ISO 27001 and PCI DSS assessments. We write about what we see in real engagements, in plain English.