OWASP ASVS verification vs penetration testing

ASVS verification or penetration testing: which one your customers are asking for

A customer questionnaire or contract that asks for ASVS verification is asking for requirement-by-requirement coverage at a chosen level. A penetration test answers a different question: whether someone can actually exploit the running system, and it reports the weaknesses it found by exception. ASVS 5.0.0 describes an ASVS verification report as covering the scope, a summary of every requirement checked, the requirements that have exceptions, and guidance on fixing them. A traditional penetration test report lists issues without that full requirement map. Read the request closely, because the two documents answer different buyer questions and are not interchangeable.

Choose ASVS verification when the customer needs evidence that a defined set of controls was checked at a stated level, such as authentication, session handling, access control or OAuth and OIDC behavior under chapters V6, V8 and V10. OWASP advises starting at Level 1 and moving up according to the organization's and application's needs, so confirm which level the customer wants before you agree a scope. Choose a penetration test when the buyer's concern is whether an attacker could chain weaknesses into real impact, or when the application has business logic that a checklist will not reach. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and the OWASP Web Security Testing Guide makes the same point that no single technique is enough.

When a contract names both, scope them as two deliverables with a shared target list rather than assuming one replaces the other. ASVS 5.0.0 encourages hybrid testing that uses documentation or source code, which means the verification team needs access to design documents and code that a penetration tester working from outside may not receive. Before you sign, ask the provider which ASVS level and chapters the verification covers, whether the tester will have source and architecture documents, and whether the report will list every requirement or only exceptions. Confirm with the customer whether a claim of ASVS compliance is acceptable, since OWASP does not certify vendors, verifiers or software.

How the two approaches differ on scope, method and output

This table compares an ASVS verification against an exception-based penetration test on goal, scope, method, evidence and report. Read it as a buyer choosing what to name in a statement of work, because each approach answers a different question about the application.

Dimension	ASVS verification (5.0.0)	Penetration test
Primary goal	Check each applicable requirement at the chosen level and record a result for every one	Find exploitable weaknesses and show what an attacker could reach within agreed rules of engagement
Scope unit	Requirements across the 17 chapters, V1 to V17, at Level 1, 2 or 3	Agreed targets, accounts and attack paths, chosen by the client and tester
Method at a buyer's level	Systematic test of each requirement, with documentation or source code reviewed where the level calls for it	Manual, tester-led attack work informed by reconnaissance; tools support but do not replace it
Source and documentation needs	ASVS 5.0.0 strongly encourages hybrid testing, so source code and design documents are expected for a fuller result	Not required by default; many engagements are black box or grey box, and access is set in scope
Report structure	Scope, a summary of all requirements checked, requirements with exceptions, and guidance on resolving them	Findings listed by exception, with evidence, impact and remediation advice
What it finds	Gaps against each requirement, including controls that were never built or are inconsistent across the application	Exploitable chains and business logic or access control flaws that an attacker could actually use
What it can miss	Attack paths outside the requirement set, and depth beyond the level chosen	Requirements that were not tested, so a clean report says nothing about unexamined controls
Link to a certification claim	OWASP does not certify applications or verifiers, and any mark claiming ASVS compliance is not OWASP-endorsed	A penetration test is not a certification either; certification bodies and auditors decide what evidence they accept

Which ASVS levels need source code and documentation

ASVS defines three verification levels, L1 to L3, each adding depth and complexity over the one below it. OWASP advises organizations to start at L1 and move up as their own needs and the application's risk require. The level you choose determines how much verification you pay for, so decide it before you ask anyone for a quote. For a first pass on a lower-risk internal application, L1 may be the sensible starting point. For an application that handles regulated data or high-value transactions, the decision may point higher. Write the chosen level, and the reasons for it, into the statement of work so the assessor and your team work from the same target.

ASVS 5.0.0 strongly encourages documentation-led or source-led (hybrid) penetration testing over testing with no documentation and no source. In practice, that means asking for architecture diagrams, authentication and authorization design notes, data flow descriptions and, where the team can provide it, read access to the code for the areas in scope. A tester working this way can check whether a control exists and is wired correctly, instead of inferring it from behavior alone. Confirm with your assessor which access model they will use at each level, what documentation they need before testing starts, and how they will handle code or design material under your confidentiality terms. Ask them to state in writing where source access would change the findings.

