A single reviewer signing off on access works fine for most applications. It's not enough for the access that would actually hurt if it were wrong, a privileged financial system, an admin role over a business-critical SaaS platform, access a regulator expects more than one set of eyes on. Multi-level review exists specifically for that population, sequential, independent judgment from more than one person, instead of the same single-reviewer process applied uniformly regardless of what's actually at stake.
Quick Summary
What Multi-Level Review Actually Means
Multi-level review lets a single certification require sign-off from more than one reviewer, in a defined sequence, before that record is considered complete. A few things worth being precise about:
- It's not the default. Most access genuinely doesn't warrant more than one reviewer.
- It supports up to five sequential levels per entity (an application or a group).
- Progression is strictly sequential: Level 2 doesn't activate until Level 1 has signed off.
- Every level's sign-off locks independently, and the certification only completes once every configured level has signed off.
This is the mechanism for escalating scrutiny on the specific slice of access that needs it, without either burying every review under unnecessary layers or leaving genuinely sensitive access under-scrutinized.
Why Sequential, Not Simultaneous
The sequencing is deliberate, not an arbitrary design choice. A reviewer acting alone at Level 1 brings one kind of context, usually operational, does this person's role still need the access. A reviewer at Level 2 brings a different kind, usually risk-focused, is this acceptable regardless of the operational case. Running them in sequence means Level 2 sees Level 1's decision already made and reviews with that context in hand, instead of two people guessing blind at the same record. In Zluri specifically, that principle is enforced structurally, Level 2 simply doesn't open until Level 1 has signed off.
Why Each Level Needs Its Own Distinct Reviewer
This is a hard requirement, worth stating precisely: every level requires a unique Primary Reviewer. The same person can't occupy two levels in the same chain, Zluri enforces this at configuration time, it isn't just a policy recommendation.
The reasoning follows the same principle as segregation of duties and the four-eyes rule, no single person should be able to unilaterally push through something significant enough that getting it wrong causes real damage, applied here to the review process itself rather than to standing entitlements. If one person could satisfy two levels of a review chain, the entire point of escalating scrutiny collapses.
A Two-Level Review in Practice
Take a Salesforce admin role, the kind of access that's routine to hold but expensive to get wrong. A two-level chain might look like this:
Level 1, Reporting Manager. Reviews with operational context: is this person still actively working in a capacity that needs admin-level Salesforce access, or has their role shifted since it was granted. Approves, modifies, or revokes, with a mandatory comment if it's anything other than Approve.
Level 2, App Owner or Security Reviewer. Sees the Level 1 decision and comment already in place, then reviews independently with a different lens entirely: does admin-level access to this specific system represent acceptable risk, regardless of whether the person's role justifies it operationally. This reviewer isn't re-doing Level 1's job, they're asking a question Level 1 typically isn't positioned to answer.
For a system under SOX scope or holding regulated financial data, a third level, a compliance or security team sign-off, is a common addition on top of these two, specifically because auditors expect to see more than operational justification alone behind privileged access.
The Fallback Reviewer, Reused Across Every Level
A single Fallback Reviewer can be configured once and reused across every level in a chain, rather than requiring a separate fallback maintained for each individual level.
This matters practically. A five-level chain doesn't need five separately maintained fallback assignments. One fallback covers the whole sequence, stepping in at whichever level actually needs it if that level's Primary Reviewer is unavailable or has left the organization. It's what keeps a multi-level chain from becoming disproportionately harder to maintain than a single-level review just because it has more steps.
What Happens at Each Individual Level
Every level in the chain is its own complete review action, not an abstraction layered on top of the record:
- The reviewer at that level sees the same record, the same access being evaluated
- They make their own independent decision, Approve, Modify, or Revoke
- Modify and Revoke require a mandatory comment specific to that level, not inherited or copied from whatever a previous level decided
- Their sign-off locks that level permanently once submitted
A manager's justification and a security reviewer's justification for the same record are two separately documented pieces of reasoning, both preserved, both part of the eventual audit trail. That separation is what keeps each level genuinely independent rather than a rubber-stamped formality.
How Sign-Off Actually Moves a Record Forward
For a reviewer working through their assigned level, the mechanics are the same as any single-level review, just scoped to their level in the chain:
- Complete Approve, Modify, or Revoke decisions for every record assigned at that level
- Confirm the progress indicator shows 100% complete for that level
- Select Sign Off, then Confirm
- The next level's reviewers are notified automatically the moment the prior level signs off, no manual handoff required
Until a reviewer signs off, they can freely revise their own decisions and comments. Once submitted, that level locks, and there's no going back to edit it, by that reviewer or by anyone at a later level.
Reviewer Resolution Applies at Every Level Independently
The same reviewer resolution logic that governs any access review, Primary Reviewer check, then Fallback Reviewer, then Certification Owner as the final backstop, applies at each level of a multi-level chain independently.
If a named Primary Reviewer at Level 3 has since left the organization, resolution at that specific level falls through to the shared Fallback exactly as it would for a single-level review, without disrupting whatever already happened at Levels 1 and 2. A personnel change mid-cycle doesn't stall a chain that's already made real progress through its earlier levels. (For the full mechanics of how reviewer resolution works, see how setup works in Zluri.)
From Last Sign-Off to Remediation
Once every configured level for a given entity has signed off, that entity is tagged Ready for Remediation. Once every entity in the certification carries that tag, Conclude Review becomes available to the Certification Owner.
This is a deliberate gate, not a formality. Remediation never triggers on a multi-level entity until the full chain, every level, every sign-off, is completely finalized. A Revoke decision at Level 1 doesn't fire a deprovisioning playbook the moment it's entered, it waits for the entire chain to close, which is exactly the point of requiring more than one reviewer in the first place.
Where Multi-Level Reviews Apply
Multi-level review is available for application-based and group-based certifications. User-based reviews don't use this same structured, level-by-level chain, they achieve comparable granularity through per-user overrides instead, assigning different reviewers to different people within the same population-based certification.
Deciding Whether Multi-Level Is the Right Call
Multi-level review fits a defined, narrower population, admin-level access to business-critical SaaS systems, financial systems under regulatory scrutiny, access following a significant team change, systems holding regulated data, not a default setting applied broadly. Applied indiscriminately, it produces the opposite of its intended effect: reviewers moving through redundant sign-offs quickly enough that the extra levels stop adding real scrutiny.
For the deeper reasoning on how many levels to use and how to keep each one genuinely independent rather than a formality, see the general guide to multi-level access reviews.
Frequently Asked Questions
Can the same person serve as the reviewer at two different levels in a multi-level chain?
No, every level requires its own unique Primary Reviewer. This is a deliberate constraint, similar in spirit to segregation of duties, ensuring no single individual's judgment alone can complete a review chain that was specifically built to require more than one perspective.
Does a five-level review chain need five separate fallback reviewers configured?
No, a single Fallback Reviewer can be configured once and reused across every level in the chain, stepping in at whichever specific level needs it rather than requiring a separately maintained fallback per level.
If a reviewer signs off at Level 2, does Level 3 see that decision or review blind?
Sequential progression means Level 3's reviewer sees the record after Level 2 has already signed off, with that decision visible as part of the record's history, which is what allows each subsequent level to build on the scrutiny already applied rather than starting from zero every time.
Does every level in a multi-level review require its own justification comment?
Yes, for any level where the decision is Modify or Revoke. Each level's comment is specific to that reviewer's own judgment and preserved independently, rather than one comment applying to the whole chain, which keeps the audit trail showing exactly what each individual reviewer concluded and why.
Do I have to use all five levels, or can I configure just two or three?
Multi-level review supports up to five levels, not a fixed five. A two-level chain, manager plus security reviewer, is one of the most common configurations. The right number is whatever matches how many genuinely distinct perspectives the access actually needs, not the maximum available.
Does remediation happen level by level, or only after the whole chain finishes?
Only after the whole chain finishes. An entity isn't tagged Ready for Remediation until every configured level has signed off, so a Revoke decision entered at an early level doesn't trigger any remediation action until the entire chain is complete.
.svg)
