Which ASVS verification level do you set for a payment-initiation API versus a marketing microsite?

### The level is a scoping decision ASVS grades its requirements into **three cumulative verification levels**. The baseline level is the low bar — the requirements you would expect any application on the internet to meet, and which can largely be checked without deep access to design documents. The middle level is the standard bar for applications that handle sensitive data or transactions; in practice it is the level most real business systems should be held to. The top level is for the highest-assurance systems, and it adds not only more requirements but a heavier expectation of evidence, segregation and defence in depth. Cumulative matters: the middle level contains the baseline, the top contains both. Choosing a level is therefore choosing a **floor**, not selecting one of three lists, and it does not stop you pulling individual higher-level requirements into a specific flow. ### The two systems in the question **The payment-initiation API.** The asset is money and the integrity of transactions, the attacker population includes motivated and funded people who will target it deliberately, and the blast radius of a failure is regulatory as well as financial. This is a middle-level system at minimum. The interesting judgment is what to do above that: rather than declare the whole estate top level — which mostly buys you an unfunded promise — pull specific top-level requirements into the flows that move money: stronger authentication binding for the initiation step, deeper logging with tamper-evident storage so a disputed transaction can be reconstructed, segregation of the signing material, and reviewed business-logic controls on limits and duplicate submission. That gives you depth exactly where the asset is, at a verification cost you can actually pay. **The marketing microsite.** No transactions, no customer records, a small attack surface, and usually built fast by people who are not the platform team. Baseline level is the honest answer, and insisting on more is how a security bar gets ignored across the whole organisation. ### The caveat that separates a senior answer from a junior one The microsite is only a low-value system *if it is genuinely outside the payment system's trust boundary*. Ask three questions before you sign off on the baseline: - Does it share a **cookie domain or session scope** with the authenticated application? If a scriptable page on the same registrable domain can set or read cookies the payment app trusts, its compromise is an authentication problem, not a defacement. - Does it share an **identity provider, an API key, or a service account**? A contact form that can call an internal endpoint has pulled the microsite inside the boundary. - Does it share **infrastructure or a deployment pipeline** with the payment service, so that code execution on one is a foothold toward the other? If the answer to any of these is yes, you have two choices, and both are legitimate: raise the microsite's bar to match what it can reach, or **separate them** — a different domain, no shared tokens, an isolated pipeline — so the low bar is actually true. The second is usually cheaper. The general rule is that the level follows the **trust boundary and the asset**, not the org chart, not the team that built it, and not the revenue the system generates. ### What a level does not mean A level is not a badge. Saying "we are Level 2" is meaningless on its own, because the claim has three hidden variables: which version and requirement set, what was in scope, and who verified it. Any credible statement carries all three, plus the results — including the requirements that **failed** and the exceptions accepted with a named owner and a date. A verification report with no failures in it is a report to be suspicious of. The same rigour applies inbound. When a supplier advertises that an SDK "meets Level 2", the useful questions are: who assessed it, against which requirement set, was the scope the SDK alone or the hosted service behind it, was the assessment black box or with source and design access, when was it done, and what is the re-verification cadence when the product changes. A self-attested claim with no scope statement should be treated as marketing, and if the level matters commercially it belongs in the contract with an evidence obligation attached, not in a slide. ### The organisational trap The failure mode at scale is a blanket policy — "everything must be Level 2 by Q3" — issued without funding the verification. What follows is predictable: teams self-assess, mark rows green, and the programme produces a spreadsheet instead of assurance. The alternative is unglamorous and works better: a low default that every system genuinely meets, a higher floor for the small set of systems that hold the crown-jewel assets, explicit above-floor requirements on the specific flows that justify them, and a real budget for independent verification of that short list. A level you can evidence for five systems is worth more than a level you have declared for two hundred.