Accountability usually spans application owners, cloud security, IAM, and platform teams because the failure crosses code, identity, and operations. If the organisation knew a patch window existed but did not govern runtime behaviour, the gap is a control design issue, not just a remediation delay.
Why This Matters for Security Teams
When a vulnerability is known but runtime controls are missing, the issue is no longer only about patching. It becomes a governance failure that spans secure design, operational ownership, and risk acceptance. Teams often assume the existence of a fix or backlog item reduces exposure, but attackers exploit the gap between awareness and enforcement. That gap is exactly where compensating controls, segmentation, and monitoring should have existed. The control objective is consistent with CISA cyber threat advisories, which repeatedly stress timely mitigation and layered defence.
Accountability matters because runtime controls are usually owned across multiple functions. Application teams may own the vulnerable code path, cloud or platform teams may own the enforcement plane, and IAM or PAM teams may own the privilege boundaries that limit blast radius. If nobody is explicitly accountable for the live control state, the organisation can end up with a paper remediation plan and an exposed system. In practice, many security teams encounter this only after an incident review reveals that everyone tracked the vulnerability, but no one owned the runtime safeguard.
How It Works in Practice
In mature environments, accountability is assigned by control domain, not by technical sympathy. A vulnerability owner tracks the defect itself, but a separate control owner is responsible for enforcing runtime mitigations such as WAF rules, container policy, EDR policy, network filtering, service account restrictions, or feature flags that reduce exploitability. That distinction is important because the patch backlog and the live risk picture are not the same thing.
A practical operating model usually includes:
- asset or service ownership for the affected workload
- a named control owner for compensating controls
- defined severity thresholds for when runtime mitigation is mandatory
- evidence that the control is active, tested, and monitored
- escalation rules when patching slips beyond the approved window
NIST guidance on control families in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates access control, system integrity, monitoring, and configuration management into operational duties that can be assigned and audited. CIS Controls v8 similarly reinforces that asset inventory, secure configuration, access management, and continuous monitoring are not optional add-ons but part of the baseline defence model. The key question is not only “is the vulnerability known?” but “who is verifying that exploitation paths are actually constrained today?”
This works best when the organisation has clear RACI ownership, change control, and continuous verification. These controls tend to break down when ownership is split across SaaS, cloud, and legacy estates because no single team sees the full attack surface or can enforce the same runtime policy everywhere.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance speed of change against the cost of coordination and false positives. That tradeoff is especially visible when teams must choose between emergency mitigation and service availability. Best practice is evolving, but current guidance suggests treating the absence of runtime controls as a risk acceptance decision that needs documented approval, not an informal gap.
There are edge cases where accountability becomes more complex. In managed service environments, the provider may operate the control plane, while the customer remains accountable for configuration and risk acceptance. In legacy systems, runtime enforcement may be technically limited, so the accountable owner may need to substitute segmentation, restricted access paths, or enhanced detection. In container and ephemeral workloads, the control owner may need to prove policy at deployment time because manual checks disappear too quickly to be reliable. ENISA Threat Landscape remains a useful reference for how adversaries exploit these gaps in practice.
The cleanest rule is simple: if the organisation knew the vulnerability and allowed execution to remain unconstrained, accountability sits with the owner of the failing control and the approver of the risk exception, not only with the developer who reported the bug.
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, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Known vulnerability without controls is a risk governance and ownership issue. |
| NIST AI RMF | GOVERN | AI RMF governance applies when autonomous systems or AI-assisted ops affect control decisions. |
| NIST SP 800-53 Rev 5 | RA-5 | Vulnerability scanning links the known flaw to required mitigation tracking. |
Assign risk ownership and track compensating controls until exposure is reduced or formally accepted.
Related resources from NHI Mgmt Group
- Should teams prioritise runtime controls over more vulnerability scanning?
- Who is accountable when automated vulnerability evidence maps to compliance controls?
- Who is accountable when a known exploited Office vulnerability remains unpatched?
- Who is accountable when Kubernetes runtime controls fail to contain a workload?
