Won’t Fix Decision

Expanded Definition

A won’t fix decision is a recorded risk acceptance choice, not a denial that a weakness exists. In security operations, it is used when the issue has been validated, the potential impact is understood, and leadership concludes that remediation is not proportionate to the current business value, operational constraint, or existing compensating controls. The decision should be specific enough to survive later review: what was found, what was assessed, who approved it, and when the justification expires. That makes it distinct from informal tolerance, backlog deferral, or simply ignoring a finding.

In mature governance programs, a won’t fix decision usually sits alongside exception management, risk registers, and control attestations. It is also closely related to control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where organisations are expected to select, assess, and maintain controls with clear accountability. Industry usage is still evolving around how much evidence is enough, but the core expectation is consistent: the decision must be deliberate, documented, and reviewable. The most common misapplication is treating “won’t fix” as a permanent dismissal of a finding, which occurs when teams omit expiry dates, compensating controls, and named approvers.

Examples and Use Cases

Implementing a won’t fix decision rigorously often introduces review overhead, requiring organisations to balance operational speed against the risk of normalising exceptions.

• A low-severity misconfiguration is left unremediated because a layered control already reduces exposure and the fix would destabilise a production workflow.
• An application dependency with a known issue is accepted temporarily because the vendor patch would break a critical integration, and the risk owner documents the compensating monitoring in place.
• A legacy system cannot be updated immediately, so the team records a formal exception with compensating network restrictions and a dated reassessment point.
• An audit finding is classified as won’t fix after the business proves the affected asset is isolated, low impact, and scheduled for retirement before the next review cycle.
• A security tool flags a control gap, but the organisation can demonstrate that another control satisfies the underlying risk objective and captures that rationale in the exception record.

For governance teams, the distinction matters because the same pattern can be a valid risk acceptance in one context and a control failure in another. Under the logic of security control management described by NIST SP 800-53 Rev 5 Security and Privacy Controls, the record must show why the residual risk was considered tolerable.

Why It Matters for Security Teams

Security teams rely on won’t fix decisions to prevent exception debt from becoming invisible. Without a formal process, unresolved findings can be mistaken for accepted risk, which weakens auditability, undermines accountability, and makes it harder to prove whether compensating controls are actually functioning. That is especially important when findings affect privileged access, cloud configurations, secrets handling, or agentic systems that can make changes autonomously: in those cases, an untracked exception can create a control gap far larger than the original issue.

This term also matters because it creates a governance boundary between remediation and acceptance. If a team cannot explain the business condition that justified the decision, the “won’t fix” label becomes a shortcut for deferred work rather than a defensible risk choice. Organisations typically encounter the cost of that ambiguity only after an incident, audit challenge, or control failure, at which point the won’t fix decision becomes operationally unavoidable to reconcile.

Related resources from NHI Mgmt Group

• What is the core decision loop Agentic AI follows and why does it create security risk?
• How do teams decide which IAM findings to fix first?
• How should security teams separate access review visibility from decision rights?
• What breaks when audit logs do not capture agent delegation and decision context?