Choose an OWASP ASVS level by asking what harm your application must resist, then naming the level you will work toward and verify, the parts of the application it covers, and any higher-level requirements your risks demand now. For many web applications, Level 2 is a sensible target: OWASP says most applications should strive for it. Level 1 is a starting point, not a statement that a SaaS product is safe. Level 3 is a deeper target for applications needing the highest assurance. The answer changes with your data, transactions, user expectations, architecture and tolerance for residual risk. Selecting a target does not establish that your application meets it. OWASP ASVS 5.0.0 explains the levels and asks organizations to decide based on their own risks.
This decision is useful to a CTO because it converts “we use OWASP” into a work plan. It gives engineering a stable requirement set, security an evidence standard and a buyer a question they can check. Record the version as ASVS 5.0.0; identifiers can change between versions, so include the version in every requirement reference.
What each level actually commits you to
ASVS is a set of verifiable application security requirements, not a scanner setting or a risk score. Its levels are cumulative. At Level 2, applicable Level 1 and Level 2 requirements need evaluation; Level 3 adds the Level 3 requirements. Some requirements have stronger conditions at higher levels. OWASP describes Level 1 as a minimum starting point, Level 2 as the goal for most applications and Level 3 as the highest depth. It also says a team may prioritize a higher-level requirement earlier when its particular risks warrant that. See the ASVS level explanation.
“We target Level 2” is a planning decision. “We satisfy Level 2” is an evidence claim that requires checking all applicable requirements, explaining applicability and reporting unresolved failures. A source-code review can contribute evidence for some requirements. It cannot, by itself, establish deployed behavior, operational procedures, external service configuration or the results of an authorized runtime assessment. OWASP separates the requirements from the methods a verifier uses, and points testers to resources such as the Web Security Testing Guide.
Avoid choosing a level from a single label such as “B2B,” “financial,” or “enterprise.” Those words do not say which users can reach which operations, whether a mistake can expose another customer, or how quickly the mistake would be noticed. Use the application’s actual flows.
An illustrative decision for a multi-tenant SaaS
Illustrative case; company, design and decisions are invented. Northstar Docs serves business customers. An account admin invites colleagues. Members upload documents and run exports. Each account has its own records in a shared application and database. A signed-in user must never retrieve or alter another account’s document. The product also has a public marketing site and an internal billing integration.
The CTO and AppSec lead make these decisions:
| Question | Northstar answer | Effect on the ASVS plan |
|---|---|---|
| What is at risk? | Customer documents and exports could cross account boundaries. | Give authorization and data protection early attention. |
| Who can reach it? | Ordinary members can request document IDs and exports over public APIs. | Include those API entry points and worker handoffs. |
| What is the target? | ASVS 5.0.0 Level 2 for the customer application. | Review applicable Level 1 and Level 2 requirements; do not call the target achieved. |
| What needs extra depth now? | Export jobs act across services and a privileged support path exists. | Evaluate relevant Level 3 authorization and contextual controls even before a full Level 3 program. |
| What is outside that application? | The separate marketing site and a vendor-operated billing portal. | Scope the marketing site separately; retain billing integration and trust-boundary questions that affect this application, even if vendor internals are unavailable. |
| What evidence is missing? | Production gateway policy, service identity propagation and an observed cross-account denial. | Keep those requirements unresolved until the owners supply evidence. |
The ASVS Authorization chapter makes the decision concrete. Requirement v5.0.0-8.2.2 concerns explicit permission to specific data items and is Level 1. Requirement v5.0.0-8.4.1 concerns cross-tenant controls and is Level 2. Requirement v5.0.0-8.3.3, about checking the original subject rather than an intermediary service’s authority, is Level 3. For Northstar, the export worker makes 8.3.3 worth assessing early even though the overall target is Level 2. The exact requirement text and level should be checked in the versioned OWASP chapter when the record is updated.
The team should not write “ASVS Level 2 covered” because someone found an account_id filter in one query. The download route, export route, worker, list endpoint, direct object endpoint, permission-changing routes and delivery storage may enforce the rule differently. A reviewer needs to trace the request and identify the trusted decision point for each operation. A controlled check in an authorized test environment can establish observed behavior for chosen cases; it does not prove every possible path.
Make the choice in five steps
1. Name the application and version. Put the product boundary, major services, deployed environments and ASVS version in a one-page record. An API and its background worker belong together when one user action crosses both. A mobile client, browser UI or external identity provider may require separate evidence, even when they support the same user journey. The output is a scope map the service owner can correct, including interfaces to external services whose internals remain outside the assessment.
2. Write three to five loss scenarios. Use actor, action, asset and consequence: “A normal member supplies another account’s document ID and receives its contents.” Include integrity and availability harms where they matter, not just confidentiality. Ask the product owner to confirm which scenarios are genuinely costly. This prevents a level choice from becoming a purely technical vote.
3. Choose a base target, then add risk-specific requirements. Start with the OWASP level descriptions. Level 2 will often be a reasonable target for customer-facing SaaS, but capacity or product stage may require a staged plan. If starting at Level 1, name the date and conditions for expanding; do not present it as a permanent assurance ceiling without a reason. If a high-impact workflow needs a Level 3 control now, add that requirement explicitly instead of pretending the whole application is at Level 3.
4. Decide applicability per component. OWASP notes, for example, that web frontend requirements may not apply to a machine-to-machine API and that unused technologies can make whole sections irrelevant. An N/A needs a reason tied to architecture, not “scanner did not report it.” Requirements linked to a shared control still need evidence that each dependent service actually uses that control. OWASP explains applicability and domain-specific tailoring.
5. Set the proof and review cadence. For each applicable requirement, name a responsible service owner and the evidence required: source review, configuration review, architecture record, controlled runtime validation, or several methods. Mark the result pass, fail or unresolved, with revision and environment. Revisit the level and applicability when the product adds sensitive data, new account roles, an external API or a significant service boundary. The AppSec lead owns the register; the CTO owns the risk decision and resources to close gaps.
Make the target survive a resource constraint
Northstar has three synthetic planning inputs: cross-account document disclosure is a material loss scenario; a buyer requests evidence for the customer application and export flow; and production identity-provider configuration will not be available during the first review week. The CTO has enough capacity for one focused flow review now, not a complete Level 2 assessment.
Two honest plans are possible. The first keeps the application-wide Level 2 target, sequences the export boundary first and reports the remaining obligations as planned or blocked. The second contracts the initial assessment to one export flow while retaining the broader target as future work. Neither plan permits “Level 2 satisfied” now. Reducing the label to Level 1 would not remove the need to prevent customer documents crossing accounts.
The CTO selects a staged Level 2 program with an explicit additional Level 3 originating-subject question for exports. The decision record is:
| Decision field | Filled Northstar value |
|---|---|
| Target | ASVS 5.0.0 Level 2 applicable requirements for customer application |
| Immediate higher-level work | v5.0.0-8.3.3 on export intermediary authority, selected because the loss scenario crosses services |
| First assessment slice | Export admission, worker read and result delivery at the pinned staging build |
| Evidence blocked | Production identity-provider mapping and current deployment binding |
| Resource commitment | API/worker owners supply traces; platform supplies configuration in the next agreed window; AppSec maintains remaining obligation plan |
| External statement now | Target selected; focused assessment underway; production and full-level achievement not established |
| Change trigger | New privileged support workflow, new data class or changed delegation boundary |
The buyer may need broader assurance before purchase. That is a delivery/commitment discussion, not a reason to erase the blocked configuration row. The CTO can fund additional access and assessment, negotiate a narrower initial scope, or delay the claim. The standard cannot make that tradeoff disappear.
When privileged support launches, reopen the application boundary and relevant contextual/admin controls. A past Level 2 target record does not automatically cover a new support principal. Record what was added, which requirements now apply and which previous evidence can still be reused after checking the new callers.
All quantities and commitments here are illustrative. The versioned level guidance permits risk-based prioritization of higher-level requirements; it does not authorize an assessor to claim an entire level from a selected subset.
Review the target when the business boundary changes
Northstar's next decision may be driven by a new use case rather than a new standards edition. If customers begin storing a more sensitive document class, the CTO should revisit the loss scenarios, relevant requirements, evidence depth and response capacity. The review may lead to additional higher-level obligations without changing every existing component at once. Record the reasoning so “Level 2 plus selected controls” remains a specific plan instead of an informal marketing phrase.
A buyer's broader request should receive the same treatment. Compare its required application boundary and assurance method with the current program. If the request includes production support access and Northstar has assessed only member exports, name the additional work and owner. Reusing the same level number does not make the scopes equivalent.
Keep the target record short enough to use at a roadmap discussion: current boundary, material loss scenarios, selected baseline, risk-specific additions, blocked evidence and the next decision. The detailed requirement register supplies the work. The CTO's record explains why that work deserves capacity and which assurance statements the company can make today.
What this choice cannot tell you
The chosen level does not make an application compliant with law or certify it. It does not say the source review covered every file or that a scanner can assess every requirement. Even a completed requirement assessment describes the application, version, scope, methods and evidence examined at a point in time. Deployment drift and later code changes can invalidate parts of it. A source-supported concern is not an observed exploit; a clean source review is not a penetration test.
Start with one loss scenario and map it to two or three versioned requirements before asking a tool for a level score. Then use the excluded-source record to identify what the chosen scope leaves out and the buyer-verifiable coverage statement when you need to explain the result externally.