Who is accountable when risk remains open after security flags it?

Why This Matters for Security Teams

When a security team flags an open risk, the hard part is usually not identification. It is making sure the finding becomes an owned work item with a clear execution path, deadline, and evidence of closure. That is why accountability cannot stop at the security queue. It has to extend into IT operations, application owners, and governance. NIST’s NIST Cybersecurity Framework 2.0 treats governance and risk response as coordinated functions, not isolated handoffs. NHIMG’s Top 10 NHI Issues shows the same pattern in identity operations: unresolved issues persist when ownership is unclear and remediation is not tied to live controls.

The real failure is structural. Security can raise the signal, but only the owning team can change the asset, credential, policy, or workflow that caused the exposure. If that relationship is not encoded in ticketing, approval, and exception handling, the organisation gets repeated findings with no closure. In practice, many security teams encounter the same risk again only after an audit, an incident, or an external report has already exposed the gap.

How It Works in Practice

Accountability works best when the organisation separates three things: risk detection, remediation execution, and formal acceptance of residual risk. Security should not be expected to perform every fix, but it must produce a finding that is actionable, traceable, and time-bound. IT or the system owner then owns the change, while leadership owns the decision if the risk remains open past the agreed window.

That workflow is strongest when it is tied to a live control system rather than a static spreadsheet. Current guidance from NIST Cybersecurity Framework 2.0 and NHIMG research on the Ultimate Guide to NHIs points toward ownership metadata, expiry dates, exception approvals, and remediation evidence being linked to the same record. That means a finding is not “done” when it is acknowledged. It is done when the control owner has either remediated it or formally accepted the residual exposure.

• Security owns the finding, severity, and required control outcome.
• IT or application owners own the fix, implementation date, and verification.
• Risk or executive leadership owns the decision to defer or accept unresolved exposure.
• Ticketing, IAM, CMDB, or GRC systems should record the owner, SLA, and closure evidence.

This model also applies to NHI and secrets risk, where a leaked credential, stale token, or orphaned integration can remain exploitable long after the first alert. NHIMG’s The State of Secrets in AppSec highlights how slow remediation becomes a control failure when no one is explicitly accountable for the next action. These controls tend to break down when ownership is spread across multiple tools and no single workflow can enforce closure.

Common Variations and Edge Cases

Tighter accountability often increases process overhead, requiring organisations to balance speed of remediation against approval friction and operational continuity. That tradeoff becomes visible when a finding affects a shared platform, a legacy system, or a third-party integration that no single team can change without coordination.

There is no universal standard for this yet, but current guidance suggests the clearest model is shared responsibility with a single named executor. Security should not be the permanent owner of business risk, and IT should not be able to close a finding without proving the control has changed. For high-severity items, the exception path should escalate quickly, with an explicit expiry date and revalidation requirement. For lower-severity findings, a risk register entry may be acceptable if the owner and review cadence are real, not ceremonial.

One useful test is simple: if the organisation cannot answer who will act, by when, and what evidence will prove completion, then accountability is not actually assigned. That problem becomes acute in environments with multiple IAM systems, fragmented asset ownership, or outsourced operations, because the control failure can hide behind organisational ambiguity rather than technical complexity.

Related resources from NHI Mgmt Group

• Who is accountable when subcontractor access remains open after a project ends?
• Who remains accountable when identity security capabilities are integrated after an acquisition?
• Who is accountable when detection risk remains high after an audit?
• How should security teams prioritise NHI remediation in cloud environments?