Without an application security policy, every team decides for itself how much security testing is enough, how fast vulnerabilities must be fixed and which risks may be accepted. This template gives you a top-level policy that sets those rules for every application [Organisation] builds, buys or operates. It follows NIST SP 800-218 (SSDF) practice PO.1, which asks organisations to define and maintain security requirements for software development, and uses OWASP ASVS 5.0 verification levels to scale requirements by risk. The detailed lifecycle procedure belongs in a separate secure SDLC policy or standard; this policy sets the mandate, the risk tiers, the minimum controls and the accountability. Adapt the wording, roles and timeframes, and have it reviewed by your legal, risk and compliance teams before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [AppSec team] and [CISO], with your own terms.
- "Must" indicates a mandatory requirement; "should" indicates a recommended practice where documented exceptions may be justified.
- Timeframes in section 9 are starting points. Set them from your risk appetite and contractual and regulatory obligations, for example PCI DSS for payment applications.
- Keep procedures out of the policy. Link each statement to the standard or procedure that implements it, such as the Secure SDLC Policy Template and the Vulnerability Management Policy Template.
- Review the policy at least annually and after any significant application security incident.
1. Purpose
This policy sets the minimum security requirements for the design, development, acquisition, testing, deployment, operation and retirement of applications at [Organisation]. It ensures that security requirements are known throughout the software lifecycle, that applications are protected in proportion to their risk, and that vulnerabilities are found and fixed within defined timeframes.
2. Scope
This policy applies to:
- All applications, APIs, services, mobile apps, scripts and infrastructure as code developed by or for [Organisation], including by contractors and outsourced developers.
- Commercial and open source software components incorporated into those applications.
- Commercial off-the-shelf and SaaS applications that process [Organisation] data classified as [Confidential] or above, for the requirements in section 10.
- Low-code and no-code applications and automations built by staff.
- AI features and AI agents embedded in applications, and AI tools used to develop software.
- All employees, contractors and third parties who design, build, test, deploy, operate or approve these applications.
3. Definitions
- Application: any software that [Organisation] develops, configures or operates to deliver a business function, including its APIs and supporting components.
- Application owner: the named business or product owner accountable for an application's risk.
- Risk tier: the classification in section 5 that determines required controls.
- ASVS level: an OWASP Application Security Verification Standard 5.0 verification level (1, 2 or 3).
- Security-relevant change: a change to authentication, authorisation, cryptography, data handling, external interfaces or trust boundaries.
- Secret: a password, API key, token, private key, certificate or other credential used by a person or a non-human identity.
4. Roles and responsibilities
| Role | Responsibilities |
|---|---|
| [CISO] | Owns this policy, approves high-risk exceptions, reports application security risk to [Executive committee] |
| [AppSec team] | Maintains supporting standards and tools, sets testing criteria, triages findings, runs training, reviews high-risk designs |
| Application owner | Classifies the application, accepts residual risk within delegated limits, funds remediation |
| Engineering manager | Ensures teams follow this policy, protects time for training and remediation |
| Developers | Write code to the secure coding standard, fix findings within timeframes, complete required training |
| Security champions | Act as the first point of contact for security within their team |
| Procurement and vendor management | Include application security requirements in contracts for software and development services |
5. Application risk classification
5.1 Every application must be recorded in the application inventory with an owner, risk tier, data classification, internet exposure and technology stack.
5.2 Application owners must classify applications using the following tiers and reclassify on significant change:
| Tier | Typical criteria | Minimum ASVS level |
|---|---|---|
| Tier 1 (critical) | Processes payment, health, authentication or [Restricted] data; internet-facing with high transaction value; safety or regulatory impact | Level 3 for critical functions, Level 2 elsewhere |
| Tier 2 (high) | Processes [Confidential] or personal data, or is internet-facing | Level 2 |
| Tier 3 (standard) | Internal only, no sensitive data | Level 1 |
6. Security requirements
6.1 [AppSec team] must identify, document and maintain security requirements for applications and for the development infrastructure and processes, including requirements from laws, regulations and contracts (SSDF PO.1.1 and PO.1.2).
6.2 Each application must meet the OWASP ASVS 5.0 level set for its tier in section 5, or an internal standard derived from it.
6.3 Security requirements must be communicated to third parties who provide software components or development services (SSDF PO.1.3).
6.4 Applications must use [Organisation]'s approved identity provider for workforce authentication and approved libraries for authentication, authorisation, cryptography and input handling where available.
7. Secure design and development
7.1 Tier 1 and Tier 2 applications must have a documented threat model, created before first release and updated on security-relevant change.
7.2 Developers must follow the [Secure coding standard] for their language and framework.
7.3 All code changes to Tier 1 and Tier 2 applications must be reviewed and approved by at least one person other than the author before merge.
7.4 Source code repositories must enforce multi-factor authentication, branch protection on release branches and least-privilege access.
7.5 Development, test and production environments must be separated, and production data must not be used in non-production environments without approved masking.
7.6 Personnel with development responsibilities must complete role-based secure development training on joining and at least annually. See the Developer Security Training Programme Guide.
8. Security testing and release
| Activity | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Static analysis (SAST) in CI | Every change, blocking on critical and high | Every change, blocking on critical | Every change |
| Software composition analysis (SCA) | Every build, blocking on known exploited and critical | Every build, blocking on known exploited | Every build |
| Secret scanning with push protection | Required | Required | Required |
| Dynamic or API testing (DAST) | Each release | Quarterly and on major change | Annually |
| Penetration test | Annually and on major change | Every [24] months or on major change | Risk-based |
| SBOM produced and stored | Every release | Every release | Should |
8.1 Releases must be built by the approved CI/CD system, not from developer workstations, and release artefacts must be signed or have verifiable integrity.
8.2 A release must not proceed with open findings that breach section 9 timeframes unless an exception under section 13 is approved.
8.3 Deployed applications must not expose source control metadata, debug interfaces or default credentials.
9. Vulnerability management
9.1 Vulnerabilities in applications and their components must be remediated or mitigated within the following timeframes from confirmation:
| Severity | Internet-facing or Tier 1 | Other |
|---|---|---|
| Critical, or listed in the CISA Known Exploited Vulnerabilities catalogue | [7] days | [14] days |
| High | [30] days | [60] days |
| Medium | [90] days | [120] days |
| Low | Next planned release | Next planned release |
9.2 [Organisation] must publish a vulnerability disclosure policy and a route for external researchers to report vulnerabilities.
9.3 Root cause analysis must be performed for critical vulnerabilities and for recurring vulnerability classes, and results fed into standards and training (SSDF RV.3).
10. Third-party components and software
10.1 Open source and commercial components must be obtained from approved registries, recorded in the SBOM and kept within supported versions.
10.2 Components that have breached their documented update and remediation timeframes must be upgraded or replaced.
10.3 Contracts for software development and for SaaS applications in scope must include security requirements, vulnerability notification duties and the right to receive evidence of testing.
11. Secrets and non-human identities
11.1 Secrets must not be stored in source code, configuration files in repositories, container images, logs or tickets.
11.2 Applications must obtain backend secrets from an approved secrets management solution and must use workload identity federation instead of static keys where the platform supports it.
11.3 Each application and service must use its own non-human identity with least-privilege permissions and a named owner. Shared service accounts between applications are prohibited.
11.4 Any exposed secret must be revoked and rotated immediately, whether or not misuse is confirmed. See the NHI Policy Template.
12. AI-assisted development and AI features
12.1 Only AI coding tools approved by [AppSec team] may be used on [Organisation] code, with configurations that prevent training on [Organisation] code where available.
12.2 AI-generated code is subject to the same review, testing and licence requirements as other code.
12.3 Applications that embed large language models or AI agents must address the OWASP Top 10 for LLM Applications in their threat model, and agents must follow the Agentic AI Security Policy Template or its adopted equivalent.
13. Exceptions
13.1 Exceptions must be requested in writing with the business justification, compensating controls, risk rating and expiry date (maximum [6] months, renewable).
13.2 Application owners may approve exceptions for medium and low risk; [CISO] must approve exceptions for high and critical risk.
13.3 [AppSec team] must maintain an exception register and report expiring and expired exceptions monthly.
14. Compliance and review
14.1 Compliance with this policy is monitored through CI/CD tool evidence, the application inventory, the exception register and periodic audits.
14.2 Breaches of this policy may result in release blocks, revocation of repository access or disciplinary action under [HR policy].
14.3 This policy is reviewed at least annually by [CISO]. Version: [1.0]. Approved by: [Name, role]. Date: [date].
Implementation guidance
- Start with the inventory and tiers: section 5 drives everything else. Without an owner and tier for each application, testing and timeframes cannot be enforced.
- Use ASVS for requirements: OWASP ASVS 5.0 organises requirements into chapters from V1 Encoding and Sanitization to V17 WebRTC, including V6 Authentication, V8 Authorization, V10 OAuth and OIDC, V13 Configuration and V15 Secure Coding and Architecture, with each requirement assigned to Level 1, 2 or 3. Select the level per tier and publish the resulting checklist. ASVS V13.3.1 (use a secrets management solution) and V15.2.1 (components within documented remediation timeframes) underpin sections 11.2 and 10.2.
- Enforce in the pipeline: encode section 8 as CI gates so compliance is the default; measure gate bypasses rather than relying on attestations.
- Map to frameworks: the policy supports SSDF PO.1 (security requirements), PO.2 (roles and training), PW.7 and PW.8 (code review and testing), PS.2 (release integrity) and RV.1 to RV.3 (vulnerability response); NIST SP 800-53 SA-3, SA-8, SA-11 and SA-15; CSF 2.0 PR.PS-06; and ISO/IEC 27001:2022 Annex A 8.25 to 8.29 (secure development lifecycle, application security requirements, secure architecture, secure coding and security testing).
- Measure: track the share of applications with an owner and tier, findings past timeframe by tier, mean time to remediate critical findings, gate bypasses per month, open exceptions and secrets-detection hits.
- Roll out in phases: apply to Tier 1 applications first with gates in warning mode for one release cycle, then blocking mode; extend to Tier 2 and Tier 3 over the following two quarters.
- Further reading: see the Application Security Guide, the Secure Software Development Lifecycle (SSDLC) Guide and the NIST Secure Software Development Framework (SSDF, SP 800-218) Guide.
Related NHI Mgmt Group resources: Secure SDLC Policy Template · Vulnerability Management Policy Template · Information Security Policy Template · Application Security Guide