Setting Up Access Reviews in Zluri

1. Overview

Access reviews are a critical component of an organization’s identity governance and compliance efforts. These reviews ensure that users retain only the necessary access to applications and systems, in accordance with the principle of least privilege and internal security policies.

Zluri’s Access Reviews module provides InfoSec and IT teams with a centralized platform to configure, execute, and monitor access certifications across the SaaS ecosystem. The module supports end-to-end administration of the review lifecycle, including:

• Selecting applications and user groups for review
• Assigning reviewers by role or individual
• Tracking reviewer progress according to configured timelines
• Closing the loop with automated remediations through playbooks to revoke or modify access based on review outcomes
• Generating timestamped, audit-ready certification reports

Zluri eliminates manual overhead by integrating with identity providers, HRMS tools, and SaaS applications to surface the necessary access data. The platform also enforces controls such as self-review restrictions and mandatory justifications for sensitive actions.

Upon completion, Zluri automatically generates non-editable PDF reports that serve as proof of access validation for audit and compliance requirements.

Zluri also tracks every review cycle from initiation to closure, with completed certifications accessible under the Completed tab for ongoing audit readiness and reporting.

2. Roles

The Access Reviews module in Zluri relies on distinct roles to manage responsibilities throughout the certification lifecycle. These roles are involved at different stages—including certification creation, performing access reviews, managing certification progress, tracking remediation actions, and generating audit-ready reports.

Primary Reviewer

The Primary Reviewer is the first-level reviewer assigned to a record. This can be configured as either:

• A specific named user, or
• A role-based assignment (e.g., App Owner, Reporting Manager)

If the role is mapped to a valid user for a given record, that user receives the task and becomes responsible for reviewing access.

Fallback Reviewer

The Fallback Reviewer is a named user assigned as a backup reviewer. This user is automatically assigned to a record when the configured primary reviewer is invalid or not found. This could happen if:

• The role-based Primary Reviewer (e.g., App Owner) is not mapped to a user for that application
• The assigned reviewer is inactive or missing from Zluri

Example:

If “App Owner” is assigned as the Primary Reviewer but the application does not have any App Owner defined, the system assigns the review to the configured Fallback Reviewer, such as [email protected].

Certification Owner

The Certification Owner oversees the entire certification lifecycle, ensuring reviews are completed within timelines, validating review outcomes, and triggering remediation. This role must have one of the following permissions in Zluri:

• Owner
• Admin
• IT Admin

Current Reviewer (System-Determined)

The Current Reviewer is assigned by Zluri based on the primary and fallback reviewer configurations. Only the Current Reviewer can take review actions (Approve, Modify, Revoke).

• Zluri automatically assigns the Current Reviewer from:
  • Primary Reviewer (if configured)
  • Fallback Reviewer (if Primary Reviewer is unavailable)

How Reviewer Assignment Works

1. Primary Reviewer Check: Zluri first looks for a valid Primary Reviewer configured for the record.
2. Fallback Reviewer Assignment: If no valid Primary Reviewer is found (for example, the role is unassigned or inactive), the record is assigned to the configured Fallback Reviewer.
3. Self-Review Handling: If the assigned reviewer turns out to be the same user whose access is being reviewed, Zluri applies the Self-Review Configuration:
   • If Allow Self Review is enabled, the reviewer can review their own record.
   • If Auto-Reassign is enabled, Zluri automatically reassigns the record to the role or user specified (e.g., Reporting Manager, Department Head, Fallback Reviewer, or a named user).
   • If neither option resolves the conflict, the record is assigned to the Certification Owner by default.

This process ensures every record has a valid reviewer and provides a clear, auditable chain of assignment decisions.

3. Prerequisites

Before initiating an access certification in Zluri, the following configurations and dependencies must be in place to ensure smooth setup and execution.

• Role Mapping (App Owner, Reporting Manager, etc.)

  Ensure that key roles are already assigned within Zluri, as they will be used for reviewer assignment during certification creation. Recommended roles include:

  • App Owner
  • App IT Owner
  • Department Head
  • Reporting Manager

• Integration Readiness

  To support automated remediation actions, the target applications must be integrated with Zluri via direct API connections. Integrations must be active and include the necessary permissions for executing deprovisioning and modification actions.

  If an integration is available but not connected, Zluri displays a banner with an option to configure it during playbook setup.

  

