Who is accountable when access decisions, application ownership, or documentation are incomplete?

Why This Matters for Security Teams

Accountability failures are not just an administrative problem. When access decisions are made without a clear owner, the organisation cannot defend why a permission was approved, who reviewed it, or who should remove it later. That creates delayed onboarding, stale entitlements, and audit findings that often surface only after an incident. The operational risk is higher for non-human identities, where ownership is frequently split across teams and toolchains.

NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, while 68% do not know how to fully address NHI risks. That combination makes unclear accountability especially dangerous because the people closest to the application context are often the only ones who can judge whether access is still justified. Guidance from the OWASP Non-Human Identity Top 10 reinforces that ownership gaps are a control failure, not a paperwork issue. In practice, many security teams discover this only after a service account has already outlived its purpose or been used outside the intended change process.

How It Works in Practice

Defensible accountability starts by assigning the access decision to the business or application owner who understands the purpose, data sensitivity, and operational dependencies of the identity. IAM and IGA teams should not own the business judgment itself; they should enforce the process, validate evidence, and block approvals that lack context. Security teams define minimum standards, such as required approver roles, time-bound access, logging, and periodic review.

A practical model uses three layers of control. First, the requestor or system owner states what access is needed and why. Second, the application owner or delegate approves against policy and intended use. Third, IAM or IGA validates that the approval meets documented controls, such as least privilege, segregation of duties, and recertification. This is consistent with the governance expectations in NIST SP 800-53 Rev. 5 Security and Privacy Controls, especially where organisations need traceable approval, accountability, and review evidence.

• Define a single accountable owner for each application and each non-human identity class.
• Require documented approvers for initial access, change approvals, and emergency exceptions.
• Use a RACI so it is clear who approves, who implements, who reviews, and who accepts risk.
• Attach ownership metadata to every service account, API key, token, and certificate.
• Force periodic attestations so dormant access is revalidated or removed.

NHIMG’s Ultimate Guide to NHIs shows why this matters: NHI sprawl is large, privileged, and difficult to see. The same guide’s Key Challenges and Risks section is useful when building ownership controls around lifecycle, rotation, and offboarding. These controls tend to break down in federated environments where application ownership is split across vendors, platform teams, and product squads because no single party can reliably evidence the access decision.

Common Variations and Edge Cases

Tighter ownership controls often increase approval overhead, requiring organisations to balance auditability against operational speed. That tradeoff is real, especially for incident response, shared platforms, and legacy systems where documentation is incomplete or the original owner has left the organisation.

Current guidance suggests treating those situations as exceptions, not normal operating state. If ownership is missing, the safest path is temporary assignment of a proxy owner with a documented expiry date, followed by remediation work to restore durable accountability. For inherited applications, the business owner should usually accept accountability even if a technical team manages the platform. For shared services, accountability should be separated by function so access decisions are not made by whichever team is available that day.

There is no universal standard for this yet, but best practice is evolving toward explicit ownership metadata, approval evidence, and periodic re-certification of both human and non-human access. Where documentation is incomplete, organisations should not infer approval from silence or historic practice. Instead, they should require a named owner, a dated review, and a fallback escalation path. The 52 NHI Breaches Analysis illustrates how quickly weak ownership becomes a security failure when access is left in place without a clear decision-maker.

Related resources from NHI Mgmt Group

• Who is accountable for protecting identity data when access is granted across partners and internal business units?
• Why do access reviews fail when data classification and identity context are incomplete?
• Who is accountable when access remains active after a support ticket is marked complete?
• Who is accountable for proving whether access is appropriate when auditors ask tough questions?