Accountability should sit with the service owner, the platform owner, and the security function that approved the exception or missed the escalation. If remediation stalls, organisations should be able to identify whether the failure was due to ownership, tooling, testing, or privilege governance.
Why This Matters for Security Teams
An unpatched dependency is rarely just a software hygiene problem. It is a control failure that can expose applications, data flows, and privileged execution paths to known exploitation. When teams cannot name a single owner for remediation, exceptions tend to persist, inventory drifts, and risk registers become disconnected from engineering reality. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that accountability has to be traceable to a control owner, not treated as a shared assumption.
The practical issue is that vulnerability management spans multiple functions. Engineering may own the code path, platform teams may own the runtime or base image, and security may own the policy and escalation process. If any one of those groups believes another is responsible, patching can stall even when the dependency is already flagged by scanners or threat intelligence. That is why accountability must be explicit in change management, exception handling, and incident readiness.
In practice, many security teams discover the missing owner only after a scanner alert has aged into an exploitation incident, rather than through intentional remediation governance.
How It Works in Practice
Accountability should be assigned at the point where the dependency enters the environment and then preserved through the software delivery lifecycle. For a service running in production, the service owner is typically accountable for fixing the issue or driving the release plan. The platform owner is accountable where the dependency is introduced by a shared image, package baseline, or managed runtime. Security is accountable for defining the policy, verifying escalation, and deciding whether an exception is acceptable.
This works best when the organisation treats patch status as a control signal, not just a ticket. Current guidance suggests that teams should maintain asset and software inventory, link vulnerabilities to owning teams, and record the reason a fix is delayed. In mature environments, that means tying findings from CISA’s Known Exploited Vulnerabilities Catalog or internal scanners to service metadata, release pipelines, and exception approvals.
- Define one remediation owner for each dependency path, even if several teams contribute to the stack.
- Record the business reason for any exception, along with expiry date and compensating controls.
- Escalate based on exploitability and exposure, not just severity labels.
- Use change windows, CI checks, and release gates to prevent silent reintroduction of vulnerable versions.
- Track whether the blocker is code fix, test failure, dependency lock, or privilege control.
Where identity and privilege matter, the question becomes who can approve the use of a vulnerable component, who can deploy the fix, and who can override the gate. That intersection is often missed in environments with weak separation between developers, operators, and approvers. These controls tend to break down when dependencies are embedded in third-party images or inherited from a shared platform because the service team may not control the patch path.
Common Variations and Edge Cases
Tighter ownership models often increase coordination overhead, requiring organisations to balance faster patching against clearer accountability. In some cases, the accountable party is not the team that wrote the application at all. For example, a managed service, SaaS integration, or golden image provided by another group can shift the practical fix path away from the product team. Best practice is evolving here, and there is no universal standard for every shared responsibility model.
One common edge case is the approved exception. An exception does not remove accountability; it changes the control decision and should create a visible obligation to revisit the risk. Another is a dependency that cannot be patched without breaking production. In those cases, compensating controls such as isolation, detection tuning, access restriction, or temporary removal from exposed paths should be documented and reviewed.
For internet-facing services and regulated environments, accountability also needs to align with operational resilience expectations and risk governance. That makes the escalation chain as important as the patch itself. If the organisation cannot show who accepted the risk, who owned the fix, and who tracked expiry, the process is functionally unaccountable even if the ticket exists.
Related resources from NHI Mgmt Group
- Who is accountable when exposed edge infrastructure stays vulnerable after disclosure?
- Who is accountable when a vulnerable WordPress site stays online after disclosure?
- Who is accountable when a vulnerable mail relay stays exposed after a fix is available?
- Who is accountable if a vulnerable domain controller remains online after disclosure?