Do not assume that a given level requires a specific test type, or that a level is only valid with source access. The standard encourages hybrid testing but does not require it for every engagement, and the choice depends on your application, your threat model and what your assessor can verify with the access you provide. Ask your assessor to explain how the scope, access model and level map to the requirements they will check, and whether any requirement will be verified only by testing behavior. If a customer or regulator asks for a particular level or access model, get that requirement in writing and check it against the standard, not against a label used in a sales conversation.

What ASVS verification finds and misses versus penetration testing

Each method sees a different part of the risk. ASVS verification checks breadth against a requirement list, while a penetration test follows an attacker's path through the running system. The cards below set out the conditions under which each gap matters and what to confirm before you rely on either result.

Requirement coverage and missing controls

ASVS verification works through every applicable requirement at the chosen level, so it is strong at finding controls that were never built, such as missing session timeouts, absent input validation rules or logging gaps that a tester would only notice by chance. This matters most when a team has never been checked against a complete list. Ask the verifier to show the requirement-by-requirement record, including which requirements were marked not applicable and why, and confirm the scope covers the authentication and session chapters that your users depend on.

Chained attacks and business logic abuse

A penetration test is strongest when a weakness only matters in combination, for example a low-impact information leak that enables account takeover through a password reset flow. Requirement checks tend to evaluate controls one at a time, so they can pass each control while the sequence still succeeds. This matters for payment, lending and approval workflows where the harm comes from abusing legitimate steps. Ask the tester to describe the attack chains they attempted and which business rules they tried to break.

Authorization and OAuth or OIDC design flaws

Flaws in object-level authorization, tenant isolation and OAuth or OIDC flows often depend on design intent and code context. A reviewer needs the role model, the token flow and the resource ownership rules to decide whether a request is wrong, and an exception-only report may not explain why. Checking V8 Authorization and V10 OAuth and OIDC requires documentation and source access. Before you commission the work, confirm the verifier will receive architecture diagrams, role matrices and the identity provider configuration.

Limits of documentation-only review

A verification that relies only on design documents can confirm that a control is described but not that the code enforces it. Documentation can be out of date, and a requirement can pass on paper while a helper function skips the check on one route. ASVS 5.0.0 encourages hybrid testing that combines documentation or source with dynamic testing for this reason. Ask the verifier how they will confirm each claimed control in the running build, and which evidence will come from code and which from observed behavior.

Pentest scope that omits listed requirements

A penetration test reports exceptions it found within its chosen scope, so requirements the tester never examined produce no record at all. A team that buys a test and then cites it against a level may leave gaps that nobody documented. This matters when a customer asks for ASVS assurance but the statement of work names only a penetration test. Ask for a written mapping from the test scope to the ASVS requirements it covers, and for a list of what was excluded.

False comfort from a checklist without exploitation

A completed requirement checklist can look like proof that the application resists attack, even when no one tried to exploit it. A requirement marked as passed by review says the control exists, not that it withstands an attacker working against the deployed system. This matters when the report is shared with customers, auditors or procurement teams who may read a clean result as the absence of exploitable flaws. Ask whether the verification includes targeted exploitation of failed or high-risk controls, and state in the report what a pass does and does not establish.

What each report looks like and who reads it

A security lead reading an ASVS verification report is looking for coverage and gaps across the whole application, not a list of the worst things found. OWASP's ASVS 5.0.0 describes the expected report contents: the scope of the verification, a summary of all requirements checked, the requirements where exceptions were found, and guidance on resolving each exception. The summary of all requirements is what separates this report from a conventional findings document, because it shows the reader what was tested and what passed.

Scope statement: Names the application, version, the ASVS chapters and the verification level that was targeted.
Full requirement summary: Shows the status of every applicable requirement, so passed items are visible and not inferred from silence.
Exception list: Identifies each requirement that did not meet the standard, with the evidence behind it.
Resolution guidance: Gives the team a path to fix each exception and a basis for retesting.
Coverage over time: Lets the security lead track which requirements are verified in each release and which still need work.

