PTES
PTES, short for Penetration Testing Execution Standard, describes the phases a penetration test moves through: pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. It exists for a practical buyer's reason. With no declared method, two tests carrying the same name deliver work that cannot be compared, and whoever pays has no way of knowing which of the two they received.
PTES is a public execution reference, with no certification body and no seal. DM11 runs the test with the phases declared in the contract, delivers a report another professional can audit and, while you are still gathering quotes, helps you write the scope requirement that goes out to the market. For application coverage we use OWASP, and to describe the path taken we use MITRE ATT&CK.
Who runs the test
CEH, ethical hacker certified by EC-Council
CPTE, penetration testing engineering through AcadiTI
SYCP and SYWP, pentest and web application pentest through Solyd
Vulnerability analysis with a Qualys Certified Specialist
WHAT IT IS
PTES is a public standard that organises the execution of a penetration test into seven sections, in the order they happen. It lists no tools and no commands: it describes what has to happen at each stage and what comes out of each one. A separate technical guide sits alongside the standard, and the split is deliberate, because the structure of a test changes slowly and the technique changes every month.
Pre-engagement interactions set scope, authorisation, windows and rules. Intelligence gathering establishes what exists and what the world already knows about you. Threat modelling turns that into attack hypotheses that make sense for your business. Vulnerability analysis identifies what could be exploited. Exploitation confirms it in practice. Post exploitation measures how far someone could get once the first door is open. And reporting closes in two parts, an executive summary and a technical report, which is the split the standard itself defines.
Worth saying plainly, because it changes what you should expect from it. PTES appeared around 2009 and the site declares the current version as 1.0, promising a 2.0 with intensity levels per phase that was never published. The last time we checked, the most recent edit to any page on the wiki dates from December 2015, the technical guide is from 2012, and the change log over a 3000-day window shows no edits at all. Two pages listed in the site's own menu, FAQ and In the Media, are empty.
The sequence of phases still holds: a serious test still begins with a written agreement and ends with a report in two layers. What changed a great deal is what happens inside each phase, because cloud, federated identity, containers, APIs and language models did not exist in the same shape when the text was written. That is why DM11 uses PTES for the execution structure, OWASP for application coverage through the Top 10 and the ASVS, and MITRE ATT&CK to name and describe the path the attacker took.
Worth settling the expectation early. What the work produces is a report with scope, method, dates, findings with evidence and a remediation route, not a certificate. No body certifies a company or a report against PTES, and there is no seal to place on your site. The certifications that exist in this field belong to the people running the test rather than to the test itself. Where your customer or your auditor needs a document issued by an accredited third party, ISO 27001 or SOC 2 is what answers that, and the report produced here carries into those audits intact as evidence.
WHO USUALLY NEEDS IT
They share one root: somebody is about to pay for technical work they cannot assess on their own, and needs a way to verify it before and after.
Both say penetration test, both quote the same number of targets, and the price gap has no visible explanation. Almost always the difference sits in what each will actually do: one includes post exploitation and a retest, the other stops at a scan with review. Requiring the phases to be declared in writing makes the comparison possible, and the conversation moves to scope instead of discount.
A large customer running due diligence, a certification audit, PCI DSS with its annual test, Brazilian central bank rules with a minimum annual frequency and a requirement for independence. In those cases the report leaves your company and gets read by somebody who was not there. A report with no declared method forces that reader to take it on trust, and that is the point at which they ask for everything again.
The document runs to dozens of pages, has severity by colour and not one sentence saying how far anyone actually got. That happens when the work skipped threat modelling, exploitation and post exploitation, which are precisely the phases that separate a scan from a penetration test. The company paid for a pentest and received a vulnerability assessment under another name.
STORIES
We change our clients' names with the same confidentiality that will protect your company later. The names change; the pattern of the problems repeats. Where a client agrees, we give named references in a conversation.
Financial services
The technology team had two penetration testing proposals on the table, a wide price gap between them and one page of scope each. Both listed the same number of addresses and the same window. Nobody on the team could explain to the board why one cost so much more, and the natural instinct was to take the cheaper one and hope.
Before any testing, we wrote the scope requirement with the client, phase by phase, and it was that requirement that went to market: what intelligence gathering covers, whether threat modelling is delivered as a document, whether post exploitation is included, whether there is a retest after remediation, who executes and with what qualification, and what has to be in the report. We asked for both proposals to be resubmitted against it.
Both came back different from what they had been. It became visible that the cheaper proposal ended at confirming the flaw, with no post exploitation and no retest, and that the other included both. The choice stopped being about price and became about scope, decided by the board with the two columns on the same screen.
Manufacturing
The company had been buying penetration tests for three years and filing the reports for the audit. Every one carried long lists of flaws graded by severity, and none carried a single line about what an attacker could do with them. Remediation ran top to bottom down the list, with nobody knowing whether the items at the top were the ones that mattered.
We redid the work with the phases declared in the contract. We modelled threats from what the company cannot afford to lose, confirmed the flaws through exploitation and carried on into post exploitation, which was exactly the phase missing in the previous years. We described the path taken in MITRE ATT&CK language, so the infrastructure team could check detection afterwards.
Three flaws graded medium, taken in isolation and deferred two years running, chained together to give access to a share holding product designs. They reached the top of the remediation queue for the first time, and two high-severity flaws nobody could exploit stayed in the queue, with the reasoning written down.
Software as a service
In the previous test, source blocking shut out the tester's address early on and the work carried on that way until the window closed. The report concluded that the environment was resilient. The board celebrated, and the security team was left with the uncomfortable sense that nothing had really been tested.
We put into pre-engagement the decision nobody had taken: what happens when the defence blocks the person testing. We defined two windows, one with the blocking active, to measure what the defence genuinely stops, and one with the tester's address allowed through under control, to measure what sits behind it. Emergency contacts, hours and the stop criterion were written down before we started.
Both answers now existed separately. The defence handled generic attacks well, and behind it sat an exposed internal service no previous test had ever reached. The client stopped having to choose between good news and useful news, because they started receiving both.
HOW WE RUN IT
Every phase ends with something you can check without taking our word for it. That is the point of the method: a report another professional can audit is worth more than a report only its author understands.
The phase buyers most often skip and the one that protects both sides most. We define what is in and what is out, the approach, the windows, the stop criterion, how third parties such as cloud and connectivity providers are handled, and whether any testing that could affect availability is permitted. Formal authorisation and emergency contacts are recorded before the first packet.
Written scope, with what is in and what is out
Rules of engagement, windows and stop criterion
Formal permission to test and emergency contacts
An agreed approach for cloud, connectivity providers and other third parties
Delivery milestoneScope and authorisation signed, with no scope question left open.
We establish what exists and what is already public about your company, passively and actively, and turn that into attack hypotheses tied to what your business cannot afford to lose. Without this phase the test becomes a hunt for loose flaws, and the result is an unprioritised list nobody knows how to use.
The surface mapped, separating what is exposed from what is internal
Public information about the company and about people, where it is in scope
Attack hypotheses tied to what the business cannot afford to lose
Targets prioritised and agreed with you before exploitation begins
Delivery milestoneAttack hypotheses validated with your team, with priority agreed.
We identify what could be exploited and confirm in practice what genuinely can be, which is the difference between a suspicion and a fact. On applications, coverage follows OWASP through the Top 10 and the ASVS, because that is where PTES stops descending into detail and the yardstick the market recognises is a different one.
Flaws identified, with the identification method recorded
Confirmation through exploitation, with evidence of what was obtained
Application coverage through OWASP, with the requirement verified item by item
Immediate notice of any critical finding, without waiting for the final report
Delivery milestoneCritical findings reported the same day, with evidence and an initial recommendation.
Post exploitation measures how far someone could get once the first door is open, which is the information that changes investment decisions. The report comes in the two layers the standard itself defines, an executive summary and a technical report, with the path taken described in MITRE ATT&CK language, so your team can check detection and not only remediation.
Real reach demonstrated, with the chained path and what was left exposed
An executive summary for the board, free of jargon
A technical report with evidence, reproduction steps and remediation per finding
A retest of what was fixed, with the outcome recorded
Delivery milestoneReport delivered and retest completed, with every finding either closed or accepted in writing.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline turns into a promise and penetration testing scope varies widely. Pre-engagement is usually the short part in execution and the most decisive in the outcome. These are the three factors that move the clock most, and the first conversation already shows which one your company is in.
Counting addresses does not describe effort. A large range of repeated services moves quickly, and a single application with many user roles, complex business rules and third-party integrations consumes far more. It is the scope conversation that separates those two cases, and it happens before the proposal.
With no information at all, a good share of the time goes into intelligence gathering, and the result resembles what an external attacker would face. With partial information, or with access to documentation and source, the same hours go into hunting flaws rather than hunting doors. Both choices are legitimate and deliver different things, and the decision is recorded in pre-engagement.
An environment that can only be tested outside business hours, a system with a seasonal peak, an authorisation pending with a cloud provider and prior notice to a managed security provider move the calendar more than the technical work does. That conversation starts early, because it tends to be the slowest one in the whole project.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
There is none, neither for your company nor for the report. PTES is a public execution reference, with no certification body, no third-party audit and no seal. The certifications that exist in this field belong to the people running the test, such as CEH, CPTE and the Solyd pentest tracks. What you receive is a report with a declared method, and it is that report which goes to the audit, to the customer and to the regulator.
A short conversation already produces the phase-by-phase scope requirement your company can take to market. It serves for comparing suppliers on merit, and it serves for hiring the test from us knowing exactly what arrives at each stage.
Comparisons on this subject
See all 13 comparisons