Who is accountable when access findings recur across systems?

Why This Matters for Security Teams

Recurring access findings usually signal a broken operating model, not a single technical gap. When a leaver still has access, or a role change does not trigger revocation, the root cause sits at the handoff between HR events, IT workflows, and application owner decisions. That is why NHI Management Group treats lifecycle governance and access governance as one control chain, not separate chores, and why the Ultimate Guide to NHIs frames offboarding and rotation as core governance work.

The accountability question matters because recurring findings often get “owned” by everyone in theory and no one in practice. In NHI-heavy environments, the same failure pattern appears across service accounts, API keys, and privileged integrations, especially when access decisions are manual and evidence is scattered. That is consistent with OWASP Non-Human Identity Top 10 guidance that treats weak lifecycle control and excessive standing access as recurring failure modes. NHI Mgmt Group research shows that only 20% of organisations have formal offboarding and revocation processes for API keys, which explains why findings recur even after remediation efforts.

In practice, many security teams encounter the same access issue again only after an audit follow-up or incident review, rather than through intentional control ownership.

How It Works in Practice

Accountability should be mapped to the control that can actually prevent recurrence. HR owns the lifecycle trigger when a person changes role or leaves, IT owns the workflow that moves that event into identity and access systems, application owners own the access decision for their application, and internal audit tests whether the control operated as designed. The recurring-finding problem appears when one of those handoffs is implicit rather than assigned.

Practically, teams reduce recurrence by documenting the full path from event to revocation and attaching a named owner to each step. That includes:

• HR or People Ops raising the authoritative lifecycle event
• IT or IAM operations translating the event into ticketed or automated access changes
• Application owners approving or denying system-specific access removal
• Control owners proving closure with evidence, logs, and time stamps

For NHI environments, the same logic applies to service accounts, API keys, certificates, and integration tokens. The identity should not outlive the business need, and the revocation path should be tested as a control, not assumed. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how poor visibility and excessive privileges turn small workflow gaps into repeated exposure. Current practice also aligns with identity governance principles in OWASP Non-Human Identity Top 10, where unmanaged credentials and stale access are treated as distinct but connected control failures.

These controls tend to break down in federated enterprises where access is granted locally by many application teams because no single system contains the full lifecycle record.

Common Variations and Edge Cases

Tighter ownership often increases coordination overhead, requiring organisations to balance clear accountability against the cost of formal handoffs. That tradeoff becomes visible in mergers, shared-services models, and multi-cloud estates where one team manages identity, another manages applications, and a third manages the workflow engine. Current guidance suggests that a RACI alone is not enough if it does not include evidence collection and escalation timing.

There is no universal standard for this yet, but the best practice is evolving toward control ownership tied to the failure point. If findings recur because access changes are delayed, IT owns the remediation path. If they recur because managers or app owners approve exceptions too readily, the owner of the business application owns the decision quality. If they recur because leaver data arrives late or incomplete, HR owns the source event integrity.

For NHI programs, recurring findings often come from static secrets that remain valid after personnel change, especially where service accounts are shared or embedded in pipelines. The Ultimate Guide to NHIs — Key Research and Survey Results shows that secrets hygiene failures are common enough that recurring findings should be expected unless revocation is automated and verified. The operational lesson is simple: shared accountability only works when one team is explicitly accountable for closing the loop.

Related resources from NHI Mgmt Group

• Who is accountable when access is over-provisioned across cloud and on-premises systems?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?