A standard tells you what to test. It does not tell you where your product breaks. This is what PTES, OWASP WSTG, the OWASP API Security Top 10, OWASP ASVS and NIST SP 800-115 actually cover, which parts matter when the target is a SaaS application or an API, and which parts exist mainly so a report can say it followed something.
Buyers often ask which methodology a penetration test follows, and it is a fair question. A named standard gives a test a shared vocabulary, a baseline of coverage and a way for someone outside the engagement to check the work. What it cannot do is replace knowing how a specific product decides who is allowed to do what. The honest answer to “which standard do you follow” is usually several, each doing a different job.
PTES: The Penetration Testing Execution Standard
PTES was written by a group of practitioners and published as a public wiki. It describes a penetration test in seven sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting.
What still holds up is the shape of an engagement. The pre-engagement section is a good checklist for scope, rules of engagement, emergency contacts and what happens when testing turns up something serious halfway through. The split in its reporting section between an executive summary and a technical report is still how a useful report is built.
It is worth being plain about its status. The official PTES site was last edited in August 2014, and its technical guidelines page in April 2012. It has not been meaningfully updated in over a decade. The technical guidance reflects the network and infrastructure testing of that era and has little to say about APIs, single page applications, OAuth, multi tenant data models or cloud identity. Citing PTES for the structure of an engagement is reasonable. Citing it as evidence that a modern SaaS application was tested thoroughly is not.
The checkbox version is a web application report that walks through all seven phases, complete with intelligence gathering and post exploitation sections that say nothing specific about the product.
OWASP WSTG: The Web Security Testing Guide
The OWASP Web Security Testing Guide is the closest thing web application testing has to a shared test catalogue. Version 4.2 is the current stable release and version 5.0 is in development. Every test has an identifier. Authorization testing, for example, includes WSTG-ATHZ-02 for bypassing the authorization schema, WSTG-ATHZ-03 for privilege escalation and WSTG-ATHZ-04 for insecure direct object references.
For SaaS work the chapters that matter most are authentication, authorization, session management and business logic. The identifiers earn their place in a report, because a developer can look up exactly what was tested and why, and they are a quick way to spot coverage gaps before an engagement ends.
The theatre version is a spreadsheet with every WSTG identifier marked pass, fail or not applicable. A test marked pass tells you a check was run. It does not tell you which roles, which objects or which endpoints were tried, and for authorization that is the whole question.
OWASP API Security Top 10
The 2023 edition lists the ten API risks OWASP considers most significant, from API1, broken object level authorization, to API10, unsafe consumption of APIs. Three of the ten are authorization failures: broken object level authorization, broken object property level authorization and broken function level authorization. API6, unrestricted access to sensitive business flows, is business logic under another name.
For SaaS and API testing this is the most relevant document of the five, because it is organised around how APIs fail rather than around a testing process. It is also the easiest way to explain a finding to an engineering team. Broken object level authorization, the same flaw as IDOR, is the first thing I check on any API.
It is an awareness document, not a methodology. A test that says it “covered the OWASP API Top 10” has told you it had ten headings. The list ranks categories of risk; it does not describe the specific way your API fails.
OWASP ASVS: The Application Security Verification Standard
ASVS is a list of security requirements rather than a list of tests. Version 5.0, released in May 2025, has around 345 requirements across 17 chapters and three verification levels, from a baseline at Level 1 to the most demanding at Level 3.
It is most useful at either end of a test. Before, it helps agree what the application is supposed to enforce, so findings can be measured against something written down. After, it turns a finding into a requirement the fix can be checked against, so a retest confirms the requirement rather than replaying the single request that exposed the problem. My sample security review shows coverage informed by ASVS alongside WSTG and the API Top 10.
The theatre version is a time boxed penetration test presented as ASVS Level 2 verification. Properly verifying a few hundred requirements needs access to design and code, and a black box test lasting a week or two does not do that.
NIST SP 800-115
NIST Special Publication 800-115, the Technical Guide to Information Security Testing and Assessment, was published in September 2008 and has not been revised since. It describes assessment at a programme level, in planning, execution and post execution phases, and treats penetration testing as four stages: planning, discovery, attack and reporting, with reporting running alongside the other three.
Its value is governance language. Its guidance on rules of engagement, approvals and the handling of test data maps well onto what regulated buyers expect to see written down, and it is a recognised reference when a security questionnaire asks for testing aligned to a framework.
It predates most of what a SaaS application is made of. It says nothing specific about APIs, tenant isolation or modern identity, and it explicitly leaves physical and social engineering testing out of scope. It belongs in the scoping document, not the test plan.
How the Standards Fit Into One Engagement
Used together, each standard does one job well:
- Scope and rules of engagement: PTES pre-engagement and the NIST SP 800-115 planning stage.
- What the application should enforce: OWASP ASVS.
- Coverage and a shared vocabulary for findings: OWASP WSTG identifiers.
- Prioritising API risk: the OWASP API Security Top 10.
- Reporting: the PTES executive and technical split, with each finding mapped back to WSTG and ASVS.
That is roughly how my penetration testing methodology uses them, and API security testing leans hardest on the API Top 10 and the WSTG authorization and business logic chapters.
What No Standard Can Tell You
Every standard above will tell you to test authorization. None of them will tell you that the export endpoint checks the session and not the role, so any signed in user can download the whole account as a CSV. That comes from knowing the product. A few more of the same kind:
- An invite flow that takes the new member’s role from the request body, so an invited viewer can accept as an admin.
- A tenant ID read from the token in one service and from the URL in another, so the second service trusts whichever tenant the caller names.
- A soft deleted record that vanishes from the interface but is still returned when requested by its ID.
- A scheduled job that runs later with the permissions of whoever created it, long after that person lost access.
- A GraphQL field that is protected on the top level query but not when reached through a nested relation.
Finding these means mapping roles, objects and tenant boundaries first, then trying every combination that matters with two or more real accounts. The checklists I start from are public: the API security checklist, the access control testing checklist, the SaaS security checklist and the GraphQL security checklist.
Standards make a test comparable and auditable. Judgment is what makes it find something.
Frequently Asked Questions
What is the Penetration Testing Execution Standard?
The Penetration Testing Execution Standard, or PTES, is a community written framework that describes a penetration test in seven phases, from pre-engagement interactions through to reporting. It is most useful for structuring an engagement and its report, and much less useful for deciding what to test in a modern web application or API.
Is PTES still maintained?
Not in any meaningful way. The official PTES site was last edited in August 2014 and its technical guidelines in April 2012, so its engagement structure is still sound but its technical content predates most modern SaaS and API architecture.
Which standard should a SaaS penetration test follow?
No single one. A good SaaS test uses OWASP WSTG for coverage, the OWASP API Security Top 10 for API risk and ASVS to define what a fix must satisfy, with PTES or NIST SP 800-115 for scoping and rules of engagement, then goes beyond all of them on the product’s own authorization logic.
