How to make a security exception with an owner and expiry

A security exception is a time-limited decision to carry a specific, understood residual risk while a safer change is delayed or another response is chosen. Give it a named accountable owner and the approval required by your organization's authority model, an exact affected scope, compensating controls that someone has checked, an expiry, and a trigger for earlier review. Keep the underlying issue open until a fix is positively verified. If the issue itself is still uncertain, record an investigation and the missing evidence; do not use an exception to manufacture certainty.

Exceptions are useful when a change is genuinely blocked and the remaining risk can be bounded. They are dangerous when “accepted” becomes a synonym for “the scanner stopped bothering us.” NIST's Secure Software Development Framework, RV.2, calls for enough risk information to plan remediation or another response; its examples include risk acceptance. That permits a decision process, not automatic forgiveness of a vulnerability. This template makes the decision inspectable later.

First decide whether an exception is the right record

Start with the precise issue and its evidence. A scanner alert can be a lead; a source citation proves a line exists, not that an attacker can reach it. Ask who can enter the path, what they control, which check should stop harm, what actually happens, and which deployment is affected. Record counterevidence with the supporting evidence. An unresolved downstream control belongs in an investigation with a due date, even if the suspected impact warrants immediate containment.

Then ask what response is actually being proposed:

The NIST CSF 2.0 enterprise risk guide treats accepting, mitigating, avoiding and transferring risk as distinct responses, and describes a risk register for communicating the chosen response and residual risk. Choose the response in those terms. A traffic filter is mitigation; it does not itself approve the remaining risk. A developer's estimate that a patch is inconvenient does not make them the person authorized to accept customer impact.

Walk through an illustrative exception

Illustrative case, not a customer incident: Alder Metrics has a staff-only report export endpoint. A source review of revision 7c42a1 finds no per-user request quota in the export handler. The team verifies that the production route requires the current staff export permission and that the gateway caps requests per identity. In an authorized staging exercise with synthetic reports, accepted requests still saturate the shared worker below the gateway limit. That supports a resource-exhaustion finding for the tested configuration; the precise production threshold remains unknown. No load attack was run against production.

The durable fix is a per-user export budget and bounded job admission. It needs a worker migration scheduled for the next release. The service owner proposes a 14-day exception. The gateway cap, worker concurrency ceiling and an alert on sustained queue growth reduce exposure in the interim, but they cannot be presented as proof that service degradation is impossible. The business owner accepts that bounded residual risk for the named service and period. If the load threshold cannot be established, the reviewer should make that unknown explicit and shorten the review interval rather than guess a probability.

Here is the filled record. Its thresholds and dates are illustrative policy choices, not values prescribed by NIST:

Exception ID: EX-2026-014; linked finding SEC-38 and fix ticket ENG-412.

Decision: Temporarily accept the residual risk of export-worker saturation from repeated requests by an authorized staff exporter.

Scope: Alder Metrics production report-export route and worker at revision 7c42a1; no other export path or staging environment is covered.

Evidence: Security reviewer traced permission check, handler, queue admission and gateway route; production configuration owner confirmed identity rate limit and worker concurrency ceiling on 18 October 2026. Authorized staging load with synthetic reports reached sustained queue delay below the gateway limit; production load threshold is untested.

Possible effect: Delayed report exports for customers sharing the worker. Practical difficulty requires an authorized staff account and enough accepted requests to consume worker capacity; the threshold remains unknown.

Interim controls: Maintain gateway identity limit and worker ceiling; operations checks a source-free queue-delay alert daily. Alert ownership: on-call platform lead.

Owner and approval: Service owner requests; Head of Product accepts customer delivery risk; AppSec lead reviews evidence and control boundaries. These are different people.

Start and expiry: 18 October to 1 November 2026, 17:00 UTC. At expiry, the exception stops being valid unless a fresh decision is recorded.

Early review triggers: Gateway rule disabled, staff role expanded, queue-delay alert fires, route or worker changes, or a credible abuse report arrives.

Exit evidence: Fix merged at a new immutable revision; reviewer confirms per-user admission on all export paths and checks behavior in an authorized test environment. A quiet alert is insufficient.

Status: Finding remains open; exception active; fix ticket scheduled.

Copy this minimum policy and form

The AppSec lead can adapt the following policy text for the team's risk procedure. The separation of requester, technical reviewer and risk approver used here is a proposed governance choice; neither the job titles nor the number of signatures is a universal requirement. Adjust authorities and time limits to the organization's own governance; do not copy the illustrative 14 days as a universal standard.

