PTES: the standard that describes how a penetration test runs

PTES splits a test into seven phases that follow one another from the first meeting to the handover of the report. The split is useful mainly as a completeness check: if a phase is missing from a proposal, it usually means no time has been budgeted for it.

The phases are not equally long and their ratio differs with the subject of the test. On an external perimeter, intelligence gathering eats a lot of the time; on an application behind a login it is vulnerability analysis and exploitation instead.

In an engagement the seven phases show up at three visible points: agreeing on the scope at the start, communication during the test when a finding can’t wait, and the report at the end. The rest runs below the surface and the client sees it only in the structure of the deliverable.

For the client the first phase matters most of all. The rules of engagement, meaning what may be tested, when, and who to call if something breaks, decide the course of the work more than the choice of tools. How a specific engagement is put together from this is described on our page for penetration testing of applications and infrastructure.

Practically nobody runs a test by the letter of PTES, and saying so is more honest than claiming conformity. The most common departure is exploitation and post-exploitation merging into one: as soon as the tester confirms a way in, they carry straight on into depth, because on an engagement with a fixed scope both happen in a single step.

The second departure is threat modeling. In the standard it is a separate phase with its own output; on a normal engagement it turns into an hour of the scoping call, because the scope is set in advance. The third is the timing of reporting: a Critical finding is reported immediately, not in the last phase.

The methodologies don’t compete; each answers a different question. PTES says how a test should run, the OWASP documents say what to look for in an application and what requirements it should meet, and NIST gives a general framework for assessment.

In practice they are combined: the course of the work under PTES, the content of a web test under WSTG, and the requirements the result is measured against under ASVS.

PTES assumes a test with a defined scope and a known target. In a scenario-based operation, where the point is to find a path to a predetermined asset and the reaction of the defenders is measured too, the phases interleave and loop back: first access is followed by more information gathering, then more exploitation.

For that type of engagement a step-by-step description of the attack works better, the way a cyberattack simulation uses it, or mapping the techniques onto MITRE ATT&CK. Seven linear phases stop matching reality there.

PTES came out of a discussion among a handful of consultants in early 2009 about what value penetration tests actually have, and its text has barely changed since. It still calls itself version 1.0 and promises a version 2.0 that never appeared. It has no publisher in the shape of an organization that would revise it, so new versions don’t come out the way they do on OWASP projects. It shows in the infrastructure too: the official site of the standard still runs over unencrypted HTTP and doesn’t answer on the HTTPS port at all. That doesn’t make it less usable, but it is worth knowing.

The structure of a test ages slowly. What ages are the specific tools and commands in the technical appendices, because those match the time the text was written. PTES therefore governs the course of the work, not the choice of tools.