Resolution latency is the time between a vulnerability being identified and a safe fix being merged into production code. It is a useful governance metric because it captures how long exposure remains active after discovery, which is often more important than the scanner that found it.
Expanded Definition
Resolution latency describes the elapsed time from confirmed vulnerability discovery to the point where a safe remediation is merged into production code. At NHI Management Group, this is treated as a governance metric, not just an engineering statistic, because it measures how long exploitable exposure remains active after it is known. It differs from detection latency, which measures how long it took to notice the issue, and from deployment latency, which measures how long it takes to roll a fix out after approval.
The term is most useful when teams need to compare risk across product lines, service tiers, or remediation workflows. A short resolution latency usually indicates clear ownership, fast triage, and a dependable release path. A long one often points to missing decision rights, weak change control, or dependence on manual approval gates. The concept maps well to governance language used in the NIST Cybersecurity Framework 2.0, especially where risk response and recovery discipline depend on timely corrective action.
Definitions vary across vendors when they blur the line between “fixed in a branch” and “safely merged to production.” For glossary use, the safer interpretation is the latter, because unresolved deployment and release risk still leaves exposure open. The most common misapplication is treating a code commit as closure, which occurs when the patch has not yet passed review, testing, or release into the running environment.
Examples and Use Cases
Implementing resolution latency rigorously often introduces measurement overhead, requiring organisations to balance operational clarity against the cost of tracking each stage of remediation.
- A security team records the timestamp when a critical library flaw is verified, then closes the metric only after the patched version is merged, tested, and scheduled for release.
- An engineering org compares resolution latency across squads to identify where dependency management, review queues, or release freezes are delaying fixes.
- A cloud platform team links resolution latency to change windows so that urgent patches do not sit in approval backlog after validation.
- A product security program uses the metric to distinguish fast-moving cosmetic issues from high-risk flaws in internet-facing services, guided by the same corrective action mindset reflected in NIST Cybersecurity Framework 2.0.
- A compliance team reviews whether high-severity vulnerabilities are being resolved within internal service-level targets, especially where third-party components or release governance slow the path to production.
These examples show why the metric matters most where release mechanics are complex. If a fix is technically ready but cannot safely move through testing, sign-off, or deployment, the exposure window remains open even though the engineering work appears complete.
Why It Matters for Security Teams
Resolution latency matters because it turns vulnerability management into a time-based governance problem. If teams only count whether a fix exists, they can miss the period in which attackers still have an opportunity to exploit known weaknesses. That is especially important in environments with shared services, CI/CD pipelines, and reusable components, where one delayed fix can affect many downstream systems.
For security teams, the metric helps answer practical questions: Where do fixes stall? Which approvals are slowing risk reduction? Are the most serious issues actually leaving production fast enough? In identity-heavy environments, the same logic applies to secrets, service accounts, and non-human identity dependencies when a vulnerable component supports authentication or orchestration workflows. The metric also helps separate a developer’s intent to remediate from the operational reality of a safe production change.
Organisations typically encounter the real impact only after a disclosed vulnerability is exploited while the fix is still waiting in the release queue, at which point resolution latency becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022, NIS2 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MI-3 | CSF addresses timely response and remediation, which directly frames resolution latency. |
| NIST SP 800-53 Rev 5 | RA-5 | RA-5 covers vulnerability scanning and remediation, the workflow measured by this term. |
| ISO/IEC 27001:2022 | A.8.8 | ISO 27001 expects technical vulnerability management with timely corrective action. |
| NIS2 | NIS2 emphasizes cyber risk management and timely mitigation for critical exposures. | |
| PCI DSS v4.0 | 6.3.3 | PCI DSS requires prompt remediation of security vulnerabilities in system components. |
Document vulnerability handling so fixes are prioritized, tracked, and released without unnecessary delay.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