• Data Ingestion: Directory, Apps, Groups

  Ensure that Zluri is receiving complete and current data for:

  • Directory sources (e.g., Okta, Azure AD)
  • Application user lists (via integration, SDK, or CSV import)

  This data is critical for accurate user access mapping and reviewer context during the certification.

• Reviewer Login (Google SSO or SAML)

  Ensure that reviewers can access the Employee View using organization-provided SSO (Google or SAML).

  Learn more about configuring SAML here.

• Playbook Availability

  To enable remediation actions within an access review certification, at least one of the following types of playbooks must be created and published:

  • Application-specific playbooks: Tied to a specific app and typically used for direct integration-based actions (e.g., revoke access in Google Workspace, remove user from Zoom, Remove from Okta group).
  • Global playbooks: Independent of any app and useful for manual or task-based workflows that can be reused across applications (e.g., create Jira ticket, notify security team).

  These playbooks must be published before the certification is created. During certification setup, Zluri requires selecting remediation actions (for Revoke and Modify decisions), and the action setup will be blocked if no valid playbooks are available.

  Note: Admins can create global playbooks from the Access Reviews → Playbooks tab. These can then be selected at the certification or application level as needed.

4. Playbook Setup

Zluri allows admins to configure playbooks that automate or facilitate remediation actions during an access review. Playbooks can be tied to either applications or groups depending on the entity under review. In addition, admins can create global playbooks for reusable, cross-application workflows.

Application-Level Playbooks

Application-level playbooks automate or standardize actions when reviewers revoke or modify a user’s access to an application.

• Created in the App Playbooks section of each integrated app.
• Support automated actions (e.g., Disable Account, Remove User from Groups) and manual tasks (e.g., create Jira ticket).
• Automated actions require the app to be integrated with Zluri and connected with the correct permissions.
• Multiple playbooks can be published for different scenarios, such as handling inactive users, downgrading privileged roles, or adjusting license types.

Group-Based Playbooks

Group-based playbooks operate like application-level playbooks but target group memberships instead of application access.

• These playbooks are always created under the source application where the group resides (e.g., Okta, Google Workspace, Azure AD, JumpCloud).
• During setup, admins select the specific group and configure actions such as:
  • Remove User from Group
  • Modify Group Membership (e.g., move user to another group, downgrade a role if supported by the source).

This ensures that automation for groups is managed in the same App Playbooks section as application playbooks, but with actions tailored for group memberships.

Deprovisioning Playbooks

Deprovisioning playbooks define the actions Zluri will take to revoke or modify access as part of an access review certification. Playbooks can contain automated or manual steps and are configured per application or group.

Accessing Deprovisioning Setup

1. Go to Applications in the Admin View.
2. Select the application (e.g., Slack).
3. Click Automation in the left panel.
4. Open the Deprovisioning tab under App Playbooks.

Creating a Deprovisioning Playbook

1. Click + Add in the Deprovisioning Playbooks section.
2. A blank playbook opens. Search or browse available actions in the All Actions panel.
3. Choose an action (e.g., Remove User from all Groups, Deactivate User).
4. Click + Add next to the action. The selected action appears in the right-hand panel.
5. Select the Application Instance if there are multiple connections.
6. Optional enhancements per action:
   • Apply Conditions: Add rules to control when the action triggers.
   • Require Approvers: Add a step for approval before the action executes.
   • Add Delay: Schedule execution after a fixed delay.

Handling Missing Permissions

If Zluri lacks permissions to run an automated action:

• A warning appears under the action.
• Admins can:
  • Click + Add Permission to connect required scopes.
  • Ignore the warning (if action won’t be executed).
  • Click Convert to Manual Task to convert it into a manual assignment.

Finalizing and Publishing

1. Add additional actions as needed.
2. Click Publish App Playbook to activate the playbook.
3. The playbook status changes from Setup Required to Published.

Adding Manual Tasks via “Convert to Manual Task”

When Zluri doesn’t have the required permissions to execute an automated remediation action, the platform allows admins to convert the action into a manual task directly within the playbook.

This ensures continuity in remediation workflows even when automation is blocked or not desired.

When This Option Appears

