What is the difference between evaluating access with hierarchical relationships and evaluating access with flat, per-resource rules?

Hierarchical evaluation uses organisational relationships such as parent and child to inherit access across a structure. Flat rules grant permissions directly on each resource or node. Hierarchical policies are easier to manage when departments or regions change, while flat rules give very explicit control. The trade-off is between administrative simplicity and the precision of individually assigned permissions.

How Hierarchical Evaluation Changes the Access Decision

Hierarchical evaluation decides access by walking relationships between objects, such as parent, child, folder, department, region, or inherited policy scope. The access result often comes from where the resource sits in the tree, plus rules attached higher up. That makes the model efficient when organisational structure is meaningful, but it also means the access decision depends on how accurately the hierarchy reflects real business boundaries.

Because the decision is inherited, a change at one level can affect many descendants at once. That is useful when you want consistent access across a portfolio, but it also means a single misplaced parent-child relationship can widen access faster than teams expect. In practice, the main question is whether the structure itself is the right security boundary or just a convenience for administration.

For identity and access governance, hierarchical models line up naturally with IAM and IGA Basics because inherited access, entitlement review, and lifecycle changes all become part of the same control problem. When the hierarchy is sound, it can reduce repeated approvals and make recertification easier to reason about across large populations.

How Flat, Per-Resource Rules Change the Access Decision

Flat evaluation ignores inheritance and checks permissions directly on the specific resource or node. Each object carries its own rule set, so the decision is local and explicit rather than implied by position in a structure. That usually gives tighter control and clearer exception handling, because the permission applies only where it is written.

The trade-off is administrative overhead. If many resources need similar access, flat rules can create duplicated policy, drift between objects, and a larger review burden. They are strongest when the environment needs precision, such as when each dataset, application, or repository has distinct access requirements that should not be inferred from a broader container.

That explicitness is why flat evaluation often pairs well with finer-grained authorisation design. The same access logic can be described more rigorously in an Authorisation Models Guide, especially when teams need to distinguish broad inheritance from policy written directly against the resource being protected.

When to Prefer One Model Over the Other

Choose hierarchical evaluation when the structure is stable, the inherited boundary is trustworthy, and the priority is operational simplicity. It works well for organisations that want access to follow business units, regions, or managed containers without rewriting rules for every node. Choose flat rules when the resource itself is the security boundary, or when local exceptions matter more than shared inheritance.

Most real environments blend the two. Hierarchy can define the default path, while flat rules override sensitive resources that need explicit handling. The practical mistake is assuming the same model should govern everything, or treating inherited access as if it were the same as directly assigned permission. The right design depends on whether the boundary is organisational convenience or security necessity.

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	AC-6 — Least Privilege	Hierarchical vs flat rules affects how far access spreads across resources.
	AC-3 — Access Enforcement	Both models are access enforcement patterns with different decision scopes.
Recommendation — Limit inherited permissions to the smallest scope needed for each resource class. Enforce access decisions at the appropriate layer, parent scope or per-resource.
ISO/IEC 27001:2022	A.5.15 — Access control	The question is about how access is granted and controlled across resources.
Recommendation — Define whether access is inherited or explicit, then document the chosen rule model.
CIS Controls v8	CIS-6 — Access Control Management	Managing hierarchical and flat permissions is an access control governance task.
Recommendation — Review resource-level permissions for drift and excessive inheritance.

Practitioner Guidance

What to verify: Test whether the inheritance tree matches the actual blast radius you intend. If a parent-level change would expose resources that should be isolated, the hierarchy is too coarse for that domain.

Decision rule: Use hierarchy for standardised access patterns and flat rules for high-sensitivity resources, exceptions, or cases where a single resource demands explicit review.

Common mistake: Teams often treat inherited access as harmless because it reduces policy sprawl, then discover that the real risk is silent overreach across every child object under the same parent.

Practitioner takeaway: The better model is the one whose access boundary matches the way you would explain and approve access in a review, if the approval path feels unclear, the policy model is probably too implicit.