In the previous lesson we saw that every ASVS requirement is tagged for one or more assurance levels. That is one of the standard's great strengths: it does not demand the same of a recipe blog as of a payment gateway. The ASVS defines three levels —L1, L2 and L3— that build up in rigor. Choosing the right level is the most important decision when adopting the standard, because it determines how many requirements apply and how thoroughly they must be verified. In this lesson we will understand what each level requires, how to choose the right one based on the application's criticality, and we will decide, with reasoned arguments, which target level makes sense for BazarNube.

1. Why the ASVS has levels
2. Level 1 (L1): opportunistic / basic
3. Level 2 (L2): standard
4. Level 3 (L3): advanced / critical
5. Comparison table L1 / L2 / L3
6. How to choose the level based on criticality and data
7. Which level BazarNube chooses and why

Applying the ASVS's hundreds of requirements to every application equally would be absurd: a static contact form does not need the same armouring as a banking system. Levels solve that problem by grading the demands. They are cumulative: each higher level includes all the requirements of the one below and adds its own.

The idea is simple: moving up a level does not change the checklist, it extends the existing one and increases the depth with which each control must be verified.

Level 1 is the minimum of security that every application should reach. It covers the controls against the most common, lowest-effort threats —the "opportunistic" attacker who uses automated tools and known techniques without dedicating special resources.

Key characteristics:

• Fully verifiable externally, with no access to source code or documentation. It can be checked through black-box testing / pentest.
• Protects against widely known vulnerabilities (much of the Top Ten is covered here).
• It is the floor, not the goal, for almost any application that handles user data.

Examples of typical L1 requirements:

• Access control exists and sensitive functions require authentication.
• Passwords have a minimum length and are not on a list of compromised ones.
• The application encodes output to prevent XSS.
• Traffic goes over TLS.

Typical L1 applications: low-risk sites, internal applications with no sensitive data, or as a preliminary maturity step before reaching L2.

Level 2 is the one recommended for most applications, especially those that handle personal data, transactions or significant business information. It defends against skilled and motivated attackers who use advanced tools and techniques in a targeted way.

Key characteristics:

• It requires access to documentation, design and source code to be properly verified (black-box alone is not enough). Code review is combined with testing.
• It adds defence-in-depth controls: robust session management, object-level access control, well-applied cryptography, logging of security events, thorough validation.
• It is the level usually required by enterprise clients, data-protection regulations and serious audits.

Examples of what L2 adds on top of L1:

• Resource ownership verification on every access (systematically prevents IDOR).
• Sensitive data encrypted at rest with proper key management.
• Logging of relevant security events with protection against tampering.
• Anti-automation and protection against credential stuffing.

Typical L2 applications: e-commerce, B2B SaaS, applications with personal or payment data. This is where BazarNube fits.

Level 3 is the highest and is reserved for critical applications: those whose compromise would have serious consequences for life, national security, large financial volumes or essential infrastructure.

Key characteristics:

• It demands maximum rigor: exhaustive code review, architecture analysis, documented threat modeling and defence in depth at every layer.
• It requires justifying the security design, not just that the controls exist: you must demonstrate that the architecture is resilient.
• The verification effort is substantially higher; it is applied only when the risk justifies it.

Examples of what L3 adds on top of L2:

• Strict component segregation and minimal trust between modules.
• Verification that threat modeling exists and that the design reflects it.
• Advanced cryptographic controls and top-tier key management.
• Traceability and logging suitable for complete forensic analysis.

Typical L3 applications: core banking, healthcare, military systems, critical infrastructure, platforms that process large payment volumes as the core of the business.

Choosing the level is not an aesthetic preference: it derives from risk, which depends on what data is handled and what would happen if it were compromised. A practical procedure:

1. Inventory the sensitive data and functions. Is there personal data? Payment methods? Medical records? Real money moving?
2. Estimate the impact of a compromise. Nuisance, moderate financial loss, serious harm to people or the business?
3. Consider external obligations. Regulation (GDPR, PCI-DSS), contractual demands from clients, regulated sector.
4. Map to a level:

A common anti-pattern is "aiming for L3 because it sounds more secure". L3 has a very high verification cost and is only justified when the risk demands it; over-sizing the level consumes resources that would be better invested in properly meeting the right level.

