Write an application security policy as a short set of decisions and owners: which applications it covers, which changes need review, how a claim becomes fix work, who can accept a delay, what evidence closes an issue, and when the policy is revisited. Put language- or framework-specific requirements in linked standards and checklists. A policy that says only “scan code and fix critical issues” leaves every hard decision to the person under release pressure.
The right text depends on your application's data, architecture, and obligations. This article provides a filled example to adapt, not a compliance certification or legal opinion. OWASP SAMM's Policy and Standards practice recommends broad, technology-independent policies with more specific, team-reviewed standards underneath. NIST's SSDF 1.1 offers a common secure-development vocabulary, but an organization still needs to decide how its own lifecycle implements it.
Collect the facts before writing requirements
Ask the engineering sponsor and service owners for an application inventory, data classifications, deployment boundaries, release path, existing review and incident processes, and who can authorize exceptions. Confirm where a security concern is reported today and whether engineering can reserve review and fix time. If these facts are missing, list the owner who will resolve each one. Do not write “all repositories” when nobody knows whether that includes archived experiments or a shared package used by production.
Decide which document has authority. The policy should state the outcomes that must be met. A standard can describe, for example, how the team's web services enforce resource-level authorization; a playbook can tell a reviewer where to record evidence. OWASP's ASVS project provides web application verification requirements that a team may select for an applicable application and version. Refer to an exact version and selected scope; linking to ASVS is not proof that every requirement was assessed or met.
A filled, copyable policy
Illustrative company and policy, not a customer document: Riverton Analytics is a B2B SaaS company with one AppSec lead, a Head of Engineering, and several service teams. It handles customer reports and exports. The sample below is deliberately short enough for a team to review in a meeting. Replace its names, scope, decision rights, and timing before adoption.
Riverton application security policy — version 1, effective only after internal approval
Purpose and scope. We protect customer data and service integrity across deployed applications that Riverton builds or maintains. The application inventory names each service, its owner, repositories, data classes, external entry points, and significant shared controls. Experimental and retired systems are labeled, with production reach verified rather than assumed. The security lead maintains the inventory with service owners.
Change review. A service owner requests a focused security review before launching a new external entry point, changing authentication or authorization, adding a new customer-data flow, or changing a shared control used by more than one service. The review records the proposed actor, protected action or data, enforcement point, selected scope, and any unresolved deployment fact. Ordinary changes follow the team's established review checklist; a scanner result is evidence to examine, not release approval by itself.
Unavailable review and emergency changes. If a triggered pre-release review cannot finish, the service owner holds the affected release or proposes a bounded release exception. AppSec records the unanswered question without asserting a vulnerability verdict. Head of Engineering authorizes release only after Head of Product separately approves the stated business risk, affected scope, interim restriction and expiry. Emergency containment may be authorized by the on-call incident commander under the incident procedure; the service owner supplies the change record and schedules retrospective review by the next business day. Emergency authority does not grant an indefinite review waiver.
Assessment record. Every assessment identifies the application, immutable revision, selected paths and controls, reviewer, method, actual coverage, exclusions, and unresolved questions. File discovery, indexing, a scan run, and examination are reported separately. A partial review is reported as partial. No assessment states that an application is vulnerability-free because no alert appeared.
Finding decision. A qualified reviewer checks a proposed issue against the affected revision and relevant controls. Consequential, disputed or unfamiliar claims receive independent challenge; routine supported repairs follow normal code review. The AppSec lead maintains the evidence standard. Repair or containment may proceed while non-decisive exposure questions remain open. The record states the possible harmful action, actor, entry, failed or missing control, effect, practical prerequisites, counterevidence, and uncertainty. Unresolved claims keep their evidence status and next check even when a precautionary repair is assigned. Rejected claims retain the reason and evidence; any separately justified hardening task states its own purpose.
Priority and response. The service owner and Head of Engineering schedule verified work using business impact, practical exploitation difficulty, exposure, confidence, fix effort, and other commitments. Suspected urgent customer-data exposure is reported to the incident owner immediately, including what is unknown; urgency does not by itself verify the finding. The sponsor resolves scheduling disputes. A severity label alone does not set a delivery date.
Fix and closure. The developer names the changed revision and intended control. A reviewer checks the original harmful path and relevant alternate paths at the new revision, using an authorized environment when runtime validation is needed. A merged patch or missing scanner alert does not close the issue. Record fixed, still present, or inconclusive, with the evidence and remaining risk.
Exception. If a verified issue cannot be fixed on the agreed schedule, the Head of Engineering names a service risk owner, affected scope, reason, interim control, review date, and expiry. The AppSec lead records the technical facts and checks whether the interim control is evidenced. The Head of Product is this policy's business risk authority and must approve or renew the exception separately from the service risk owner. An exception changes the plan; it does not reclassify the code as fixed.
Access and retention. Technical details go only to people who need them for review and remediation. Executive status uses a separate summary without source or exploit instructions. Source, reports, logs, and exports follow the approved data-handling standard; this policy does not claim a particular tool's storage or deletion behavior.
Review. The AppSec lead and Head of Engineering review this policy every six months and after a material incident or architecture change. They publish a versioned change note, notify service owners, and update the linked technical standards and review checklist.
The example is a starting point. Riverton still needs a service catalogue, incident contacts, technical standards, and an exception register. If it promises a review before every minor code change without staffing that review, the policy will be bypassed. If it omits the scope and evidence record, “we assessed the application” will mean different things to security, engineering, and a customer.
Tabletop the policy before adopting it
Riverton's policy is an illustrative governance choice, not an external requirement. Test its wording with three requests a manager could actually receive. The useful output is the decision and the clause that makes it possible.
Request 1: “A copy change touches the account screen. Does security approve it?” The diff changes explanatory text; the reviewer confirms that it does not change a permission, data flow, external entry or shared control. Ordinary code review applies. The record is: “Change-review trigger not met; normal owner review; reassess if scope changes.” Calling every account-screen edit a security review would consume the capacity needed by request 2.
Request 2: “The partner export launches tomorrow, but the shared-service reviewer is away.” This is a new external entry and customer-data flow, so the trigger is met. The service owner knows the caller is authenticated but cannot yet show where each exported object's account is checked. “No alerts” does not answer the question. The verified-vulnerability exception clause is also the wrong mechanism: there is no supported finding to accept yet.
The unavailable-review clause makes the actual choice explicit. In this exercise, Product chooses to delay partner export rather than approve an uncertain data-access release. Head of Engineering records the release hold; AppSec requests the shared read and route binding; the service owner books Monday's reviewer. The underlying feature remains unassessed in that respect. If leadership instead approved a restricted release, the record would need its real audience limit, effective control evidence, expiry and both designated approvals. It could not say “risk reviewed” merely because the release exception was signed.
Request 3: “An export endpoint may be exposing data; the on-call engineer can disable it now.” Waiting for the next business-day review would defeat the emergency route. The incident commander authorizes the narrow restriction under the incident procedure and owns the response. The service owner records the deployed change and its effect on legitimate exports. AppSec checks the suspected path while the service remains restricted. The next-business-day review determines what can be restored; it does not retrospectively certify facts that were unknown during containment.
Before this exercise, a tempting policy sentence might have been “All security changes require review before deployment.” It cannot distinguish a harmless screen edit, a missing launch review and urgent containment. The finished policy instead names a trigger, an owner, a decision and the exceptional route. That specificity lets the team operate it without quietly bypassing the document.
Finally, check a mundane failure: the named Head of Product is on leave. Riverton must name an authorized delegate in its maintained authority register before relying on the exception path. A service owner cannot become the business approver simply because a deadline is near.
Keep the policy stable and the standards specific
Technology changes faster than governance. A policy can say that access to customer resources must be checked for the specific resource and current actor; a standard can show how that rule is implemented in a particular framework and how it is verified. A policy can require an assessment's actual scope to be stated; a playbook can define the exact coverage fields. Review standards with senior developers so the instructions are feasible and the evidence is interpretable. OWASP SAMM explicitly recommends product-team feedback and versioned, linked standards.
When using ASVS or another control set, record the version, selected levels or requirements, applicability, and whether the relevant component was actually examined. Do not turn “ASVS referenced” into “ASVS compliant.” If a legal, regulatory, or contractual requirement is part of the policy, have the appropriate legal or compliance owner decide applicability and wording. The template cannot do that interpretation for them.
Publish only what the organization can operate
Pilot the policy with one service for a month. Count triggered reviews, completed decisions, unresolved facts, and fixes positively reassessed. Ask the service team which rule was ambiguous or costly and revise its guidance. A useful policy should help a busy engineer know who to call and what evidence to bring during a release, including when the answer is “we do not know yet.”
To adapt the sample today, replace Riverton's service scope, accountable roles, change triggers, incident contact, exception authority, and review interval. Then run one ordinary change, one new trust boundary and one emergency repair through the tabletop above. If the hard question is how often to meet or who has capacity, use the sustainable review cadence. For exception wording and expiry, continue with the risk-exception guide.