Before accepting an ASVS report, confirm that the requirement summary covers every applicable requirement at the chosen level and that the scope names the source code or documentation the verifier used.

Questions buyers ask before choosing ASVS verification or a penetration test

What drives the cost of an ASVS verification compared with a penetration test?

Cost follows scope and depth, not a standard price list. For an ASVS verification, the main drivers are the chosen level (L1 to L3), the number of applicable requirements, the size and complexity of the application, and whether documentation and source code are available for review. For a penetration test, the drivers are the number of targets, the authentication roles to test, the attack surface and the time the testers need to probe exploitable paths. In both cases the tester is the main cost and the scope document is what sets it. Ask any provider for a written scope that names the ASVS level or test type, the targets, the roles and the deliverables, and get the quote tied to that scope. DeployOpen engagements are typically fixed-scope and quoted from the written scope.

How long does each one take, and what sets the duration?

The duration depends on the level and scope you agree, not on a fixed figure. An ASVS verification at a higher level needs more review of requirements, and source-led work takes longer than black-box testing of the same application. A penetration test is shaped by the number of targets, the roles to exercise and how much exploit chaining the rules of engagement allow. No duration is set by the OWASP ASVS 5.0.0 standard, so treat any single number from a vendor as a claim to verify. Ask for a schedule with milestones, the dates the client must supply inputs by, and the retest window if fixes are planned.

What does the client need to provide for each engagement?

The inputs differ by method. An ASVS verification works best with architecture documents, data flow and threat models where they exist, access to source code or configuration, and test accounts for each role. A penetration test needs test accounts, target lists, rules of engagement and an agreed window, plus a named contact who can approve actions that could affect production. A hybrid, documentation- or source-led approach, which the ASVS 5.0.0 standard encourages over testing without documentation or source, needs all of the above. Name the contact, agree how production risk is handled, and confirm the source and document access in writing before work starts.

Can our own team run ASVS checks, and what are the limits?

Yes, an internal team can work through ASVS requirements at a chosen level, and OWASP recommends starting at Level 1 and moving up as needs grow. The limits are independence and evidence. Self-assessment is useful for finding gaps, but an external party will not accept it as independent verification, and staff who built the application may miss the same assumptions. Keep a requirement-by-requirement record with scope, evidence and exceptions, which is the shape the ASVS verification report is meant to take. Use an independent verifier when a customer or regulator asks for outside assurance.

Does an ASVS report prove compliance or certify the application?

No. OWASP does not certify vendors, verifiers or software, and any assurance mark or certification that claims ASVS compliance is not officially endorsed by OWASP, according to ASVS 5.0.0. An ASVS verification report documents the scope, a summary of the requirements checked, the requirements with exceptions and guidance on resolving them. That document is evidence of what was tested and what was found. Read any vendor claim of ASVS compliance carefully and ask which requirements, which level, which version and which verifier produced the result. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications.

Will customers or regulators accept one in place of the other?

It depends on the customer and the regulation, so confirm it before you choose. ASVS and penetration testing answer different questions. ASVS verification checks coverage against a requirements list and reports exceptions, while a penetration test reports exploitable findings by exception. Regulatory and customer frameworks differ on which they expect; for example, PCI SSC's penetration testing guidance says an automated tool alone does not satisfy a penetration test requirement. Ask each customer or regulator, in writing, which test type and which level they accept, and whether a combined engagement satisfies both demands.

How do we ask for a fixed-scope quote that we can compare?

Send each provider the same written scope. Include the application name and version, the ASVS level or the penetration test type, the in-scope targets and environments, the authentication roles, the documents and source access you will supply, the named contact, the rules of engagement and the required deliverables. Ask for the report format, the retest terms and what happens if scope changes mid-engagement. Ask each provider to state what is one-time and what recurs, such as retests or a support retainer. DeployOpen does not publish a price list, and its engagements are typically fixed-scope, agreed in writing before work starts.

