Who is accountable when an organisation cannot answer access questions about critical applications in time?

Accountability sits with the organisation’s identity, security, and application ownership functions together, because access governance is a shared control. CISOs, IAM leaders, app owners, and compliance teams must define clear decision rights, maintain authoritative ownership records, and ensure review workflows produce timely answers. If they cannot, the control design is not operating effectively.

Why This Matters for Security Teams

When an organisation cannot answer access questions about critical applications in time, the issue is not just process friction. It is a control failure that blocks incident response, audit readiness, and business recovery. Access governance only works when ownership is explicit, entitlements are searchable, and review paths are fast enough to support real decisions. Current guidance in the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point to the same operational reality: if an application owner cannot be identified quickly, the control environment is too brittle to trust.

NHI Management Group research shows how often that brittleness is already present. Only 5.7% of organisations have full visibility into their service accounts, and 68% do not know how to fully address NHI risks, according to the Ultimate Guide to NHIs. Those gaps matter because critical applications increasingly depend on service accounts, API keys, and other non-human identities that do not appear in a simple user directory. In practice, many security teams encounter the ownership problem only after an audit request, outage, or suspected compromise has already exposed the missing answer.

How It Works in Practice

Accountability should be assigned across three functions that must operate as one control: identity, security, and application ownership. Identity teams maintain the authoritative inventory of accounts and credentials. Security teams define policy, evidence requirements, and escalation paths. Application owners confirm who can approve access, who reviews it, and what constitutes acceptable business need. Without all three, the organisation can know that access exists but still be unable to explain why it exists or who can revoke it.

Practically, the control needs a single source of truth for application ownership, linked to current access grants, privileged roles, secrets, and service accounts. That record should support timely questions such as who approved the access, when it was last reviewed, whether the account is still in use, and what dependency breaks if it is removed. For NHI-heavy environments, this is especially important because access is often embedded in code, pipelines, cloud services, and integrations rather than interactive login paths. The 52 NHI Breaches Analysis shows how often hidden credentials and unclear ownership turn routine access governance into a breach amplifier.

• Define decision rights for approval, review, and revocation before the next audit cycle.
• Link each critical application to a named owner and an accountable backup.
• Track non-human identities separately from human users, including service accounts and API keys.
• Set evidence SLAs for access questions so responses are measured in hours, not days.

For organisations that manage secrets at scale, this also means reviewing whether ownership data is usable during an incident, not just complete on paper. These controls tend to break down in hybrid estates with multiple IAM systems, where the same application has different owners in cloud, on-premises, and CI/CD tooling.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance faster answers against more review steps and cleaner ownership records. There is no universal standard for response time, but best practice is evolving toward measurable service levels for access questions, especially for regulated or business-critical systems. If the organisation cannot meet those targets, accountability usually shifts from an individual reviewer to a broken governance design.

One common edge case is outsourced or shared application ownership, where vendor teams manage the platform but the organisation still owns risk. Another is emergency access, where break-glass accounts exist but are not tied to a clear approver or review schedule. In both cases, the problem is not that access exists; it is that no one can answer fast enough who granted it, who should validate it, and who must revoke it if the answer is wrong. The Ultimate Guide to NHIs is clear that visibility and lifecycle governance remain the limiting factors, while the NIST control set reinforces that accountability only exists when assignments are documented and enforced in operation.

Related resources from NHI Mgmt Group

• Who is accountable for ensuring users have the right access to the right assets at the right time?
• Who is accountable when just-in-time access is not revoked after use?
• Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?
• Who is accountable when SaaS access controls fail during a customer-critical workflow?