OWASP WSTG vs PTES: which one should your web application test cite?
The OWASP Web Security Testing Guide is the catalog of web application tests a tester runs, while the Penetration Testing Execution Standard is the process that governs the whole engagement from pre-engagement through reporting. If an application test is on your shortlist and the statement of work needs a named methodology, the two answer different questions, so the choice is rarely one or the other. WSTG tells the tester what to check in an application, grouped into 12 categories from information gathering through authentication, authorization, session management, input validation, business logic, client-side and API testing. PTES tells the engagement how to run, including the rules, scope, intelligence gathering and reporting around those checks.
Choose WSTG alone when the buyer already has a clear engagement process and needs assurance that the application itself was tested against a broad, current set of web-specific cases. Choose PTES alone when the main gap is in how the engagement is governed, for example scope control, escalation and reporting discipline, and the testers already know web testing. Require both when the test is a formal application assessment, since the SOW should name WSTG for the test cases and PTES for the process, and it should state which WSTG version applies. The WSTG v4.2 release is dated 3 December 2020 according to the project's GitHub releases, so confirm with your provider whether a newer version is in use and what changed.
NIST SP 800-115 says NIST does not endorse one methodology over another and notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. That position suits this decision: the SOW should not rely on a single methodology as proof of quality. Ask the provider to map each WSTG category to the planned test activities, and to state how the PTES phases, including rules of engagement, are documented. Confirm the rules of engagement template and the depth of testing in writing before work starts, because the methodology name alone does not define either.
How WSTG and PTES differ on scope, method and output
This table compares what OWASP WSTG and PTES each cover, how they structure a test, what the buyer receives, and what drives cost and effort. Read it as a checklist for deciding which reference belongs in an application test statement of work. Confirm current versions and license terms with each project before citing them.
| Dimension | OWASP WSTG | PTES |
|---|---|---|
| Primary purpose | A catalog of web application test cases organized into 12 categories, from information gathering through business logic, client-side and API testing | A general process for running a penetration test across seven main sections, from pre-engagement interactions through reporting |
| Scope of coverage | Web applications and their APIs, tested item by item against documented test cases | Any engagement type, from a routine web or network test to a full red team engagement, with scope set during pre-engagement |
| Method at buyer level | Shows which technique to apply to each test case; OWASP says no single technique is enough and recommends a mix weighted toward early development | Defines the sequence a tester follows from scoping and intelligence gathering through exploitation and post exploitation |
| Engagement start | Assumes the application is the target; testers select cases that fit the app | Starts with pre-engagement interactions that set rules, goals and expected adversary behavior |
| What the buyer receives | Test results mapped to WSTG test case identifiers, so coverage can be checked case by case | A report covering the reporting section of the engagement; format depends on the provider and the agreed statement of work |
| Version and status | v4.2, released 3 December 2020 per the project's GitHub releases; confirm whether a newer version is current before citing | Described on its main page as v1.0, with a planned v2.0 that would add intensity levels; confirm the status of v2.0 with the project |
| License terms | Confirm current license terms with the OWASP project before citing or embedding the guide in your own documents | Confirm current license terms with the PTES project before citing or embedding the standard in your own documents |
| Cost and effort drivers | Number of test cases in scope, application complexity, whether the tester has source or documentation, and how many APIs and client-side components are included | Depth of intelligence gathering, number of phases agreed in scope, and whether the engagement includes threat modeling and post exploitation |
| What to require in a statement of work | Named WSTG version and the test case categories in scope | Named PTES version and the sections in scope, with rules of engagement agreed in pre-engagement |
What a WSTG-led test finds and misses compared with a PTES-led test
OWASP WSTG and PTES answer different questions. WSTG tells a tester what to examine inside a web application, while PTES tells the engagement what phases to run from first contact to reporting. The cards below show where each one reaches deep, where it stops, and what a buyer should ask for so the gaps are covered by something else.
Application logic coverage in WSTG
WSTG groups web application testing into 12 categories, from information gathering and configuration management through authentication, authorization, session management and input validation, to business logic, client-side and API testing. For a banking or claims portal, the business logic and authorization categories are where a WSTG-led test spends the most judgment, since flaws such as skipped approval steps or horizontal access between accounts rarely appear in a scanner's output. Ask the tester which WSTG test IDs were executed and which were marked not applicable, with the reason for each.
Pre-engagement scope in PTES
PTES begins with pre-engagement interactions, where scope, rules of engagement, contacts and goals are agreed before any testing starts. WSTG assumes a web application is already defined and says little about how that boundary is set. A PTES-led statement of work makes the application's hosts, accounts, third-party integrations and out-of-scope production functions explicit, which prevents a web test from quietly drifting into a network engagement or the reverse.
Threat modeling and its gap
PTES includes threat modeling as a named section, so the adversary profile and likely attack paths are chosen before exploitation. WSTG also treats threat modeling as one of the four techniques it compares, but its test catalog concentrates on what to check in the application itself. A WSTG-only test can therefore miss attack paths that run through the identity provider, the hosting network or a supporting service unless the threat model names them and the team tests them.
Post-exploitation outside WSTG
PTES covers post exploitation, meaning what an attacker can reach after a foothold: lateral movement, privilege escalation and access to sensitive data across systems. WSTG does not give a comparable sequence for what happens once a web flaw yields access to a host or database. Where a web finding leads to a server or internal network, ask whether the test was extended into a post-exploitation phase or whether the finding was reported at the application level only.
Application tests missing from PTES
PTES describes its phases and technical guidance in general terms, from routine web application tests to full red team engagements, but it does not enumerate application test cases the way WSTG does. A tester who follows only PTES may check a login form without testing session fixation, cookie attributes or API object-level authorization. Require the statement of work to name the WSTG categories or equivalent test cases for any application in scope.
No single technique is enough
OWASP's own guidance says no single technique is enough and recommends a mix of manual inspections and reviews, threat modeling, source code review and penetration testing, with more weight on early development phases. A WSTG-led test run only at release time will miss design flaws that a threat model or code review would catch earlier. Ask the provider how the web test is paired with code review or ASVS verification and when each activity runs in your delivery cycle.
How testers combine WSTG and PTES on one web engagement
PTES supplies the frame and WSTG supplies the test cases. On a web engagement, PTES sets the seven phases, from pre-engagement interactions through reporting, and the rules of engagement, scope and reporting structure that govern them. Inside the vulnerability analysis and exploitation phases, the tester works through the WSTG categories that match the application: information gathering and configuration management first, then authentication, authorization, session management, input validation, business logic, client-side and API testing. Practically, the statement of work names PTES as the process and WSTG v4.2 as the test catalog, and the test plan maps each WSTG category to the in-scope applications and roles. Ask the provider to show which WSTG test IDs it will execute and which it will mark not applicable, with a reason for each.
The OWASP guidance itself does not treat penetration testing as sufficient on its own. It compares manual inspections and reviews, threat modeling, source code review and penetration testing, and states that no single technique is enough, recommending a mix that puts more weight on early development phases. For a buyer, this means the strongest application test pairs the PTES engagement with earlier evidence such as design review, threat models and code review, not only a late-stage black-box run. OWASP ASVS 5.0.0 points the same way, strongly encouraging documentation or source code led (hybrid) penetration testing over testing without documentation or source. Confirm whether the provider will receive architecture documents, API specifications, role matrices and read-only source access before testing begins, and whether those inputs change the WSTG categories it selects.
When writing the statement of work, require WSTG v4.2 as the application test reference and PTES as the engagement process, and name both in the deliverables. Specify the test accounts per role, the environment (production or staging), and whether authenticated testing is included, because WSTG authorization and session tests depend on them. Ask for a report that maps each finding to its WSTG test ID and to the PTES reporting section, so your remediation team and your auditors can trace coverage. Confirm the exact WSTG version the provider uses against the OWASP WSTG releases page, since test IDs and categories can change between releases.
Which reference to require in a statement of work for an application test
When the application already has a defined test plan, the OWASP Web Security Testing Guide is usually the natural reference to write into the SOW. It is a catalog of web application test cases organized into categories, so a tester can map each planned case to a concrete check and report coverage against named items. The guide also says no single technique is enough, so the SOW should name the mix you expect, such as source code review or threat modeling alongside penetration testing. Confirm with the vendor which WSTG version the tester uses, since the current release line is documented on the project's GitHub releases page.
- Test case mapping: Require the report to reference WSTG test IDs for each area tested, so results can be compared across releases.
- Categories in scope: List which of the WSTG categories, such as authentication, authorization, session management or API testing, are in and out of scope.
- Authenticated roles: Name each role (for example, customer, support agent, administrator) and how test accounts are provisioned and removed.
- Environments: State whether testing runs in staging, production or both, and which data sets may be touched.
- Rules of engagement: Adapt the NIST SP 800-115 Appendix B template for contact points, testing windows, stop conditions and data handling.
Before signing, check that the SOW names the WSTG version, the test accounts and the environment, and that the tester can show how each planned case was covered.
When the engagement must show how an attacker would move through the application, the PTES reference fits better as the process frame. PTES runs from pre-engagement interactions through intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting, and its main page describes a range that extends to full red team engagements. It is a process standard, so the SOW must add the detail that PTES leaves to the engagement: the adversary profile, the objective and the limits on what the tester may do after initial access. A planned PTES v2.0 would add intensity levels for stating adversary sophistication, but the supplied material describes it only as planned, so confirm its status before relying on it.
- Adversary profile: Describe the expected attacker capability and the objective, such as access to customer records, in the SOW rather than leaving it to the tester.
- Pre-engagement terms: Record the rules of engagement, emergency contacts and what happens if the tester gains access to live customer data.
- Post-exploitation limits: Define which lateral movement, persistence and data extraction actions are allowed, and how they are stopped.
- Threat modeling input: Provide architecture diagrams, trust boundaries and data flows so the threat model reflects the real design.
- Reporting format: Specify whether the deliverable is a findings report, a narrative attack path or both.
Before signing, confirm that the SOW states the adversary profile and the post-exploitation boundaries, since PTES does not supply them.
When a regulated program asks for a named methodology, the SOW should cite the reference the program requires, and the supplied facts do not show any regulator requiring the OWASP WSTG or PTES by name. Under DORA, Article 25 lists penetration testing and related tests, and Article 26 covers threat-led testing for entities designated by their competent authority, but neither article names these two references. Where the program needs a control-based anchor, NIST SP 800-53 control SA-11 covers developer testing, including dynamic code analysis and interactive application security testing, and can be cited alongside the methodology. Ask the regulator or assessor which reference they accept before writing the SOW.
- Required reference: Cite the methodology the regulator or internal policy names, and use WSTG or PTES as the working detail beneath it.
- Control mapping: Reference the control IDs the assessor will check, such as SA-11 for developer testing, and state which safeguards the test evidences.
- Independence: Require that the tester be independent of the development team when the program calls for it.
- Evidence package: List the artifacts the assessor expects, such as scope letters, tool versions, tester qualifications and retest results.
- Retest and closure: Define how fixed findings are retested and who signs off on closure.
Before signing, ask the assessor or regulator to confirm the named reference in writing, because DeployOpen prepares evidence but does not issue audit reports or certifications.
What you receive from a WSTG-based and a PTES-based report
This table compares what a report looks like when the test is organized around the OWASP WSTG test catalog versus the PTES phases and reporting section. Read it to judge which structure matches your audit trail, your remediation workflow and your application scope. Deliverables depend on the written scope, so ask for a sample report and a test-case index before you sign.
| Report element | WSTG-organized report | PTES-organized report |
|---|---|---|
| Organizing structure | Results grouped by WSTG category, such as information gathering, authentication, authorization, session management and input validation | Narrative organized around PTES phases: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting |
| Test case coverage | Per-test-case status that shows which WSTG items were executed, not applicable or not tested | Coverage described in the engagement narrative and scope; per-case tracking depends on the provider's own methodology |
| Findings presentation | Findings linked back to the WSTG test ID where they were identified, which helps a repeat test confirm the same checks ran | Findings written up with attack path, impact and evidence, often read as an engagement story for management and technical staff |
| Evidence an assessor can trace | Test-case index that maps each check to evidence, useful when an auditor asks which web checks were performed | Phase records and rules of engagement that show how the test was scoped and run, useful when an auditor asks how the test was governed |
| Gaps to watch | Checks outside the web application layer, such as network services or cloud configuration, may be absent unless added to scope | Test-case depth varies by tester, so confirm which web checks were attempted and how they were recorded |
| What to request before signing | Sample report and the full test-case index with status values for each WSTG category | Sample report and the scope document showing which PTES phases are in the deliverable and how each is reported |
What drives the cost and effort of each approach
Both approaches are priced and staffed from the same handful of inputs: how much surface is in scope, how the tester gets access, and how often the work repeats. Read the cards as a checklist to put in a statement of work, so that a quote for a WSTG-led or PTES-led application test can be compared line by line.
Applications and roles in scope
Each application, each user role and each trust boundary between them multiplies the test cases. A WSTG-based test walks authorization checks per role, so five roles on one application costs more effort than one role. Ask the provider to list applications, roles and environments in the scope document, and to state which roles are tested with which privileges. Scope changes after kickoff are the most common source of unplanned effort.
API surface
Every endpoint, schema, version and authentication scheme adds work that a page-by-page review does not cover. WSTG includes an API testing category, so ask whether the quote counts endpoints, GraphQL schemas or only the web front end. An application with a large API and a small UI can cost more to test than the reverse, and the fee should show the API count explicitly.
Authenticated versus unauthenticated testing
Unauthenticated testing covers what an outsider can reach. Authenticated testing, with test accounts for each role, covers session handling, access control and business logic, which is where most application findings sit. Authenticated work usually needs more setup and more retest time. Confirm in writing how many accounts the client will supply, whether MFA or SSO must be bypassed for testing, and who owns that setup.
Source code access
Access to source code and design documents lets testers verify controls directly, which OWASP ASVS 5.0.0 strongly encourages for hybrid testing. The cost moves from discovery to review time, and it is usually one-time per release line. Ask whether the client can provide read-only repositories, architecture diagrams and data flow notes before testing starts, and who pays for the review hours.
Retest cycles
The first test is the one-time cost. Retests after fixes recur and are often priced separately, so a plan that retests every release, or after every critical finding, carries a steady cost. CIS Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually, and Safeguard 18.4 asks that detections be validated after each test. Ask for the retest allowance, the window for verifying fixes, and the cost of testing after architecture changes.
Reporting depth
A findings report with reproduction steps for each WSTG test case costs more than a summary with ranked issues. PTES reporting covers the engagement narrative, the methodology and the remediation plan, which adds writing time. Ask the provider what the report includes, whether it maps findings to WSTG test IDs, and whether the executive summary, technical appendix and retest letter are separate deliverables with separate effort.
Questions buyers ask before choosing WSTG or PTES
Is the OWASP Web Security Testing Guide a complete test on its own?
No. WSTG is a catalog of web application test cases, grouped into 12 categories from information gathering through business logic, client-side and API testing. It tells testers what to check, not how to run an engagement. The guide itself says no single technique is enough and recommends a mix of manual inspection, threat modeling, source code review and penetration testing, with more weight placed on early development phases. A WSTG-only assessment leaves out scoping, rules of engagement, attack path planning and reporting unless the provider adds them. Ask the provider which process wraps the WSTG cases and how the findings are reported and validated.
Does PTES cover every web application category I need?
PTES does not list web test categories. It is a general penetration testing process with seven main sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting, with technical guidance published separately. Its scope runs from a routine web application or network test to a full red team engagement. Web coverage depends on the technical guidance and on the tester's own method, so a PTES-based statement of work should name the web test cases it expects, typically by reference to WSTG v4.2 or another catalog.
What does the client need to provide before a web application test starts?
The work depends on what the tester must see and reach. Most web engagements need test accounts at each privilege level, so authorization checks can be exercised. Architecture documents, API specifications and a list of trust boundaries reduce time spent discovering the application. Source code access supports the hybrid testing that OWASP ASVS 5.0.0 strongly encourages over testing without documentation or source. The client should also agree on a test environment, rules of engagement, contact points for incidents, and whether testing covers production. Confirm each item in writing before the work is scheduled.
How long does a web application test take, and what changes the duration?
No researched figure is available for typical duration, so confirm it with the provider against your own scope. The main drivers are the number of roles and user journeys, the number of APIs and integrations, whether source code and documentation are provided, whether the test runs against staging or production, and how many retest cycles are planned after fixes. A fixed-scope engagement sets scope, deliverables and timelines in writing before work starts, so ask for the schedule as a written milestone plan rather than a single estimate.
Can our own security team run WSTG in-house?
Yes, WSTG is written so that a skilled internal team can work through its test cases, and it is free to use. The effort lies in tooling, tester skill, evidence handling and independence. Internal testers often know the application too well to challenge its assumptions, which is one reason many organizations use an independent team for the annual test. Your team will also need a defined rules of engagement and a way to validate that detections cover the techniques used, which CIS Safeguard 18.4 asks for. Ask whether the in-house output will satisfy your auditor, since that depends on the framework you are assessed against.
Which reference should we cite in a statement of work for a web application test?
Cite WSTG v4.2 as the test case reference for web application categories, and cite PTES or a similar process for engagement phases, rules of engagement and reporting. NIST SP 800-115 provides a rules of engagement template in Appendix B and says it does not endorse one methodology over another, so it can be cited as the governing guide. If a framework requires a specific methodology, such as PCI DSS 11.4.1 for penetration testing, confirm with the assessor which reference they accept. Also cite NIST SP 800-53 control CA-8 if your baseline requires penetration testing, and SA-11 for developer testing.
Does a DORA or TIBER-EU requirement change which reference we use?
It can. DORA Article 25(1) lists tests such as vulnerability assessments, scenario-based tests and penetration testing, and Article 26 requires threat-led penetration testing at least every 3 years for entities identified by their competent authority. TIBER-EU is a threat intelligence-based red team framework with at least 12 weeks of active testing and mandatory purple teaming, and the ECB states these tests produce no pass or fail result. A web application test alone does not meet a threat-led requirement. Confirm with your competent authority whether a WSTG-based web test counts toward the DORA testing obligation.
How DeployOpen scopes and delivers web application security testing
This sequence turns a web application or API test into a written, fixed-scope engagement with a named methodology, verified findings, and a retest that shows what was fixed.
Agree the written scope and rules of engagement
DeployOpen and the client define the applications, APIs, environments, user roles, testing windows and any out-of-bounds actions before work starts. The rules of engagement cover who may be contacted, what testing is permitted in production, and how a critical finding is escalated. The output is a signed statement of work that sets the scope and deliverables. The step is complete when both parties have approved that document in writing.
Name the methodology in the statement of work
The statement of work names the reference that structures the test, such as the OWASP Web Security Testing Guide for application-level coverage, PTES for the engagement process, or both. Where a test covers an API, the SOW also states which API standard or specification the testers will follow. The client confirms that the named methodology matches the evidence it needs for its own assurance file. The step is complete when the methodology appears in the SOW as a reviewable line item.
Gather documentation and access for the target
The client supplies architecture notes, API specifications, role matrices, test accounts and any source code access the scope includes. Documentation-led testing typically finds more authorization and business logic issues than testing with no context, so the client should confirm which materials exist before the test starts. DeployOpen records what was provided and what was not. The step is complete when the test accounts work and the gaps are logged in the engagement file.
Run the manual and automated application tests
DeployOpen testers work through the agreed test categories, covering information gathering, authentication, authorization, session management, input validation, business logic, client-side and API behavior. Automated scanners support the manual work but do not replace it, because the PCI SSC guidance treats penetration testing as an essentially manual process. Testers keep notes and request evidence for each test case. The step is complete when every in-scope category has a recorded outcome.
Validate and rate each finding
Each suspected issue is reproduced by hand, with the request, response and conditions recorded, so that the client can repeat it. Testers remove false positives and rate severity using the scoring method the SOW names. Findings that could chain into a larger compromise are linked together. The step is complete when every reported finding has reproduction steps and a rating the client can review.
Deliver the report and walk through fixes
The report maps each finding to the test case and methodology reference used, describes the impact in plain terms, and gives remediation guidance developers can act on. DeployOpen walks the client's engineering and security leads through the findings so fixes can be prioritized. The report is an input to the client's own assurance file and is not an audit report or certification. The step is complete when the client accepts the report and the remediation owners are named.
Retest remediated findings
After the client applies fixes, DeployOpen retests the findings in the agreed scope and records whether each fix holds or fails. The retest result is added to the engagement record so the client can show what was closed and what remains open. Changes that touch other parts of the application may need a wider check, which the SOW should cover in advance. The step is complete when each finding is marked as resolved, open or accepted risk with supporting evidence.
Continue testing under an optional retainer
Where the client wants testing to follow releases, DeployOpen can offer a retainer for ongoing support and continuous testing, scoped in writing like the original engagement. The client should ask what triggers a retest, how new features are added to scope, and how findings are tracked between cycles. DeployOpen prepares the evidence for each cycle, and independent auditors or certification bodies decide what that evidence proves. The step is complete when the retainer scope and reporting cadence are agreed in writing.
