PTES: The Penetration Testing Execution Standard
The methodology our engagements are built on — seven phases that make a penetration test repeatable, thorough and defensible.
How testing supports PTES
The Penetration Testing Execution Standard defines what a penetration test should actually involve, from the first scoping conversation to the final report. It exists because ‘penetration test’ means wildly different things from one vendor to the next. Building our engagements on PTES — alongside NIST SP 800-115 and OWASP for application work — is what makes our testing consistent regardless of who is testing, and defensible when an auditor asks how it was done.
What a test evidences
A single engagement produces evidence across these areas of PTES.
Pre-engagement & scoping
Clear scope, rules of engagement and objectives agreed before any testing begins.
Intelligence & threat modeling
Understanding the target and prioritizing the paths a real attacker would take.
Exploitation & post-exploitation
Manual, controlled exploitation that establishes genuine impact, not theoretical risk.
Reporting
An executive summary and technical detail structured so findings can be fixed and verified.
Evidence for every framework at once
Most organizations answer to several frameworks, not one.
We scope a single penetration test so its findings and evidence serve PTES alongside the other standards your auditors, customers and insurers ask about — instead of running overlapping engagements for each.
| Finding | Severity | Maps to |
|---|---|---|
| Cross-tenant data access | Critical | PTES |
| Over-privileged access | High | PTES |
| Weak session handling | Medium | PTES |
PTES testing, answered
Why does the methodology matter?
Because it is what separates a real penetration test from a scan with a cover page. A defined standard makes the work consistent, thorough and auditable, so results mean the same thing every time.
Do you follow other standards too?
Yes. PTES is the backbone, with NIST SP 800-115 for technical execution and OWASP’s testing guides for application work, plus MITRE ATT&CK for mapping exploitation.
Other frameworks we test against
SOC 2
Independent testing evidence for the Common Criteria and the vendor questionnaires that gate enterprise deals.
PCI DSS 4.0
Requirement 11.4 internal and external testing, plus segmentation validation where you rely on it.
HIPAA
The technical half of a Security Rule risk analysis for providers, payers and digital health.
Testing for PTES?
Tell us the framework and the deadline. We scope to the evidence your assessor needs.