Hierarchy functions are policy helpers that understand relationships within an organisational tree, such as parent, child, ancestor, and sibling. They allow access rules to follow business structure instead of requiring explicit permissions for every node, which is useful when departments, offices, or regions are managed as nested entities.
How hierarchy functions work
Hierarchy functions are relationship-aware policy helpers. Instead of evaluating each object in isolation, they let a rule understand how one node sits inside a larger organisational tree, so access can be inferred from a parent, ancestor, sibling, or child relationship.
That makes them useful anywhere structure matters more than a flat list of explicit grants. A policy can say, for example, that access to a regional office should also apply to the teams beneath it, or that a business unit’s permissions should be inherited by related subunits without repeating the same rule everywhere.
Why hierarchy functions matter for access design
The main benefit is scalability. Without hierarchy-aware logic, administrators often duplicate permissions across many nodes, which increases drift and makes reviews harder. With hierarchy functions, the policy can follow the organisation’s own structure, so changes at a higher level can cascade consistently to related entities.
They also improve policy readability. A rule that references “all descendants of Finance” is easier to reason about than a long list of individual departments, offices, or regions. That said, the simpler expression can hide broad reach if the tree is deep or loosely governed, so the structure itself becomes part of the security model.
Where hierarchy functions are used
These functions are common in access control systems, directory-based policies, data governance rules, and organisational reporting structures. They are especially helpful when the business model is nested, such as corporate divisions, franchise networks, subsidiaries, or geographically layered operations.
They can also support delegation and exception handling. For instance, a policy may grant a regional manager authority over their own branch and all child branches, while preserving separate controls for peer branches or unrelated parts of the tree. That makes hierarchy functions a practical way to express inherited authority without flattening the organisation.
Common implementation considerations
Hierarchy functions only work well when the tree is accurate, stable, and well-owned. If parent-child relationships are outdated, circular, or poorly maintained, the policy can grant the wrong scope of access or fail to reflect the real business structure.
They also require clear boundaries between structural inheritance and explicit exception handling. The more a policy depends on hierarchy, the more important it is to define who can create, move, or reparent nodes, because those administrative changes can alter effective access just as much as changing the policy itself.
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, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Hierarchy functions define how access is enforced across parent-child relationships. |
| AC-6 — Least Privilege | Hierarchy-driven inheritance can expand access beyond the minimum if trees are broad. | |
| Recommendation — Model inheritance rules under AC-3 so structural scope changes do not overgrant access. Limit inherited scope under AC-6 to the smallest organisational subtree needed. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Hierarchy functions often govern who can access what as organisational relationships change. |
| Recommendation — Review structural access rules under PR.AA-01 whenever hierarchy changes affect entitlements. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Hierarchy functions are a method for expressing access control across organisational structure. |
| Recommendation — Define hierarchical access rules in the access control policy and review inherited reach regularly. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | Hierarchy-aware policies are an IAM design pattern for inheriting permissions through business structure. |
| Recommendation — Use IAM governance to keep parent-child access inheritance aligned to organisational ownership. | ||
Practitioner Guidance
Governance implication: Treat the hierarchy as part of the control plane, not just a data model. If ownership of the tree is weak, inherited access becomes difficult to review, and policy changes can have wider effects than their wording suggests.
What to watch for: Pay close attention when organisational restructures, mergers, or regional expansions change parent-child relationships. Those changes often alter effective access even when no explicit permission updates were made.
