Development teams are often told to "meet ASVS" without anyone deciding which of its roughly 350 requirements apply to which applications, so the standard ends up either ignored or applied in full where it does not fit. This template turns OWASP ASVS 5.0.0 into an organisation-specific requirements baseline: application risk tiers, the ASVS level each tier must meet, rules for marking chapters not applicable, the documentation ASVS expects, how compliance is verified and how exceptions work. It follows the approach the ASVS itself recommends, a traceable organisation-specific fork that starts from Level 1. It is for application security leads, security architects and engineering managers. For background on the standard itself, see the OWASP ASVS Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [AppSec team] and [Risk committee], with your own names.
- "Must" is a mandatory requirement of this baseline; "should" is recommended practice where a documented exception is acceptable.
- Keep ASVS requirement identifiers in the versioned form the standard asks for, for example
v5.0.0-8.2.2, so the baseline stays traceable when ASVS is updated. - Download the ASVS 5.0.0 requirement list in CSV or JSON from the OWASP ASVS project and maintain your tailored list as a controlled file alongside this document.
- Have the tier definitions agreed by risk owners before publishing; the tiers drive cost.
- Review this baseline at least annually and whenever a new ASVS major or minor version is released.
1. Purpose
This standard defines the minimum application security requirements that applications built or substantially modified by [Organisation] must meet. It uses the OWASP Application Security Verification Standard version 5.0.0 (ASVS) as its source so that requirements are specific, verifiable with a pass or fail result, and consistent across teams and suppliers. It also sets how requirements are selected for each application, how compliance is evidenced and who may approve deviations.
2. Scope and applicability
- In scope: web applications, APIs and web services developed by [Organisation] staff or contractors, and those acquired where [Organisation] controls the code or can set contractual security requirements.
- Components included: in line with the ASVS definition of an application, components that serve, modify or validate HTTP traffic for the application (for example a WAF, load balancer or API gateway) are in scope for requirements such as rate limiting, caching and connection restrictions.
- Out of scope of this standard: infrastructure, DNS, backup and CI/CD controls, which are covered by [Infrastructure security standard] and [Secure development lifecycle standard]. ASVS itself notes these must still be addressed elsewhere.
- Mobile and thick clients: native mobile apps must also meet [Mobile standard based on OWASP MASVS]; their back-end APIs are in scope here.
- When it applies: new applications from design onwards; existing applications at their next major release or within [12] months of this standard's approval, whichever is sooner.
3. Roles and responsibilities
| Role | Responsibility under this standard |
|---|---|
| [AppSec team] | Owns this standard and the tailored requirement list; assigns tiers with the application owner; approves not-applicable decisions; reviews verification evidence |
| Application owner | Accountable for the application meeting its tier; signs off risk for any exception |
| Engineering lead | Plans requirements into backlogs; maintains the required security documentation; ensures tests exist for each requirement |
| Security architect | Defines the organisation-wide security decisions referenced by ASVS documentation requirements (for example authorisation model, input validation rules, approved cryptography) |
| Verifier (internal or third party) | Tests requirements and records pass, fail or not applicable with evidence |
| [Risk committee] | Approves exceptions for Tier 1 applications and any exception exceeding [6] months |
4. Application risk tiers
ASVS deliberately does not say which level an application must reach; it asks each organisation to decide based on risk, the sensitivity of the application and the expectations of its users. [Organisation] assigns every in-scope application to one tier.
| Tier | Typical profile | Required ASVS level |
|---|---|---|
| Tier 1: critical | Handles payments, health data, credentials or authentication for other systems; regulated; high-value target; privileged administration interfaces | Level 3 for chapters V6 Authentication, V7 Session Management, V8 Authorization, V9 Self-contained Tokens, V10 OAuth and OIDC and V11 Cryptography where applicable; Level 2 for all other applicable chapters as a minimum |
| Tier 2: standard | Internet-facing or processes personal or confidential data; most business applications | Level 2 |
| Tier 3: low | Internal only, no confidential or personal data, no write access to systems of record | Level 1 |
- The tier must be recorded in [application inventory] with the rationale and the date assigned.
- An application processing data classified [Confidential] or above must not be Tier 3.
- Reassess the tier when the application gains internet exposure, new data types, new integrations or privileged functions.
For context, ASVS states that Level 1 contains around 20% of its requirements, that an application needs around 70% (all of L1 and L2) to comply with Level 2, and that Level 3 adds the final 30% or so. In the 5.0.0 requirement list, 70 requirements are Level 1, 183 are Level 2 and 92 are Level 3, 345 in total.
5. Baseline requirements by chapter
ASVS 5.0.0 has 17 chapters. The table below records, for each chapter, the number of requirements first required at each level and the [Organisation] position. Example requirements show the kind of control each chapter contains; the full tailored list in [requirements file] is authoritative.
| Chapter | L1 / L2 / L3 requirements | Example requirement (v5.0.0) | [Organisation] position |
|---|---|---|---|
| V1 Encoding and Sanitization | 8 / 19 / 3 | 1.2.4 (L1): database queries use parameterised queries, ORMs or equivalent protection | Applies to all |
| V2 Validation and Business Logic | 4 / 7 / 2 | 2.1.1 (L1): documentation defines input validation rules | Applies to all |
| V3 Web Frontend Security | 8 / 11 / 12 | 3.4.1 (L1): Strict-Transport-Security on all responses with a max age of at least one year | Not applicable to APIs with no browser client |
| V4 API and Web Service | 2 / 8 / 6 | 4.1.1 (L1): Content-Type header matching the response body, with charset | Applies to all with an HTTP interface |
| V5 File Handling | 4 / 5 / 4 | 5.2.2 (L1): uploaded file extension and content checked against expected types | Only where files are accepted or served |
| V6 Authentication | 13 / 22 / 12 | 6.2.1 (L1): user-set passwords at least 8 characters, 15 strongly recommended | Applies where the application authenticates users itself; otherwise verify the identity provider integration |
| V7 Session Management | 6 / 12 / 1 | 7.4.1 (L1): terminated sessions cannot be used again | Applies where sessions exist |
| V8 Authorization | 4 / 3 / 6 | 8.2.2 (L1): data-specific access restricted to consumers with explicit permission, to prevent IDOR and BOLA | Applies to all |
| V9 Self-contained Tokens | 4 / 3 / 0 | 9.1.1 (L1): tokens validated by signature or MAC before their contents are trusted | Where JWTs or similar tokens are used |
| V10 OAuth and OIDC | 5 / 24 / 7 | 10.4.1 (L1): authorisation server validates redirect URIs by exact match against a per-client allowlist | Where OAuth or OIDC is used, by role (client, resource server, authorisation server) |
| V11 Cryptography | 3 / 11 / 10 | 11.3.2 (L1): only approved ciphers and modes such as AES with GCM | Applies to all |
| V12 Secure Communication | 3 / 6 / 3 | 12.1.1 (L1): only the latest recommended TLS versions, such as TLS 1.2 and 1.3 | Applies to all |
| V13 Configuration | 1 / 12 / 8 | 13.3.1 (L2): a secrets management solution such as a key vault for back-end secrets | Applies to all |
| V14 Data Protection | 2 / 7 / 4 | 14.1.1 (L2): sensitive data identified and classified into protection levels | Applies to all |
| V15 Secure Coding and Architecture | 3 / 10 / 8 | 15.1.1 (L1): documented risk-based remediation time frames for vulnerable third-party components | Applies to all |
| V16 Security Logging and Error Handling | 0 / 16 / 1 | 16.3.1 (L2): all authentication operations logged, successful and unsuccessful | Applies to all Tier 1 and Tier 2 |
| V17 WebRTC | 0 / 7 / 5 | WebRTC-specific requirements | Only where WebRTC is used |
5.1 [Organisation] additions to Level 1
ASVS allows organisations to prioritise higher-level requirements earlier based on their own risk. [Organisation] requires the following Level 2 requirements for Tier 3 applications as well, because they address weaknesses seen in our own incidents: [list, for example v5.0.0-13.3.1 secrets management and v5.0.0-13.2.3 no default credentials for service authentication].
5.2 [Organisation] additions beyond ASVS
Requirements not in ASVS that [Organisation] adds are numbered separately with an [ORG-] prefix so they are never confused with ASVS identifiers, for example: [ORG-1 every machine identity used by the application is registered in the NHI inventory with an owner].
6. Tailoring and not-applicable rules
- A chapter or section may be marked not applicable only when the feature it covers does not exist, for example V17 when WebRTC is not used, or V3 for a machine-to-machine API. ASVS itself gives these examples.
- Not-applicable decisions must name the feature that is absent and be approved by [AppSec team]. "Handled by another team" is not a reason; record the owning control instead.
- Where a requirement is met by a shared platform (for example an identity provider or API gateway), record the platform and its own verification evidence; the application inherits it.
- When a not-applicable feature is later added, the application must meet the related requirements before the feature is released.
- The tailored list must keep ASVS identifiers unchanged. ASVS encourages forks provided traceability is kept so a requirement means the same thing across versions.
7. Security documentation
ASVS 5.0 includes documentation requirements, placed in the first section of the relevant chapter, that record an organisation's security decisions and are each paired with an implementation requirement. Examples include authorisation rules (8.1.1), input validation rules (2.1.1), component remediation time frames (15.1.1), the cryptographic key management policy and inventory (11.1.1, 11.1.2), communication needs (13.1.1) and logging inventory (16.1.1). [Organisation] meets these as follows:
- Organisation-wide decisions: [Security architecture team] publishes standard decisions (approved cryptography, password and MFA rules, logging fields, remediation time frames) that applications reference instead of rewriting.
- Application-specific decisions: each application maintains [security design record] covering its authorisation model, validation rules, data classification, external communications and the machine identities and secrets it uses.
- Shared libraries: where decisions are implemented in a mandated common library, the library documentation counts as the decision record, as ASVS allows.
- Verifying the documentation and verifying the implementation are separate checks; both must pass.
8. Verification and evidence
- Tier 1: independent verification against the full tailored list before first release and at least [annually], using documentation and source code-led (hybrid) testing.
- Tier 2: verification before first release and after major changes; automated tests for requirements that can be automated; manual verification of authorisation and business logic requirements.
- Tier 3: self-assessment by the engineering lead, sampled by [AppSec team].
- Report content: following ASVS guidance, a verification report must state the scope, the level targeted, a summary of all requirements checked, the requirements with exceptions or failures, the not-applicable items with reasons, the methods used, and remediation guidance. Pass-by-exception pentest reports are not sufficient.
- Automation: ASVS cautions that off-the-shelf SAST and DAST will not verify many requirements, especially business logic and access control. Write application-specific tests, similar to unit and integration tests, for those requirements.
- Test method reference: testers should use the OWASP Web Security Testing Guide for how to test each requirement. See the OWASP WSTG Guide.
- Claims: no one may describe an application as "OWASP certified". OWASP does not certify vendors, verifiers or software.
9. Exceptions
- A failed requirement that cannot be fixed before release needs a recorded exception with the requirement ID, the risk, compensating controls, the risk owner and an expiry date of no more than [6] months.
- Exceptions for Tier 1 applications and renewals beyond [12] months need [Risk committee] approval.
- Failures with a severity of [High] or above under the [bug bar] cannot be excepted for internet-facing applications without [CISO] approval.
- Exceptions are tracked in [exception register] and reported monthly. See the Remediation SLAs and Vulnerability Exceptions Guide.
10. Maintenance and version control
- [AppSec team] reviews this baseline at least annually.
- ASVS uses Major.Minor.Patch releases. A major release (for example 4.0.3 to 5.0.0) can change requirement numbers and requires re-evaluation; a minor release may add or remove requirements; a patch release only removes or relaxes requirements. [Organisation] will publish a crosswalk and transition period of [6] months for each major or minor release.
- All references in tickets, tests and reports use versioned identifiers (
v5.0.0-x.y.z).
Implementation guidance
- Inventory and tier first: list in-scope applications and assign tiers with application owners. Expect most business applications to land in Tier 2, which matches ASVS's view that most applications should strive for Level 2.
- Build the tailored list: start from the ASVS 5.0.0 CSV or JSON, add tier columns, mark chapter-level applicability rules, and add any [ORG-] requirements. Keep it in version control.
- Publish shared decisions: write the organisation-wide documentation that ASVS documentation requirements expect, so teams reference rather than reinvent.
- Pilot with two applications: one Tier 1 and one Tier 2. Measure how long tailoring and verification take and adjust tiers or additions before wider rollout.
- Turn requirements into backlog items and tests: each applicable requirement becomes an acceptance criterion; where possible, a test that runs in CI.
- Verify and report against the list: require verifiers to report every requirement, not only failures.
- Measure: track percentage of applications with an assigned tier, percentage of applicable requirements passing per tier, open exceptions by age, and failures by chapter. Repeated failures in one chapter usually mean the shared decision or library is missing.
Identity-heavy chapters (V6 to V10) deserve particular care because they also govern the application's own machine credentials and integrations. See the Secrets Management Guide for how requirements such as 13.3.1 are met in practice.
Related NHI Mgmt Group resources: OWASP ASVS Guide · OWASP WSTG Guide · Threat Modelling Guide · Secure Code Review Guide