Let us apply the procedure to BazarNube:

1. Data it handles: user accounts, addresses, purchase history and, above all, payment data and personal data of the marketplace's buyers and sellers.
2. Impact of a compromise: financial fraud, leakage of personal data (with a GDPR fine), loss of trust and of the contract with the enterprise client.
3. External obligations: the corporate client requires demonstrable compliance; handling payments brings it closer to PCI-DSS-style demands; GDPR applies because of the personal data.
4. But it is not core banking or critical infrastructure that puts lives at stake.

The team's conclusion is clear:

BazarNube adopts ASVS Level 2 (L2) as its target.

The reasoning Lucía documents in the backlog:

• L1 falls short: it handles payments and personal data; the basic floor covers neither its risks nor satisfies the enterprise client.
• L3 is over-sized: it is not a system where a failure costs lives, nor a core bank; the L3 verification cost is not justified by the real risk.
• L2 is the right spot: it demands defence in depth, verification with code and design, object-level access control, robust cryptography and logging —exactly what a marketplace with payments needs— and it is the level clients and auditors expect.

The door is left open to selectively raise certain modules (for example, the payment subsystem) to L3-level demands, without taking the whole application to that level. This idea of "general L2 with selective reinforcement" is a mature and realistic strategy.

• Choosing the level by ambition rather than risk. "Let's go for L3" without justifying it drives up cost and slows things down without adding proportional security.
• Believing L1 is verified the same way as L2. L1 allows black-box; L2 and L3 require access to code and design. Promising L2 with only a black-box pentest means failing the method.
• Forgetting that levels are cumulative. L2 includes all the L1 requirements; you do not "skip" the lower level.
• Applying a single level to a very heterogeneous system. It is valid to set general L2 and reinforce the most critical components (like payments) to L3.
• Tip: document why you choose the level (data, impact, obligations). That justification is the first piece of evidence an auditor will ask for.

Exercise 1. A startup launches an informational website with no user accounts and no personal data, only public content. Which ASVS level would you recommend and why? What verification method would suffice?

Exercise 2. Justify in 3–4 sentences, as if you were writing it in BazarNube's backlog, why L2 is more appropriate than L3 for the marketplace despite it handling payments.

Exercise 3. BazarNube's payments team proposes: "the whole marketplace to L3 to be safe". Refute or qualify the proposal by suggesting a more efficient alternative.

Solution 1. Level 1 (L1). It handles no personal or sensitive data and the impact of a compromise is low (at most defacement of the public content). The basic floor against opportunistic attackers is proportional to the risk. Being L1, a black-box verification / pentest would suffice with no need for code access, although reviewing it is always desirable.

Solution 2. "BazarNube handles personal and payment data, so L1 does not cover its risks nor satisfies the enterprise client. However, it is not core banking or critical infrastructure with an impact on lives, so L3 —with its exhaustive threat-modeling cost and architecture verification— is over-sized. L2 demands defence in depth, object-level access control, robust cryptography and logging verified with code and design, which is exactly the level of rigor a marketplace with payments needs and that auditors and clients expect."

Solution 3. Taking the whole marketplace to L3 hugely inflates the verification cost (exhaustive architecture review, documented threat modeling of every component) without most modules (catalogue, reviews, profile) justifying it by their risk. A more efficient alternative: set L2 as the general target and selectively reinforce only the payment subsystem to L3-level demands, which is where the impact of a failure is greatest. You get the armouring where it matters without paying the L3 cost across the whole application.

The ASVS grades its demands into three cumulative levels: L1 (basic, against opportunistic attackers, verifiable in black-box), L2 (standard, for most apps with data, verifiable with code and design) and L3 (advanced, for critical systems, with threat modeling and architecture review). The level is chosen by risk: what data is handled and what impact its compromise would have. BazarNube adopts L2 because it handles payments and personal data without being a critical system, with the option to selectively reinforce the payments module.

We now know which standard we use and what level we aspire to. It is time to open the catalogue and see the actual requirements. In the next lesson, 04-03 Security Requirements, we will walk through the most relevant chapters (authentication, sessions, access control, validation, cryptography, logging...), learn to read a verifiable requirement and map BazarNube's Top Ten findings to concrete ASVS requirements.