The PTES methodology against the six phases a B-52 engagement runs, the NIST four-phase structure underneath both, and the OWASP list that belongs to each class of target. Every citation on this page carries the edition it was read at and the date it was read.
The register
A standards page is read by the person doing the checking, which is the reason it is built as a register and not as a badge wall. Editions move at their own speed: the web Top 10 stood at its 2021 list until January 2026, while the API list has been at its 2023 edition throughout. Quoting either from memory produces a scope document that names the wrong document.
Terms used below without definition are defined once in the glossary, and the per-class detail sits on the coverage class pages, each of which repeats the standards for its own class.
Deliberately excluded
PTES methodology
PTES divides an engagement by what the tester is doing at that moment. Our six phases divide it by what the run produces and where a gate sits, so the two are different decompositions of the same work and not translations of each other. Anyone presenting them as an exact mapping is presenting a tidier picture than the standard supports.
Four of the seven correspond closely: intelligence gathering, vulnerability analysis, exploitation and reporting. A fifth, threat modelling, sits inside our planning phase alongside work PTES keeps in pre-engagement. Of the remaining two, one sits outside our six entirely and one folds into a phase of ours behind an approval gate — and one of ours has no PTES phase facing it. PTES itself is cited as current, without an edition year.
| PTES phase | Where the same work sits here | What does not line up |
|---|---|---|
| Pre-engagement interactions | Before the six begin | Scope, targets and the written authorisation are settled and signed before a run starts, which makes this a gate on the engagement and not a phase inside it. |
| Intelligence gathering | Discovery, the first phase | The closest correspondence of the seven. What answers is established before anything is judged against it. |
| Threat modelling | Planning, the second phase | Planning also fixes the movement boundary and the three approval gates, which PTES treats as pre-engagement business. |
| Vulnerability analysis | Scanning, the third phase | Ours stops where a candidate is still only a candidate. Confirmation belongs to the phase after it, so nothing is reported out of this one. |
| Exploitation | Exploitation, the fourth phase | Direct correspondence, with the first approval gate standing in front of anything destructive or state-changing. |
| Post exploitation | Exploitation, the fourth phase | Not a separate phase here. Persistence and movement past the entry host wait for written approval, and where that approval is not given the run stops at the foothold and the report says where it stopped. |
| Reporting | Reporting, the fifth phase | Direct correspondence, with the exploit artefact on each finding: request, response, and the steps to reproduce it. |
| No PTES phase | QA, the sixth phase | PTES has no counterpart for it. QA runs on the finished report, before that report reaches you, which is the ordering the whole model turns on. |
The seven PTES phases against the six a B-52 engagement runs
Pre-engagement interactions
Intelligence gathering
Threat modelling
Vulnerability analysis
Exploitation
Post exploitation
Reporting
No PTES phase
NIST SP 800-115
Final in September 2008, and neither withdrawn nor superseded. Age and staleness are not the same property: where a guide has not been replaced, reaching for a document with a fresher date on the cover is the error and not the correction. Read 2026-09-13.
Its four-phase structure is the skeleton PTES and our six both hang on, which is why a report can cite all three without contradicting itself.
Ours: discovery and planning
Rules of engagement, scope and approvals are agreed, and no testing happens inside it. Our first two phases carry that work, and the authorisation is signed before discovery sends a packet.
Ours: discovery and scanning
Enumeration of what is reachable, then the vulnerability analysis that turns what answered into a list of candidates worth attacking.
Ours: exploitation
Candidates are verified by exploiting them. SP 800-115 draws a loop from attack back to discovery, because a successful attack can expose hosts the first pass could not see, and a run that finds one follows that loop.
Ours: reporting and QA
SP 800-115 runs reporting alongside the other three phases instead of bolting it on at the end. Our sixth phase then puts QA on the finished report before you see it.
OWASP, by class
OWASP publishes a separate set for each class of target, and those sets move on separate schedules. Two things follow: cite the list that belongs to the class being tested, and cite it at the edition current for that list, not the edition current for a neighbouring one.
| Standard | Version | Read | What it carries here |
|---|---|---|---|
| OWASP Top 10 | 2025 edition | 2026-09-13 | The category a web finding is reported under, so the report sorts the way your developers already sort their backlog. |
| It superseded the 2021 list in January 2026. SSRF is absorbed into A01 Broken Access Control and A07 is renamed Authentication Failures, so a report still written to the 2021 categories files SSRF under a heading the current list no longer carries, and names A07 by a title that has changed. | |||
| OWASP WSTG | v4.2, current stable | 2026-09-13 | The test procedure behind each check, which is what lets your team reproduce a finding from the same steps the run used. |
| v5.0 is in development and is not cited until it is stable. | |||
| OWASP ASVS | 5.0.0, May 2025. 17 categories | September 2026 | The verification requirement a finding maps to, and the level a scope is agreed against before the run starts. |
| The first major release in six years. 4.0.3 is superseded. | |||
Web application standards, their editions, and what each carries in a report
OWASP Top 10
It superseded the 2021 list in January 2026. SSRF is absorbed into A01 Broken Access Control and A07 is renamed Authentication Failures, so a report still written to the 2021 categories files SSRF under a heading the current list no longer carries, and names A07 by a title that has changed.
OWASP WSTG
v5.0 is in development and is not cited until it is stable.
OWASP ASVS
The first major release in six years. 4.0.3 is superseded.
| Standard | Version | Read | What it carries here |
|---|---|---|---|
| OWASP MASVS | v2.1.0 | September 2026 | The requirement a mobile finding maps to. MASVS-PRIVACY arrived at v2.1.0, so a privacy defect now has a home in the standard instead of a note appended to the report. |
| OWASP MASTG | v2.0.0 | September 2026 | The test procedure for a signed release build: what is checked on the artefact you publish, and how. |
| Verification levels became MAS Testing Profiles at v2.0.0. “MASVS Level 2” is a retired construct, so a scope still written to it is written to something the standard no longer contains. | |||
Mobile application standards, their editions, and what each carries in a report
OWASP MASVS
OWASP MASTG
Verification levels became MAS Testing Profiles at v2.0.0. “MASVS Level 2” is a retired construct, so a scope still written to it is written to something the standard no longer contains.
Where the year goes wrong
The web list moved to a 2025 edition and the pull is to make the API row match it. The API Security Top 10 is still at its 2023 edition, which is the only major update it has had since 2019, so a scope document citing a 2025 or 2026 API list names a document nobody has published. The mistake only ever runs in that one direction.
| Standard | Version | Read | What it carries here |
|---|---|---|---|
| OWASP API Security Top 10 | 2023 edition | 2026-09-13 | The category each API finding is reported under. Its leading entries are authorisation failures, which is why an API assessment turns on whether a second credential is in scope. |
| 2023 is the current edition and the only major update since 2019. There is no 2025 or 2026 edition, and citing a year that matches the web list would cite a document that does not exist. | |||
| OWASP ASVS | 5.0.0, May 2025 | September 2026 | Carried across from the web set for the verification requirements an API shares with a web application. |
| OWASP WSTG | v4.2 | 2026-09-13 | Carried across for session handling, input handling and transport, which an API is tested for the same way a web application is. |
API standards, their editions, and what each carries in a report
OWASP API Security Top 10
2023 is the current edition and the only major update since 2019. There is no 2025 or 2026 edition, and citing a year that matches the web list would cite a document that does not exist.
OWASP ASVS
OWASP WSTG
| Standard | Version | Read | What it carries here |
|---|---|---|---|
| OWASP Top 10 for LLM Applications | 2025 edition, 12 March 2025. LLM01 to LLM10 | 2026-09-14 | The category each finding in an LLM application is reported under, covering what the application retrieves and trusts, what it renders, and which tools it can be made to invoke. |
| MITRE ATLAS | Current release, no version pinned here | September 2026 | The adversary technique a finding is mapped to where the defect is in how an application uses a model. |
| ATLAS publishes on a rolling cadence, so the report names the release each finding was mapped against and this page names none. The band below sets out why that is the safer of the two options. | |||
| NIST AI RMF | AI 100-1, 26 January 2023, with the Generative AI Profile AI 600-1, 26 July 2024 | September 2026 | The function a finding is reported against where the assessment is filed into an AI risk programme. |
| AI 100-1 is under revision and no version 2.0 has been published, so AI 100-1 is what a report can cite today. | |||
LLM application standards, their editions, and what each carries in a report
OWASP Top 10 for LLM Applications
MITRE ATLAS
ATLAS publishes on a rolling cadence, so the report names the release each finding was mapped against and this page names none. The band below sets out why that is the safer of the two options.
NIST AI RMF
AI 100-1 is under revision and no version 2.0 has been published, so AI 100-1 is what a report can cite today.
On the finding itself
Three citations belong to no single class. Two of them sit on every finding in every one of the eleven coverage classes; the third appears only where a finding is one step of something longer. What each of them is doing on the page is set out beside it.
Each finding also carries the artefact that proves it. Validation and proof sets out what that artefact contains and what the fully autonomous model adds to it before a finding is reported.
Two deliberate omissions
Two citations above carry no edition, and in both cases a number printed here would be a wrong number within weeks of the page being published. Pinning one anyway would buy the appearance of rigour at the cost of the thing itself.
Both are pinned where pinning does the work. The report names the release or the benchmark version each finding was mapped against, on the finding, and a report is fixed at the date it was signed while a page is republished whenever somebody edits it.
Where a finding is filed
Findings are mapped to the control or criterion a framework names, so an auditor can read the report against the clause they are testing. What the mapping produces is evidence for that auditor to test; the certificate or attestation at the end of it is the appointed certification body’s to issue, on its own engagement.
Each framework below has its own page, and so do the Indian instruments a report is filed against: CERT-In empanelment, SEBI CSCRF, the RBI Directions 2026 and DPDP. The compliance index lists all of them, and each page cites the instrument it rests on with the date that instrument was read.
| Framework | Instrument and version | Read | What findings map to |
|---|---|---|---|
| PCI DSS | v4.0.1 | September 2026 | Requirement 11.4.3, external penetration testing at least once every twelve months and after any significant infrastructure or application upgrade or change. Requirement 6.2.3, bespoke and custom software reviewed prior to release into production. |
| The v4.x requirements have been in force since 31 March 2025. | |||
| PCI SSC penetration testing guidance | v1.1, September 2017 | September 2026 | The scoping and methodology expectations an assessor reads a penetration test report against. |
| ISO/IEC 27001 | 2022, with Amendment 1:2024 | September 2026 | Annex A controls, 93 of them in four categories. Amendment 1:2024 carries the climate action changes to clause 4.1. |
| SOC 2 | Trust Services Criteria, the 2017 set with the 2022 revised points of focus | September 2026 | CC7.1 vulnerability monitoring and CC4.1 evaluations, as evidence a service auditor can read and test. |
| GDPR | Article 32(1)(d) | September 2026 | A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures. |
| HIPAA Security Rule | 45 CFR 164.308(a)(1)(ii)(A) and 164.308(a)(8), in force | September 2026 | The risk analysis, and the periodic technical and non-technical evaluation. |
| The NPRM published on 6 January 2025 would add six-monthly vulnerability scanning and annual penetration testing. It is a proposed rule: OMB’s Unified Agenda (RIN 0945-AA22) targets July 2027 for a final one, so a filing made today rests on the two sections named above. | |||
| CIS Benchmarks | No version pinned here, by decision | September 2026 | The configuration baseline a cloud finding is measured against. The report names the benchmark and the version the run worked to. |
Frameworks, the instrument cited, and the control findings are mapped to
The v4.x requirements have been in force since 31 March 2025.
PCI SSC penetration testing guidance
The NPRM published on 6 January 2025 would add six-monthly vulnerability scanning and annual penetration testing. It is a proposed rule: OMB’s Unified Agenda (RIN 0945-AA22) targets July 2027 for a final one, so a filing made today rests on the two sections named above.
CIS Benchmarks
Name the framework the report has to satisfy and the class of target it covers, and the scope that comes back names the standards the run will be worked against. One scan is one application or target, from $500, for a web application, a mobile app, an API, a thick client or a secure code review; anything outside those five is settled on the call.