Who is accountable when active exploitation is known but enrichment is still incomplete?

Accountability sits with the teams that own exposure, patching, and prioritisation decisions, not with the catalogue alone. When enrichment lags, governance must shift to risk ownership based on live telemetry and business criticality. Waiting for full metadata is a process choice, not a technical necessity.

Why This Matters for Security Teams

When active exploitation is already known, accountability cannot wait on a perfect asset record. The practical risk is not abstract exposure but ongoing abuse of live credentials, service accounts, and API keys while enrichment jobs are still catching up. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that control ownership and response action need to be defined even when data quality is incomplete. NHIMG’s Ultimate Guide to Non-Human Identities shows why this matters: only 5.7% of organisations have full visibility into their service accounts, which means waiting for enrichment often means waiting for certainty that never arrives.

The right model is to assign risk ownership to the teams already empowered to patch, revoke, contain, or prioritise based on live telemetry and business criticality. A catalogue can inform the decision, but it cannot be the decision-maker when exploitation is underway. In practice, many security teams discover that “pending enrichment” becomes a standing excuse for inaction only after attackers have already used the gap to move laterally or persist.

How It Works in Practice

The operational pattern is straightforward: treat enrichment as support data, not as a gating requirement for response. When exploitation is known, incident handling should immediately anchor to the system owner, the credential owner, and the remediation owner for the affected workload. If those roles are split, the decision authority must still be explicit so patching, token revocation, isolation, or compensating controls can happen without delay. This is consistent with the control ownership and response discipline reflected in NIST SP 800-53 Rev 5 Security and Privacy Controls and with NHIMG’s breach analysis in 52 NHI Breaches Analysis, where delay and ownership ambiguity repeatedly amplify damage.

A workable process usually includes:

• Declare the asset or identity in-scope based on telemetry, not completeness of metadata.
• Assign a named business or technical owner who can approve emergency containment.
• Use live evidence such as authentication logs, secret usage, and network activity to prioritise action.
• Escalate to the team that can revoke secrets, rotate keys, or disable access immediately.
• Backfill enrichment after containment so the record supports lessons learned and future automation.

This approach prevents catalog lag from becoming a blocker and keeps accountability with the people who can reduce harm fastest. It also aligns with the practical reality that many NHI environments are already under-governed, with excessive privilege and incomplete visibility common across service accounts. These controls tend to break down in highly federated environments where no single team owns both the workload and the identity lifecycle, because response authority becomes fragmented across platform, application, and security groups.

Common Variations and Edge Cases

Tighter emergency authority often increases operational overhead, requiring organisations to balance rapid containment against the risk of overstepping ownership boundaries. That tradeoff is especially visible when third-party services, shared platforms, or CI/CD-managed identities are involved, because the team that sees the exploit may not be the team that can safely revoke the credential.

Best practice is evolving, but current guidance suggests three common exceptions. First, if the identity is tied to a regulated production system, the security team may need pre-authorised containment power even before enrichment is complete. Second, if the workload is ephemeral or auto-generated, the platform owner may be the only practical accountable party because there is no durable business owner in the usual sense. Third, if enrichment is delayed by tool failure rather than missing source data, accountability should shift to whoever owns the enrichment pipeline as well as the exposed workload. NHIMG’s Ultimate Guide to Non-Human Identities is a useful reminder that visibility gaps are common, so governance should assume partial data as the norm rather than the exception.

Where organisations get this wrong is by treating the catalogue as the source of truth for actionability. It is not. The source of truth for accountability is the operational owner who can act on active exploitation right now.

Related resources from NHI Mgmt Group

• Why do still-valid secrets matter after public disclosure?
• Who is accountable when an unowned NHI is left active?
• Who is accountable when compliance evidence is incomplete?
• Who is accountable when inherited NHI credentials remain active after a merger or acquisition?