Who is accountable for fixing vulnerabilities when security teams identify the risk but IT teams do most of the remediation?

Who Owns Vulnerability Remediation When Security Flags the Risk?

The clean answer is that accountability should be explicit, not implied by whichever team discovered the issue. Security can own risk identification, prioritisation and escalation, while IT or platform teams often own implementation. If nobody has decision rights and deadlines, findings sit in limbo. The governance problem is not the split itself, but the absence of a named owner for closure.

How the Security and IT Split Should Work in Practice

A workable model separates risk-based vulnerability management from remediation execution. Security should define severity, business context, and due dates; IT should execute patches, configuration changes, or compensating controls; and asset owners should confirm that the change actually reduces exposure. When the same team is expected to both assess and fix everything, prioritisation becomes inconsistent and remediation slows.

That division is also why remediation SLAs and vulnerability exceptions matter. A target date is only useful if it is tied to a workflow that shows who must act, when exceptions are allowed, who approves them, and when the exception expires. Without that structure, “security said it was critical” and “IT never got the change window” become competing narratives instead of a managed process.

In larger environments, vulnerability management works best when intake, triage, fix, validation and reporting are treated as one lifecycle. Security teams should not be reduced to ticket creators, and IT teams should not be left guessing whether a finding is advisory or mandatory. Clear ownership makes it possible to measure backlog age, overdue items and exception drift.

Where Accountability Usually Breaks Down

Accountability fails most often when responsibility and authority are split unevenly. Security may be held responsible for the outcome, but lack the authority to schedule work, consume maintenance windows or force remediation across infrastructure owned by another team. In that situation, the “owner” is only nominally accountable, and the real blocker is organisational control over change.

A second failure mode is ambiguous handoff. If the finding is handed to IT without a named resolver, an agreed due date and a validation step, the ticket can be reopened, reassigned or ignored until audit pressure appears. That is why a plan of action and milestones style register is useful when remediation spans multiple teams: it turns shared work into visible commitments with deadlines and status.

The other common problem is exception creep. Teams sometimes label a delayed fix as “accepted risk” without documenting compensating controls, expiry or renewal criteria. That turns a temporary workaround into a permanent control gap and makes it impossible to tell whether the exposure is being reduced or merely deferred.

Risk and Threat Considerations

Delayed or disputed ownership increases exposure because exploitable findings can remain open long enough for attackers to target them, especially when the issue is already known and externally visible. The risk is not just that a vulnerability exists, but that the organisation cannot prove who must act before the exposure becomes an incident.

Failure mechanism: security identifies the issue, IT controls the fix path, and neither side has enforced decision rights, so remediation stalls in ticket queues, exception registers or change windows.

Impact: attackers gain a longer exploitation window, the organisation accumulates unclosed exposure, and leadership loses a defensible record of accountability for risk treatment.

Practitioner Guidance

What to verify: every material vulnerability should have one named business owner, one named remediation owner, a due date and a validation step. If any of those four elements is missing, the issue is not really assigned, even if a ticket exists.

Decision rule: if security can define the risk but cannot drive the fix, governance must specify who can approve the change, who can reject the exception, and who must escalate overdue remediation. If that authority is undefined, the organisation will default to delay.

Common mistake: treating “security owns risk” as equivalent to “security owns remediation.” Risk ownership and implementation ownership can be different, but final closure still needs a single accountable decision-maker.

Practitioner takeaway: the split between risk ownership and fix ownership is acceptable only when the workflow makes one person or function clearly accountable for closure, not just for reporting the problem.

Related resources from NHI Mgmt Group

• Who is accountable when a vendor’s security score drops and remediation is triggered in a third-party risk workflow?
• Why does the accountability gap between security and remediation teams create so much delay in fixing vulnerabilities?
• How should security teams prioritise remediation when an EHR application has multiple high-risk web vulnerabilities at once?
• How should security teams reduce breach risk when known vulnerabilities and credential abuse remain the main entry paths?