• While configuring an automated action in a playbook (e.g., “Add User to SSO Groups” or “Remove User from All Groups”).
• If Zluri lacks required scopes or integration permissions, the action status displays a warning.
• A Convert to Manual Task link becomes visible beside the action.

Manual Task Setup Flow

1. Click Convert to Manual Task.
2. Select the integration tool or task management system for assignment (e.g., Jira).
3. Choose a template (or select “Custom”).
4. Fill in:
   • Project
   • Issue Type
   • Summary
   • Description
   • Assignee (e.g., Department Head)
   • Due Date (in days)
5. Click Save Task.
6. The task is added to the playbook and marked as Manual Task in the overview.

Global Playbooks

Global playbooks are reusable workflows that are not tied to a specific app or group. They are created under Access Reviews → Playbooks and can be applied across certifications.

• Common use cases include manual or task-based workflows (e.g., notify Security, create a ServiceNow ticket).
• Global playbooks can also serve as default remediations at the certification level, then be overridden at the application or group level if required.
• Admins should use consistent naming (e.g., Jira – Remove User Access) to make them easy to identify and reuse.

When to Use a Global Playbook

Global Playbooks are ideal when:

• A remediation action needs to apply across multiple applications.
• Manual or task-based workflows (e.g., Jira tickets, notifications) are required.
• Standardized processes (e.g., “Notify Security,” “Raise ticket to HR”) need to be reused.
• Application-specific integration scopes are unavailable or unnecessary.

How to Create a Global Playbook

1. Go to Access Reviews → Playbooks in the Admin View.
2. Click + New Playbook.
3. Enter a name for the playbook.
4. Click Add an Action and choose from:
   • Zluri platform actions
   • Manual task (e.g., via Jira, ServiceNow, email)
   • Trigger another playbook
5. Configure the action:
   • Define task details, approvers, delays, and conditions
   • Assign to a user, role, or integration system (e.g., Jira Project)
6. Click Publish Playbook to activate.

Where Global Playbooks Are Used

• During Certification Setup, under “Configure Remediation Actions”
• As default remediations when creating a new certification
• As fallback actions when app-specific playbooks are missing or unavailable

Admins can select these playbooks when defining what happens if access is revoked or needs to be modified.

5. Creating a Certification

Zluri enables administrators to configure and launch access certification campaigns from the Access Reviews module in the Admin View. Each certification can include one or more applications or groups, along with their reviewers, user scope, column selections, and remediation actions.

Step 1: Access the Certification Setup

1. Navigate to Access Reviews in the left sidebar.
2. Click Create New Certification in the top-right corner.
3. A three-step configuration wizard opens:
   • Certification Details
   • Set Up Certification
   • Complete Setup

Step 2: Certification Details

1. Enter the Certification Name and assign a Certification Owner.
   • Owners must have Owner/Admin/IT Admin privileges.
2. (Optional) Add a Certification Description — rich text and links are supported. Example: Link to an internal knowledge base article with review process guidelines, or attach an access matrix that reviewers can reference while making decisions.
3. Select the entity type to review:

• Applications
• Groups

1. Configure optional defaults (these apply to all selected entities unless overridden later):

   • Default Reviewers – Assign role-based or specific reviewers

   • For applications, reviewer options include App Owner, Reporting Manager etc.

   • For groups, app owner roles are not available; reviewer options are limited to roles like Reporting Manager and Department Head.

   • Multi-level reviews are supported. See How multi-level reviews work in Zluri for configuration details.

   • Default Remediations – Assign playbooks that will automatically run when reviewers take revoke or modify actions.

Click Next to continue.

Step 3: Set Up Certification

a) Applications

1. Select Application – Search and choose the application(s) to be reviewed.

2. Assign Reviewers – Define primary and fallback reviewers. Multi-level review chains can be added if the process requires multiple stages of validation.

3. Select Users – Filter which users should be included in the review.

   • Filters can use both default attributes (e.g., department, employment status, location) and account-level attributes (e.g., app roles, licenses, last login).
   • Example use cases:
     • Include only inactive employees still holding licenses.
     • Flag external contractors with access.
     • Scope reviews for privileged roles like Admin or SuperUser.

4. Select Columns – Choose which attributes reviewers will see in the review table. Examples:

   • App Role
   • License Type
   • Last Login
   • Department
   • Employment Status Columns can also be reordered to prioritize critical information for reviewers.

