Organisations should accept that access decisions often happen close to the business and then build visibility around those decisions. The practical goal is to know which applications are used, who uses them, and through which accounts. That gives IT the observability needed for audit, accountability, and more effective control without forcing every decision back into a central queue.
Why visibility breaks when access decisions move into the business
When access is decided close to the team that owns the application, the loss is usually not control, it is central visibility. Business units may know why access was granted, but IT often cannot easily answer the operational questions that matter later: which applications exist, which accounts are in use, and whether the access path is still appropriate. The fix is to make those decisions observable, not to pretend every decision should be centralised.
That means treating business-led access as a source of truth that still needs a control plane. A useful visibility model captures the application, the user or role behind the access, the account type used to reach it, and the business owner who approved it. Without that minimum dataset, audit and review become guesswork, especially where access is spread across SaaS apps, shared administrative paths, or locally managed entitlements.
What organisations need to know to regain control
The practical objective is not full central approval, but a complete inventory of effective access. Organisations should be able to correlate IAM and IGA basics with actual application usage so that business-approved access can still be reviewed, challenged, and revoked when needed. That is where identity visibility and intelligence platforms become useful: they help turn fragmented access data into a unified view of who has access to what.
For application access specifically, the most valuable signal is not simply “user exists”, but “user, account, and application relationship is known and current”. That lets teams see whether access is attached to a named person, a shared account, a service path, or an exception that has drifted into normal use. If the organisation cannot answer those questions consistently, the visibility problem is already large enough to affect review quality and accountability.
In practice, this often requires mapping identity visibility and posture tools against business-owned applications and then using the results to support access recertification, entitlement cleanup, and ownership assignment. The point is to expose the real access graph, not just the approval workflow.
How to rebuild observability without recentralising every decision
Recovering visibility works best when organisations separate decision-making from evidence collection. Business units can keep deciding who should get access, while IT or security defines the minimum logging and reporting standard that every application must satisfy. That usually includes ownership, approval source, account type, last-used date, and a path back to the requesting team.
A practical first step is to standardise a small set of fields across all application access records, then enforce those fields through reporting and review. Once the data is reliable, teams can identify orphaned access, stale accounts, and apps with no accountable owner. Lifecycle management is the right lens here because visibility degrades whenever provisioning, review, and offboarding happen in different systems without a shared record.
Where organisations have many local approval models, the goal should be a federated governance pattern: keep the decision close to the business, but centralise the evidence. That gives central teams enough observability to support audit and exception handling without forcing every request through a bottleneck that the business will work around.
Risk and Threat Considerations
When application access is visible only inside business units, the main risk is not just weak reporting, it is uncontrolled drift. Access can remain active after role changes, exceptions can accumulate, and shared or misclassified accounts can hide the true blast radius of a compromise. That weakens auditability and makes revocation slower when an account, team, or application is no longer trusted.
Failure mechanism: Access decisions are made locally, but no reliable record ties each application, account, and owner together, so stale or excessive access survives normal review cycles.
Impact: Organisations lose the ability to prove who had access, increase the chance of privilege creep, and create blind spots that can be exploited for misuse or persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Application access needs auditable records of who used what and when. |
| AC-2 — Account Management | Visibility depends on knowing which accounts exist and who owns them. | |
| IA-5 — Authenticator Management | Access visibility fails when account and credential state is not governed consistently. | |
| Recommendation — Log application access events with enough detail to trace user, account, and application activity. Maintain current account inventories, owners, and timely deprovisioning for application access. Track and govern authenticators and related account material through their full lifecycle. | ||
| CIS Controls v8 | CIS-5 — Account Management | Central visibility requires knowing authorized accounts and removing stale ones. |
| Recommendation — Inventory, review, and disable unused application accounts on a regular cadence. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access must be governed and reviewable even when decisions are distributed. |
| Recommendation — Define access control rules that preserve traceable approvals and periodic review. | ||
Practitioner Guidance
What to prioritise: Start with the applications that carry the most business value or the highest access concentration. If those cannot be inventoried cleanly, the rest of the portfolio will be harder to govern and the reporting noise will be high.
What to verify: For each application, confirm that you can identify the owner, the approved account type, the last access date, and the process for revocation. If any of those elements are missing, treat the access path as incomplete, even if the approval itself was legitimate.
What good looks like: Business units still own access decisions, but IT can produce a current view of effective access on demand, and review evidence can be traced back to the application, the account, and the approving team without manual reconstruction.
Practitioner takeaway: Regaining visibility is mostly a data and accountability problem, not a policy problem, and the strongest control is the ability to prove effective access after the business has already made the decision.
Related resources from NHI Mgmt Group
- How should organisations improve identity visibility when IAM environments are fragmented across business units and cloud systems?
- Who is accountable for protecting identity data when access is granted across partners and internal business units?
- How should security teams manage role-based access for mixed identity populations across multiple countries and business units?
- What breaks when organisations manage identity separately across multiple business units and platforms?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
