What breaks when access is approved from org charts instead of actual usage?

Why org charts fail as an access model

An org chart answers reporting relationships, not operational need. Access decisions built from hierarchy tend to miss the real signals that drive entitlement: which project someone is on, whether a contractor is still active, what application they touch, and whether a role carries sensitive data. The result is stale access that outlives the business reason for granting it.

That mismatch is especially visible in shared teams and fast-moving delivery work. A person can remain “in scope” on paper while their actual duties have changed, or they can move between systems with very different sensitivity levels. When the approval model follows structure instead of usage, entitlement reviews become a formality rather than a control.

What fails when approval follows reporting lines instead of usage

The first thing that breaks is least privilege. If approvers rely on title, department, or manager chain, they often grant broader access than the job actually requires. That creates persistent over-provisioning, especially where access was approved once and never revisited after a project ended or an account went dormant.

The second failure is lifecycle drift. Org-based approvals do not naturally capture short-term work, temporary access, or application-specific sensitivity, so revocation happens late or not at all. In practice, the access graph becomes detached from the work graph, which makes both recertification and cleanup less reliable.

The third failure is accountability. When approval logic is vague, reviewers cannot tell whether they are validating business need, manager preference, or inherited entitlement. That weakens the control’s value as an audit trail and makes exceptions harder to challenge.

How to think about a better access decision model

A usable access model starts with actual usage and business context, not just organisational position. That means asking whether the user is still active in the relevant project, whether the account type is appropriate for the task, whether the requested system carries higher sensitivity, and whether the access should expire when the work ends.

For sensitive systems, the decision should be explicit and time-bound. If the access is temporary, the approval should include a review point or expiry. If the entitlement is broad, the reviewer should require a clearer justification than “this person reports to the right manager.”

This is where external control guidance helps anchor the practice. Least-privilege and account governance expectations in CIS Controls v8, the access-control and identification controls in NIST SP 800-53 Rev 5 Security and Privacy Controls, and the access-control requirements in ISO/IEC 27001:2022 Information Security Management all support the same practical direction: approval should reflect current need, not static structure.

Risk and Threat Considerations

When approvals are based on org charts, access tends to accumulate quietly. That creates exposure when inactive users, ex-contractors, or moved staff retain permissions that still reach sensitive applications or data. The threat is not only misuse, it is also the enlarged blast radius if an account is compromised after its business need has already passed.

Failure mechanism: Static approval criteria fail to track actual work, so excess entitlement survives role changes, project transitions, and account inactivity.

Impact: The environment drifts toward persistent over-provisioning, weaker least privilege, and a larger set of accounts that can be abused, inherited, or overlooked during review.

Practitioner Guidance

What to prioritise: Review the approval rule itself before tuning the review cadence. If the rule is “manager approved,” “same department,” or “in the org,” it is too coarse for systems where sensitivity changes by application or project.

What to verify: Check whether each approved entitlement can be tied to a current business task, an owner who can defend it, and an expiry or recertification trigger. If you cannot explain why the access still exists today, treat it as a cleanup candidate, not a standing entitlement.

Practitioner takeaway: Good access governance follows actual work and current risk, while org charts only describe structure; when those two diverge, over-provisioning is usually the first control failure you will see.

Related resources from NHI Mgmt Group

• What breaks when access reviews do not reflect actual runtime usage?
• What breaks when privileged access reviews rely on a static list instead of actual permission data?
• What breaks when organisations define identity access rules only from policy documents and not actual usage patterns?
• What breaks when organisations rely on assigned access instead of real usage data?