TL;DR: Access reviews only become defensible when visibility, decision rights, and entity-level data isolation are separated by role, row, and configuration, according to Veza. That model matters because least privilege in IGA is now a compliance control, not just an administrative preference.
At a glance
What this is: This is an analysis of how access review programmes need granular role, row, and entity controls to make certifications defensible and keep review data isolated.
Why it matters: It matters because IAM, IGA, and compliance teams have to treat access reviews as enforced controls with evidence, not just workflow, especially where operating entities, auditors, and reviewers need different scopes.
Context
Access review programmes are only defensible when the system can separate decision rights from data visibility. In practice, that means the platform must enforce who can administer campaigns, who can review assigned rows, and which entity's review data each persona is allowed to see.
This becomes more important in organisations made up of multiple operating entities or business units. If review scope and review data are not isolated cleanly, least privilege collapses inside the governance workflow itself, which weakens both compliance evidence and reviewer accountability.
Key questions
Q: How should teams separate reviewer access from review administration in IGA?
A: Teams should design access reviews with separate controls for who can administer campaigns and who can act on assigned rows. That separation preserves least privilege, reduces accidental overexposure of review data, and makes it easier to prove that decisions were made within the right scope.
Q: When should organisations use entity-level isolation for access reviews?
A: Organisations should use entity-level isolation whenever review evidence, approvals, or campaign data must stay separate across subsidiaries, business units, or regulated operating entities. The goal is to keep one entity's evidence from becoming visible to another, which helps preserve audit defensibility and limits unnecessary exposure of control data.
Q: Where do access review programmes most often lose least privilege?
A: They lose least privilege when reviewer visibility, operator administration, and audit oversight are collapsed into broad tenant permissions. The common failure is letting a persona inherit more review scope than the job requires, which undermines both segregation of duties and evidence quality.
Q: What should auditors look for in an access-request control?
A: They should look for a record that shows the requester, the approver, the business reason, the policy decision and the provisioning outcome in one place. If any of those elements are missing, the organisation is relying on evidence fragments rather than a control that can be independently reconstructed.
Technical breakdown
Two-dimensional access control for reviews
Access review governance has two different control problems: action control and data visibility control. Action control determines what a persona can do, such as create campaigns, assign rows, approve or reject access, reassign items, or certify outcomes. Visibility control determines which reviews, configurations, and rows the persona can read at all. A mature model needs both because a reviewer who can act on a row should not automatically see unrelated campaign data, and an operator who can manage campaigns should not inherit reviewer visibility everywhere. When those layers collapse into one permission model, segregation of duties becomes harder to prove and easier to misconfigure.
Practical implication: Treat review permissions and review-data visibility as separate design problems in the IGA model.
Row-level scoping and reviewer isolation
Row assignment is the mechanism that turns access review into a targeted control rather than a broad reporting exercise. In the model described here, reviewers should only see the rows assigned to them, and in some cases only the uncompleted rows that still require action. That prevents reviewers from being exposed to unrelated entitlements, other business units, or other operating entities. The technical value is not convenience alone. It is evidence quality, because the system can prove that each reviewer acted only within the scope assigned to them. Where the same user holds more than one persona, the platform must preserve those boundaries rather than merge them blindly.
Practical implication: Use row-level scoping to restrict reviewers to assigned items and preserve evidence of scoped decision-making.
Limit Access lists and entity segregation
Limit Access works like an access control list for review configurations and inherited reviews, which is useful when the same platform serves multiple departments or operating entities. This matters because a governance workflow can fail even when the underlying application access is well managed if the review layer itself leaks across entity boundaries. The article also shows that groups can carry access at scale, including through SCIM-managed membership, which makes lifecycle accuracy a governance dependency rather than an administrative detail. If group membership, entity ownership, and review visibility drift apart, access reviews stop being a precise compliance control and become a blended tenant-wide permission surface.
Practical implication: Use configuration-level access restrictions and group governance to keep review data segregated by operating entity.
NHI Mgmt Group analysis
Granular access review control is now part of the compliance control plane. Access reviews are no longer just a workflow for certifying entitlements. They are an enforcement layer that produces evidence, which means permission design has to satisfy compliance requirements as tightly as the underlying access model.
Two-dimensional control is the real governance requirement. The first dimension is what each persona can do, and the second is what each persona can see. When those dimensions are not separated, least privilege inside the review process breaks down even if the application layer is well governed.
Entity segregation is the overlooked control boundary in IGA programmes. Multi-entity organisations do not only need campaign scoping, they need review data isolation that survives operating structure, reviewer roles, and shared administration. The practical implication is that compliance teams should treat review tenancy boundaries as a governance requirement, not a platform preference.
Review scope drift: This article exposes the risk that reviewers, monitors, and operators can end up with broader visibility than their jobs require. That pattern matters because it turns an access certification programme into a high-friction shared data space, which weakens evidentiary value and increases misassignment risk.
Group-based access management becomes a governance dependency at scale. Once review access is granted through groups, SCIM, and inherited configuration, the quality of lifecycle governance matters as much as the review workflow itself. The practical implication is that teams should align identity lifecycle discipline with review isolation, or the control plane will drift.
From our research library:
- Over 70% of organisations lack automated access risk analysis, user access reviews and provisioning and deprovisioning, according to Pathlock's 2025 Digital Transformation and Access Risk Report.
- Read next: NHI Lifecycle Management Guide
What this signals
Access review governance is becoming a platform design problem, not just a policy problem. Teams that still treat certification as a single workflow will miss the control boundaries that matter most: row scope, configuration scope, and entity scope. The practical shift is to audit whether the platform can prove who saw what before you rely on the resulting evidence.
Granular permissioning only works when lifecycle governance keeps pace with shared administration. Once review access is mediated through groups and inherited configuration, stale membership becomes a visibility risk, not only an access risk. That is why IGA teams should align review scoping with joiner-mover-leaver discipline and entity ownership, especially in multi-business-unit environments.
For practitioners
- Separate action rights from visibility rights Design review permissions so campaign administration, reviewer decisions, monitoring, and audit certification are governed independently from review-data visibility.
- Scope reviewers to assigned rows only Ensure reviewers can only see the rows they are assigned and nothing else, even when they also hold an administrative persona elsewhere in the tenant.
- Apply Limit Access by operating entity Use configuration-level access controls to keep one entity's review campaigns, review configurations, and inherited reviews isolated from another's.
- Govern group membership as part of the control model Treat SCIM-managed and customer-managed groups as governance objects, because inherited access can widen review visibility if memberships drift.
Key takeaways
- Access reviews only function as defensible controls when visibility and decision rights are separated by persona and by entity.
- The main governance risk is not simply too much access, but too much shared visibility inside the review process itself.
- Teams should verify row-level scoping, configuration-level isolation, and lifecycle-governed group membership before treating review output as compliance evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing who can access review functions and review data. |
| Recommendation — Apply PR.AA-05 to keep review permissions and row visibility aligned to job role and scope. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Granular review roles and row restrictions are a least-privilege design problem. |
| Recommendation — Use AC-6 to limit campaign administration, reviewer action, and audit visibility to the minimum needed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Group membership and role assignment govern access to review workflows and evidence. |
| Recommendation — Manage review access through disciplined account and group lifecycle control. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The article focuses on controlling access to review data and actions across entities. |
| Recommendation — Document and enforce access control rules for review visibility, administration, and certification. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Inherited access through groups and roles creates lifecycle risk if memberships are not removed cleanly. |
| Recommendation — Remove stale review access promptly when users change roles or leave the operating entity. | ||
Key terms
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
- Row Assignment: A control that limits a user to the specific review items assigned to them. It reduces exposure by preventing reviewers from seeing unrelated line items, and it helps ensure that approval or rejection decisions stay tied to the exact access being certified.
- Limit Access: A scoped permission model that restricts who can read, update, or manage specific review configurations and campaigns. It is used to keep review evidence isolated across entities, departments, or operating units while preserving least privilege for the people running the program.
- Entity Segregation: Entity segregation is the separation of review data and control rights across distinct business units or operating entities. It matters when one platform serves multiple compliance domains, because evidence is only defensible if the data boundaries remain clear.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org