GOVERNANCE
Cross-app
GRC Lead

Scope every access review by department, role, or manager to eliminate noise and focus on what auditors check

Why this is hard without Oleria

Reviews scoped to "everyone with access to App X" are impractical when App X has thousands of users. Org-wide reviews fail under load — reviewers can't sustain the volume, and the ones that do produce weak evidence. Without a way to scope the review to a tractable population, governance defaults to skipping the review (audit gap) or rubber-stamping it (control failure).

Most IGA tools support filtering at submit time but treat slicing as an afterthought rather than a first-class scoping mechanism. The result: enterprises run one big review and either fail it or fake it, rather than running ten smaller reviews aligned to actual reviewer accountability. Attribute-Based Access Review Scoping turns unmanageable org-wide reviews into targeted, auditable cycles that reviewers can actually complete with confidence.

AT A GLANCE

Dept, manager, date
Slice attributes
App + group
Combine with
Per-slice
Cadence

Oleria AI

The same three-signal engine (Dormant Days, Peer Group, HR Changes) drives recommendations within the sliced population. Slicing changes the scope; the intelligence per line is unchanged.

How it works

  1. Pick the access review type - Application access review and select the applications you want to review
  2. Slice the user population — Filter by department, manager, or start date. Combine filters where needed.
  3. Pick reviewer and cadence — Manager (mapped to a manager-tree slice naturally) or specific user (e.g., department lead).
  4. Run the review — Per-line three-signal evidence and recommendations on the sliced population. Decisions captured per cycle.

Frequently Asked Questions

How does this fit alongside HR-change-driven reviews?

Slicing answers "what population." HR-change signals (D-13) answer "what changed." The two combine: run an HR-change-aware review scoped to the finance department, and you see only the finance employees with recent role / department / status changes — a tighter, more actionable cycle than a department-wide or org-wide review.

What about transitive manager-tree slicing?

Direct manager filter today — review users who report to a specific manager. Transitive manager-tree filtering (the manager's manager's reports too) is a roadmap consideration; today, multi-level org reviews are run as separate slices per manager.

Why slice by start date specifically?

Recent joiners are typically the highest-risk slice. Joiner provisioning bundles can over-permission by template; new hires are also least observed in operational data, so dormancy and peer signals are noisier. A recurring "users joined in last 90 days" review becomes a hygiene control on the entry point rather than waiting for the next quarterly cycle to catch problems.

What employee attributes can I slice by?

Department, Job function, manager, and start date today. The user population on a application can be filtered by any combination of these. Each slice produces its own scoped campaign with its own reviewer assignment and cadence.