How to combine ASVS verification with penetration testing in one program

This sequence sets the ASVS level first, then uses documentation and source to verify every applicable requirement, and finally points a penetration test at the exceptions and high-risk flows that the verification report cannot fully answer. Confirm the order with your assessor before you start.

Choose the ASVS level from risk and customer demands
The application owner, security lead and, where contracts require it, the customer's security team agree which ASVS verification level applies. OWASP advises starting with Level 1 and moving up according to the organization's and application's needs, so the choice should follow the data the application handles, its exposure and what buyers have asked for in writing. The step is done when the chosen level, the applicable chapters and the reason for each are recorded in the verification scope document. Confirm with your assessor whether every chapter applies at that level or whether some can be marked not applicable with justification.
Prepare documentation and source access
The development team assembles architecture diagrams, data flow descriptions, authentication and authorization design notes, build instructions and read-only access to the relevant repositories. Your assessor and the tester need this material before testing begins, because ASVS 5.0.0 strongly encourages documentation or source code led (hybrid) testing over testing without either. Access is usually granted through a named account with logging enabled, and the security lead confirms in writing what was provided. The step is complete when the assessor confirms the package is sufficient for the chosen level.
Run hybrid verification against each requirement
Verifiers work through every applicable requirement at the chosen level, testing the running application and reading the code or design where the level calls for it. Each requirement receives a result, and any gap is recorded as an exception with evidence and guidance on resolving it. The output is an ASVS verification report that lists the scope, a summary of all requirements checked and the requirements with exceptions, which differs from the exception-only format of a traditional penetration test report. The step is done when every applicable requirement has a recorded outcome.
Scope penetration testing on exceptions and high-risk flows
Using the exception list and the threat model, the security lead defines a penetration test that concentrates on the failed requirements, authentication and authorization paths, payment or personal data flows and any business logic that a checklist cannot exercise well. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and it provides a rules of engagement template in Appendix B that can anchor the agreement. The step closes when the rules of engagement and written scope are signed by the system owner.
Retest fixes and update the verification record
After developers fix the exceptions, the verifier and the penetration tester retest the affected requirements and flows, then update the verification record to show which exceptions closed and which remain open with a documented risk decision. Retesting confirms the fix works rather than assuming it does. The step is complete when each original exception has a closed status with evidence or an accepted-risk entry signed by an owner.
Validate detections against the tested techniques
The security operations team reviews which attacker techniques the penetration tester used and checks whether logging and alerting would have detected them. CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques the testers used, and this step links the test findings to monitoring gaps. The output is a list of detection rules to add or tune, each tied to a tested technique and assigned an owner. The step is done when the list is reviewed and tracked in the team's backlog.
Schedule recurring testing alongside regular scanning
The program owner sets a recurring cadence for regular vulnerability scanning and periodic penetration testing, which NIST SP 800-115 suggests running together, and decides when the ASVS verification is repeated after major releases or architecture changes. Confirm with your assessor and the customer what interval their contracts or regulators expect, since the source material does not set one for this combination. The step is complete when the schedule, triggers for re-verification and owners for each activity are written into the program plan.

What drives cost and effort for each approach

Both approaches are priced from the written scope, so the same application can cost very different amounts depending on how much is verified and how much access the tester gets. The cards below cover the inputs that move cost and effort most, and what to ask for in a quote.

ASVS level and requirement count

An ASVS verification is priced by the number of applicable requirements at the chosen level, since each one needs a recorded result. OWASP advises starting at Level 1 and moving up as the application's risk requires, so a Level 2 or Level 3 engagement covers more requirements and more evidence. A penetration test is priced by its time-boxed attack scope instead. Ask the vendor how many requirements apply to your application and how each is evidenced.

Documentation and source code access

ASVS 5.0.0 strongly encourages hybrid testing that uses documentation or source code, and that work is usually the largest variable in effort. Architecture diagrams, data flow notes and a readable repository shorten the time needed to map controls, while missing material means more discovery. Confirm before scoping what documents exist, whether source is available for review, and who prepares them.

Application size, roles and integrations

