A won't fix decision records a real vulnerability that the organisation chooses not to remediate immediately because the residual risk is acceptable. That decision should be tied to compensating controls, documented context, and a reviewable rationale rather than simple backlog pressure.
What a "Won't Fix" Decision Means in Security Governance
A won't fix is not the same as ignoring a finding. It is an explicit governance choice to accept the vulnerability for now, usually because the residual risk is judged lower than the cost, disruption, or uncertainty of immediate remediation.
The decision only holds up when it is traceable: the risk owner understands the issue, the rationale is documented, and the exception has a review date or trigger. Without that, "won't fix" becomes an unowned backlog item rather than a defensible risk decision.
How to Interpret the Decision Record
The key question is whether the record preserves the context needed for future judgment. A sound won't fix entry should identify the asset or control gap, the affected environment, the reason remediation is deferred, and any constraints that make immediate change impractical.
That context matters because the same vulnerability can be acceptable in one environment and unacceptable in another. A production internet-facing system, for example, may not tolerate the same residual exposure that a segmented internal test system can.
What Makes It Defensible
A defensible won't fix decision rests on compensating controls and proportionality. If the organisation is choosing not to remove the flaw, it should be able to show what reduces exposure in the meantime, such as monitoring, access restriction, segmentation, or a control elsewhere in the stack.
It should also be time-bound. Security posture changes as assets, threat activity, business criticality, and attacker economics change, so a once-acceptable exception can become a material exposure later.
Where It Fits in Vulnerability Management
"Won't fix" is one disposition in the broader lifecycle of vulnerability handling, alongside remediation, mitigation, acceptance, and in some programmes, risk transfer. It is most useful when the organisation wants a clear audit trail for a deliberate exception rather than an open-ended deferral.
In practice, the term helps separate true risk acceptance from low-quality process behaviour. A backlog delay may be operationally understandable, but a won't fix should signal an intentional decision, not just unresolved work.
Risk and Threat Considerations
A won't fix decision can leave known exposure in place long enough for threat actors to weaponise it, especially when the issue is externally reachable, widely known, or easy to automate. The risk is not only the vulnerability itself, but the assumption that the environment around it will stay stable.
Failure mechanism: An accepted vulnerability remains exploitable when compensating controls are incomplete, drift over time, or do not actually reduce the attacker path enough to offset the original weakness.
Impact: The result can be compromise, privilege escalation, lateral movement, or repeated audit and governance findings if the exception is not revisited before conditions change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Defines ongoing vulnerability handling and exception-aware risk treatment. |
| CA-5 — Plan of Action and Milestones | Supports documenting deferred remediation and accountability for outstanding security weaknesses. | |
| Recommendation — Track accepted vulnerabilities with reviewable risk decisions and revisit them as conditions change. Record deferred fixes in a tracked plan with owners, milestones, and review dates. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities are Identified and Managed | Anchors the need to identify, assess, and manage known weaknesses rather than leave them informal. |
| GV.RM-01 — Risk Management Strategy | Supports documented risk acceptance decisions within a stated risk strategy. | |
| Recommendation — Classify accepted vulnerabilities and manage them through an explicit risk process. Apply your risk strategy to justify and periodically review accepted vulnerabilities. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | Requires handling technical vulnerabilities through planned treatment and oversight. |
| Recommendation — Document why a vulnerability is deferred and ensure the exception remains controlled. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Covers repeated discovery, prioritisation, and treatment of vulnerabilities over time. |
| Recommendation — Keep exceptions under review and prevent accepted findings from becoming permanent by default. | ||
Practitioner Guidance
Why practitioners should care: Treat won't fix as a formal risk decision, not a storage bin for unwanted work. If the record cannot explain the acceptance rationale in plain terms, the decision is probably too weak to survive review.
Governance implication: The owner, review cadence, and compensating controls should be explicit so the exception remains accountable over time. That keeps the decision aligned with the organisation's risk appetite instead of personal judgement or backlog pressure.
Practitioner takeaway: A good won't fix decision is temporary, contextual, and reviewable, even when the organisation does not plan to remediate immediately.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org