Who is accountable for prioritising exposure remediation when new vulnerabilities appear between assessments?

Who owns the window between scans and the next breach?

Exposure management fails most often in the gap between formal assessments, when a newly disclosed vulnerability can be exploitable long before the next scheduled review. Accountability sits with the leaders who own security governance and remediation execution, because they must ensure findings are triaged, contextualised, and prioritised according to business exposure rather than raw ticket counts. NIST’s control set on ongoing assessment and risk response is useful here because it treats vulnerability handling as a continuous accountability problem, not a periodic report. NIST SP 800-53 Rev 5 Security and Privacy Controls

In practice, many security teams encounter avoidable compromise only after ownership gaps, asset ambiguity, and escalation delay have already allowed an exposed system to remain reachable.

How remediation prioritisation actually works between assessments

The practical answer is that accountability should be explicit, but prioritisation should be driven by validated exposure context. A vulnerability score by itself rarely tells you whether a flaw is exploitable in your environment. Teams need to know whether the affected asset is internet-facing, whether compensating controls exist, whether the service is business critical, and whether the weakness is already visible to adversaries. That is why remediation workflows should combine vulnerability data, asset inventory, identity and privilege context where relevant, and operational criticality.

Security leaders usually own the policy and the escalation path. Platform, application, infrastructure, or product owners usually own the fix. Risk owners decide when exposure can be deferred, accepted, or isolated. That division matters because “security” cannot realistically patch every issue alone, but neither can application teams decide priority without a risk frame. Where there is no named owner, remediation tends to stall even when the issue is severe.

A useful operating model is to triage new findings as soon as they appear, then separate them into immediate containment, near-term remediation, and monitored exception. That process should be continuous, not tied to the next scheduled assessment cycle. If the organisation waits for the next audit or scan window, the exposure management programme has already become reactive.

• Validate asset ownership before assigning the fix.
• Confirm whether the weakness is reachable or already exploited in the wild.
• Prioritise internet-facing, privileged, or business-critical exposure first.
• Use exception handling only when the compensating control is demonstrable.

This guidance breaks down when inventories are stale, ownership is unclear, or the organisation cannot distinguish theoretical severity from reachable exposure.

Where ownership gets blurred, and what good governance looks like

Tighter exposure governance often increases coordination overhead, requiring organisations to balance speed of remediation against the friction of accurate ownership and validation. The common mistake is to treat prioritisation as a vulnerability management team problem alone. That approach works for reporting, but not for reducing exposure. The remediation decision often spans security, IT operations, engineering, and business ownership, especially when the affected service supports multiple products or shared infrastructure.

There is also a genuine trade-off between speed and certainty. Fast action is appropriate when the vulnerability is actively weaponised or the asset is highly exposed. More context is needed when the finding is low reachability, behind compensating controls, or tied to a system with limited blast radius. Good governance does not mean every issue is fixed immediately; it means the organisation can explain why one issue outranks another and who approved that order.

For questions of accountability, the strongest practice is a named owner, a documented triage rule, and an exception path that can survive review. That is especially important when a new vulnerability appears between assessments, because the absence of a fresh scan does not remove the obligation to act. In mature programmes, the question is not whether the team saw the finding first, but whether the organisation can move from detection to decision without delay.

Practitioner takeaway: accountability should sit with leadership, but prioritisation must be grounded in exposure reality, because raw severity without asset context produces busy work rather than risk reduction.

Related resources from NHI Mgmt Group

• Who is accountable for reducing exposure risk between security assessments?
• How should security teams prioritise NHI remediation in cloud environments?
• What is the difference between attack surface management and NHI governance?
• What is the difference between reviewing human access and reviewing NHIs?