5. Set Up Actions – Configure remediation playbooks that will run based on reviewer decisions:

   • Approve – No action required.
   • Revoke – Trigger a deprovisioning playbook.
   • Modify – Trigger a playbook to downgrade or adjust user access.

b) Groups

1. Select Group – Search and choose the group(s) to be reviewed. The UI shows the group name, number of members, and group source (e.g., Okta, Azure AD).

   

2. 2. Assign Reviewers – Add reviewers for each group. Multi-level review chains are supported. (App owner roles are not available for groups.)

   

3. Select Users – Define which group members to include in the review.

• Filters focus on user-related attributes like employment type, department, or group role.
• Example use cases:
  • Target inactive employees still in security groups.
  • Scope reviews for users with privileged memberships (e.g., admin groups).
  • Exclude groups containing only contractors.

1. Select Columns – Pick which user attributes reviewers will see during group reviews. Examples:

• Department
• Group Role
• Employment Status

1. Set Up Actions – Configure playbooks for revoke or modify actions.
   • Global playbooks – Task-based actions such as raising Jira tickets or sending notifications.
   • App playbooks tied to the group source – For example, in Okta, trigger actions like Remove User from Group or Move User to a Different Group.

Note:

Applications and groups can be added multiple times in the same certification with different scopes and reviewers.

• Example:
  • App 1 – Privileged roles reviewed by Reporting Manager → App Owner
  • App 1 – Non-privileged roles reviewed by Reporting Manager only

This flexibility allows admins to separate high-risk user sets from standard user sets and assign them different reviewers or remediation workflows.

Click Add Application or Add Group to finalize setup for the selected entity. Repeat the steps as needed to include more applications or groups.

Step 4: Complete Setup

1. Choose whether the certification should:

• Start Now – Launch immediately. The certification appears under Ongoing and reviewers are notified to begin.

• Start Later – Schedule for a future date. The certification appears under Upcoming and remains locked until the start date is reached.

1. Set timelines:

• Review End Date – Deadline by which all reviewers must complete and sign off their actions.

• Remediation End Date – Deadline for completing all remediation tasks after reviews are concluded.

• Notifications – By default, Zluri sends automated reminders 48 hours before deadlines:

• To reviewers with pending actions (before the Review End Date)

• To the Certification Owner (before the Remediation End Date)

1. Configure Self-Review Handling:

Decide how the system behaves if a user is assigned to review their own access.

• Allow Self Review – Reviewers can approve or revoke their own records.
• Auto-Reassign – Automatically reassigns the record to another role or user:
  • Role options: Reporting Manager, Department Head, Certification Owner, Fallback Reviewer
  • User option: Assign to a specific named user

1. (Optional) Enable Recurring Certifications.

• Choose a frequency (e.g., monthly, quarterly) to automatically schedule future certifications with the same scope and configurations.

Click Create Certification to finalize and launch, or Save Draft to pause setup and continue later.

Save As Draft

Creating and configuring a certification is often a multi-step process. Admins may need to pause setup at various points—for example:

• A remediation playbook needs to be created or updated
• Discovery data must be verified or refined
• Configuration needs internal review before launch

To support these scenarios, Zluri offers a Save Draft option at any stage of the certification setup. This allows work-in-progress certifications to be paused and resumed later.

All saved drafts are accessible from the Drafts tab in the Access Reviews module. Drafts can be reopened, updated, or finalized by clicking Create Certification once ready.

Post-Launch Behavior

Once the certification is created, it will appear in either the Ongoing or Upcoming tab, depending on the Start Date:

• Start Now: The certification appears immediately in the Ongoing Certifications tab.
• Start Later: The certification appears in the Upcoming Certifications tab and remains non-editable until the configured start date and time.

When the certification is live under Ongoing Certifications, each row in the table includes:

• Review Stage – Current phase of the certification (e.g., Review, Remediation).
• Certification Owner – The designated owner responsible for managing progress.
• Connected Entities – The applications or groups included in the certification.
• Review Status – Progress bar showing number of records completed vs total.
• Due Dates – Deadlines with indicators such as “Overdue: 5 days” or “Due in 6 days”.

Reviewers are notified automatically when the certification enters the Ongoing state.