Why a repeatable methodology matters
A penetration test is only defensible if it follows a documented, repeatable process. Two testers working the same scope should arrive at comparable coverage, and a client should be able to see exactly what was and was not examined.
The most widely referenced public frameworks are the Penetration Testing Execution Standard (PTES), NIST Special Publication 800-115 (Technical Guide to Information Security Testing and Assessment), the OWASP Web Security Testing Guide, and the OSSTMM. They overlap heavily. PTES defines seven phases; NIST 800-115 groups the work into planning, discovery, attack, and reporting.
- PTES: https://www.pentest-standard.org
- NIST SP 800-115: https://csrc.nist.gov/pubs/sp/800/115/final
- OWASP Web Security Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
Pre-engagement and scoping
Scoping fixes what is in and out of bounds before any packet is sent. This phase produces the rules of engagement (RoE): in-scope IP ranges, domains, and applications; excluded systems; permitted testing windows; approved techniques; and emergency contacts.
Authorization must be explicit and in writing. Testing systems without documented permission is unlawful in most jurisdictions, so a signed authorization letter and a defined point of contact are prerequisites, not paperwork.
- Confirm asset ownership, especially for cloud-hosted and third-party systems that may require provider notification.
- Agree the testing perspective: black box, grey box, or white box.
- Define handling of sensitive data discovered mid-test and a stop condition for critical findings.
Reconnaissance and threat modeling
Reconnaissance gathers information about the target, split into passive (open-source intelligence, DNS, certificate transparency logs, public records) and active (port scanning, service enumeration, banner grabbing) collection.
Threat modeling turns that information into a prioritized plan. The tester identifies high-value assets, likely entry points, and the attack paths a realistic adversary would take, which keeps limited testing time focused on impactful issues rather than noise.
Vulnerability analysis, exploitation, and post-exploitation
Vulnerability analysis correlates discovered services and versions against known weaknesses and configuration flaws. Automated scanners are a starting point, not the finding; each candidate issue is manually validated to remove false positives.
Exploitation confirms that a vulnerability is real and reachable by safely demonstrating impact. Post-exploitation then measures what that access is worth: privilege escalation, lateral movement, and the sensitivity of data or systems reachable from the foothold.
- Prefer proof-of-concept over destructive actions; the goal is evidence, not damage.
- Record every command and timestamp so activity is attributable and reproducible.
- Map techniques to MITRE ATT&CK (https://attack.mitre.org) to give defenders detection context.
Reporting and remediation
The report is the deliverable clients act on. It pairs an executive summary written for non-technical stakeholders with detailed technical findings that each include a description, affected assets, reproduction steps, evidence, business impact, a severity rating, and a specific remediation recommendation.
Severity should be justified, commonly using CVSS (https://www.first.org/cvss/) adjusted for the client environment. A strong report also confirms scope coverage and offers a retest to verify fixes.
Related
FAQ
What is the difference between a vulnerability assessment and a penetration test?
A vulnerability assessment identifies and catalogs known weaknesses, typically at breadth and often scanner-driven. A penetration test goes further by validating and safely exploiting selected weaknesses to demonstrate real business impact and attack paths.
Which framework should a penetration test follow?
PTES and NIST SP 800-115 are the most common overarching methodologies, with the OWASP Web Security Testing Guide used for web application depth. They are complementary; many providers blend them and map findings to MITRE ATT&CK.
Is written authorization really required before testing?
Yes. Accessing systems without explicit, documented permission from the asset owner is unlawful in most jurisdictions. A signed authorization and defined rules of engagement are prerequisites for any legitimate test.