concept
stage: scope
2 min read
Penetration testing methodology
A good penetration test is a method, not a bag of tools: define the goal, work through the phases systematically, record everything, and report so the client can act.
PTESNIST SP 800-115OWASP Web Security Testing GuideOSSTMMMITRE ATT&CKnote-taking and evidence tools (Obsidian, Dradis)
Assessment types
- Vulnerability assessment: broad, mostly automated discovery and ranking of weaknesses. It answers "what is exposed?" and does not try to exploit.
- : a time-boxed attempt to exploit weaknesses and show the real impact, within an agreed scope. It answers "what can an attacker actually do?"
- : a goal-driven simulation of a realistic adversary over a longer period, often testing detection and response as much as prevention.
- Black box (no prior knowledge), gray box (some knowledge such as accounts and documentation) and white box (source code and architecture): more knowledge finds more issues in the same time.
The phases
- Planning and scoping: goals, scope, , access and logistics.
- Reconnaissance: learn the target from public and permitted sources.
- Discovery and enumeration: find hosts, services, applications and accounts, and what versions and configurations they expose.
- Vulnerability analysis: decide which weaknesses are real and which are worth testing.
- Exploitation: demonstrate the weakness with the least impact needed.
- Post-exploitation: determine what the access actually allows (data, other systems, privileges) and clean up what you changed.
- Reporting and retest: explain findings with evidence and fixes, then verify the fixes.
Standards worth knowing
The (PTES) describes the phases above. NIST SP 800-115 is a technical guide to security testing. The OWASP Web Security Testing Guide is the detailed checklist for web applications, and the defines what to verify. gives a shared vocabulary for the techniques used, so findings can be tied to detection coverage.
Work in a repeatable way
- Keep timestamped notes and raw evidence from the start; reports are written from notes, not memory.
- Make each test reproducible: exact request, account used, expected and actual result.
- Track what you change so you can clean up completely.
- Prefer depth on realistic attack paths over a long list of low-value issues.
# Engagement: <name> Tester: <name> Date range: <dates>
## Scope and constraints (copy from the signed RoE)
## Timeline (UTC)
- 2026-11-02 09:10 started passive recon on app.example.com
- 2026-11-02 11:40 enumerated API routes (see evidence/api-routes.txt)
## Hypotheses and results
| Hypothesis | Test | Result | Evidence |
|---|---|---|---|
| User B can read user A's invoices | GET /api/invoices/{id} with B's token | Confirmed | evidence/idor-01.png |
## Findings (draft)
- F-01 Broken access control on /api/invoices/{id}
## Cleanup checklist
- [ ] test accounts removed - [ ] uploaded files deleted - [ ] scanners stoppedconnections on the map
- Authorization, scope and ethicsboundsPenetration testing methodology
- Penetration testing methodologystarts withReconnaissance and attack surface
- Penetration testing methodologyends withReporting findings and driving remediation
updated on 14/10/2026 · sources to go deeper · report an error
Study before
Unlocks
test what you learned
Loading questions…