Who is accountable when access risk spans multiple business applications?

Why This Matters for Security Teams

When access risk spans multiple business applications, the failure is rarely a technical one alone. The real issue is that one team owns the process outcome while several teams own fragments of the entitlement model, the evidence trail, and the enforcement points. That split creates gaps in certification, delays in revocation, and inconsistent approvals that are easy to miss until an audit or incident exposes them. Current guidance from NIST Cybersecurity Framework 2.0 still points to accountable governance and traceable control ownership, but it does not remove the operational ambiguity across shared applications.

NHI Management Group research shows the scale of the problem is not theoretical. In the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which makes fragmented ownership especially dangerous when a process touches multiple platforms. In practice, many security teams encounter accountability failures only after access drift, failed offboarding, or a certification exception has already become accepted as normal.

How It Works in Practice

The accountable owner should be the business process owner, because that person or function is the only one positioned to judge whether cross-application access is justified end to end. IAM can define the control model, IGA can orchestrate reviews and evidence, and application teams can expose entitlements and revocation hooks, but none of them should be the sole owner of the risk decision. That distinction matters because accountability is not the same as task execution.

A workable operating model usually separates four responsibilities:

• Business owner: approves access based on process need, data sensitivity, and operational impact.

• IAM team: defines the access pattern, joiner-mover-leaver logic, and identity source of truth.

• IGA team: runs certifications, exception handling, and audit evidence collection.

• Application owner: maintains entitlement accuracy, technical enforcement, and deprovisioning support.

This model aligns with the broader governance direction in OWASP Non-Human Identity Top 10, especially where privileged service access and weak lifecycle control create hidden exposure across systems. For process-level risk, the review should ask whether access across all connected applications is still needed together, not whether each individual permission looks acceptable in isolation. The evidence trail should show one accountable approver, consistent rationale, and clear remediation ownership if any application cannot enforce the decision.

That is why NHI Management Group recommends pairing business accountability with a visible control map, as described in the Ultimate Guide to NHIs — Why NHI Security Matters Now and the Ultimate Guide to NHIs — Key Challenges and Risks. These controls tend to break down when a single process depends on legacy apps, custom connectors, or shared service accounts that cannot express ownership cleanly.

Common Variations and Edge Cases

Tighter accountability often increases review overhead, requiring organisations to balance control quality against approval speed. That tradeoff becomes sharper when a business process spans cloud, SaaS, and on-prem applications, because each platform may expose different entitlement names, logging depth, and deprovisioning mechanics.

There is no universal standard for this yet, but current guidance suggests a few practical patterns. For shared platforms, the process owner can remain accountable while delegate approvers handle system-specific details. For outsourced application administration, the vendor may execute tasks, but accountability still stays inside the business because risk acceptance cannot be transferred. For highly regulated environments, some organisations create a risk committee or data-owner sign-off for especially sensitive cross-application access, though best practice is evolving and should be documented clearly.

One common failure mode is treating each application review as independent. That approach ignores cumulative privilege, where access across several tools enables a broader outcome than any single entitlement suggests. Another edge case is when no single owner exists for an end-to-end workflow; in that situation, the organisation should formally assign one accountable business owner before the next certification cycle, rather than letting IAM inherit the risk by default. The control is weakest when process boundaries are unclear, because then every team can point to the others while the access path remains live.

Related resources from NHI Mgmt Group

• Who is accountable when risk-based access decisions fail audit or compliance testing?
• Who is accountable when delegated access outlives the original business need?
• Who should be accountable when identity risk spans IAM and security operations?
• Why do business applications create hidden identity risk even when perimeter security is strong?