Exception policy: An exception may cover one described risk and one bounded scope. The requester supplies evidence, affected assets, possible customer impact, alternative responses, interim controls, owner, fix plan and proposed expiry. A security reviewer checks the technical claim and control evidence. A separately authorized business risk owner decides whether to accept the residual risk. The record remains linked to the open issue. Expiry or an early-review trigger suspends reliance on the approval until a new decision is made. Name the operational response in advance; suspension must not automatically remove a protective control or reopen a restricted feature. Renewal requires fresh evidence, a reason the fix has not landed, and an explicit new approval. Incident escalation can override the ordinary review schedule.

Copyable intake form:

Exception ID / linked finding / linked fix work:
Requester / service owner / business risk owner / technical reviewer:
Exact service, route, environment, revision, users and data affected:
What harmful action could occur, and to whom?
Evidence for actor -> entry -> controls -> effect:
Counterevidence and unresolved assumptions:
Responses considered: fix now / mitigate / avoid / transfer / accept
Why the chosen response is necessary until this date:
Interim controls, proof they are active, and control owner:
Residual impact and practical prerequisites after those controls:
Start, expiry, next review date, and early-review triggers:
Fix owner, milestone, and positive closure evidence:
Reviewer decision / authorized risk-owner decision / timestamps:

Link to controlled evidence rather than pasting private source into a broad risk register. OWASP SAMM Defect Management emphasizes enriching defects for decisions; its metrics stream includes accepted risk. The register exposes repeat deferrals without treating fewer tickets as less risk.

Follow the exception when the facts change

Continue the illustrative record through three dated updates. The staging observation and approvals above are supplied case facts, not work performed for this article.

24 October — the migration slips. Engineering moves the worker migration to 6 November, five days after expiry. This changes the fix plan; it does not automatically extend approval. The service owner requests renewal, attaching the revised dependency and two alternatives: keep the staff export route available longer under current controls, or disable that route at expiry and use an already established manual report process. AppSec records that the saturation path remains open and that the production threshold is still unknown. The original exception remains valid only within its existing scope and triggers while the request is considered.

25 October — “staff” expands. The identity team adds contractors to the staff role. The request cap and worker ceiling have not changed, but one premise of the approved actor population has. This is an early-review trigger even though 1 November has not arrived. Mark the old approval suspended for reliance pending review, and notify the risk owner; do not simply update the description of “staff” in place.

In this exercise, the service owner removes contractor export permission and supplies the effective permission artifact and route binding. AppSec checks that the restricted route actually uses that permission and that no alternate export entry bypasses it. The approver then records a fresh decision for the original staff population through the original expiry. This is an amendment with fresh evidence, not a claim that a role label alone restored the boundary. Any requests accepted during the broader-access interval require separate review under the incident/exposure procedure if warranted.

1 November — the fix is still not ready. Head of Product declines the longer residual-risk period. Before 17:00 UTC, the service owner disables the route and supplies evidence that its live binding no longer admits new export requests. Operations separately checks queued work and retained download artifacts; switching off admission does not prove those have disappeared. Assume those checks find no remaining queued work for this feature and confirm retained artifacts follow the ordinary authorized-download policy. The record can then say the new-request saturation path is unavailable in that deployment, while the underlying code repair remains scheduled. It cannot say “quota fixed.”

The completed decision log is short:

When the migration ships, the service owner must request restoration and provide evidence for per-user admission, legitimate workloads and alternate entry paths. Restoring the route is a new operational decision. An expired exception, a silent alert or a completed migration ticket does not supply that evidence.

Keep renewal evidence smaller than a new application review

Renewal should concentrate on the assumptions that justify carrying the residual risk. For EX-014, compare the actor population, effective gateway cap, worker ceiling, queue behavior, current release and repair milestone. A change in any of those can invalidate the old decision; unchanged background documentation need not be rewritten merely to create a fresh-looking packet.

Ask the owner why the delay changed and what specific work the renewed period will buy. “Still busy” does not identify a path to exit. A useful request names the migration dependency, the reserved implementation slot and the evidence needed for restoration or closure. If those commitments do not exist, the approver is deciding whether to continue an open-ended condition and should see that plainly.

Retain declined renewals too. They explain why a route was restricted and what must be established before anyone restores it. The exception register is part of operating history, not just a list of current permissions to defer.

For the next real request, fill the scope and early-review fields before proposing a date. Use the backlog workflow to preserve the open issue and the planning guide to fund the work that ends the exception.