Every user role, tenant model, API surface and third-party integration adds test cases, especially for authorization (V8) and OAuth and OIDC (V10). A single-role web app with no integrations is a very different job from a multi-tenant platform with partner APIs and single sign-on. Ask which roles, environments and integration points are in scope, and whether each one is verified or only sampled.

Tester access and environments

Testers need authenticated test accounts for each role, a staging environment that matches production closely enough to test controls, and a named contact who can answer questions during the work. Without those, time shifts from testing to requesting access and waiting. Agree in writing which environments are in scope and whether production testing is permitted, since penetration testing against live systems carries higher operational risk.

Reporting depth and retest rounds

An ASVS verification report lists the scope, every requirement checked, the requirements with exceptions and guidance on resolving them, so it takes longer to write than an exception-based penetration test report. Retest rounds after fixes are a separate line item. Ask whether retests are included, how many rounds are allowed, and whether the final report will record requirements that passed as well as those that failed.

Fixed scope versus retainer

A fixed-scope engagement has a written scope, deliverables and timeline agreed before work starts, so the quote is tied to those terms. Ongoing verification after each major release, or continuous testing, is usually bought as a retainer that recurs. Decide whether you need a one-time assessment, a repeated assessment per release, or a standing arrangement, and ask the vendor to price each separately.

What OWASP says about ASVS certification claims

OWASP does not certify vendors, verifiers or software. ASVS 5.0.0 states that any assurance mark or certification claiming ASVS compliance is not officially endorsed by OWASP. For a buyer, this means a badge, logo or sentence saying an application or a testing firm is "ASVS certified" carries no OWASP backing. Before accepting such a claim in a statement of work or a due diligence file, ask the provider to name the issuing body, the ASVS version, the chosen verification level, and the scope the claim covers. A claim that cannot be traced to a named body is a claim you should treat as unverified.

The one accreditation most often raised in this context is CREST's OWASP Verification Standard (OVS) accreditation, which CREST announced on 28 October 2022. It assesses whether testing organizations can run web assessments against ASVS and mobile assessments against MASVS at Levels 1 and 2. That is an accreditation of the testing organization's capability at those levels, not a certificate for any particular application, and it does not cover Level 3. Ask any provider which accreditation applies to the work you are buying, at which level, and for which discipline. Then confirm it directly with CREST, since a provider's own description of its accreditation is not sufficient evidence.

Expect some providers to describe a completed engagement as "ASVS compliant" or the application as "certified." Ask for the written verification report and check whether it lists the requirements checked, the exceptions, and the guidance for resolving them, as ASVS 5.0.0 describes. If the document is only a penetration test summary of findings, it does not show that the requirements were verified, whatever the marketing says. Write your procurement language so the deliverable is named by its content, for example a verification report at a stated level, rather than by a label that implies a certification.

How DeployOpen scopes, delivers and supports security testing

DeployOpen plans, runs and documents security testing inside your own infrastructure, so the choice between an ASVS verification and a penetration test is settled against your application, data and audience before work starts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.

How we scope

Agree in writing which ASVS 5.0.0 level applies and which chapters are in or out of the verification
Confirm whether the tester receives documentation and source code, since ASVS favors documentation or source-led testing
Define the report format up front: a requirement-by-requirement ASVS report, an exception-based penetration test report, or both

How we build

Set up the test environment inside your cloud account, data center or air-gapped network, with access limited to agreed accounts
Map each applicable ASVS requirement to a test step, evidence source and tester, and record any requirement not checked
Run exploitation and validation only where the rules of engagement allow it, with stop conditions agreed in advance

How we hand over

Deliver a report that lists scope, every requirement checked, requirements with exceptions, and guidance on resolving them
Provide reproduction steps and evidence for each finding so your developers can verify fixes
Document what the work does not establish, including any claim of ASVS compliance that OWASP does not endorse

How we support

Re-verify agreed requirements after fixes, within the fixed scope of the original engagement or a new written scope
Offer ongoing support, upgrades and continuous testing as a retainer, with terms agreed in writing
Ask your auditor or customer which evidence they accept, and confirm that reports meet their expectations before sign-off