Welcome to the Access Reviews product documentation!

Overview

Reviews leverage the Veza graph to provide repeatable and scalable certification campaigns for user access and entitlement review. Depending on your organization and compliance requirements, the scope of review might include user access to data, resource entitlements, roles, groups, policies, or any other source > destination relationship discovered by Veza. Access reviews can involve IdP identities, local users, service accounts, or any other entity Veza has discovered.

Access Reviews support many assigned users per review, with options for manual assignment after review creation. A mobile device experience provides simplified filtering, bulk actions, and reassignments for reviewers on the move.

The reviewer's interface presents the access under review in a spreadsheet-like format, with columns showing attributes and details such as roles, groups, permissions, and decisions. Reviewers can open an assigned review to approve or deny the level of access according to business policy and compliance requirements. Typically, these users are compliance engineers, managers, and system or data owners with the Access Reviewer role.

When conducting a review, users will review each assigned row to take action and leave notes on each result. If the original reviewer cannot decide, they can re-assign the row to another user in the organization. Reviewers can sort, filter, and act in bulk for efficient workflows.

Downstream system integrations enable remediation processes. Email notifications keep stakeholders informed when decisions occur, deadlines approach, and reviewers are (re)assigned.

While the original review configuration search conditions can be edited, the final decisions and the relationships under review are immutable. Completed reviews represent a snapshot of all decisions: immutable and vault-ready evidence for internal and external auditors.

Get Started

The following topics can help you familiarize yourself with Access Reviews concepts and workflows:

Product Documentation

For more information, see the rest of the Access Reviews documentation. Expand the section on the left navigation to view all topics, or use the quick links for popular pages:

Overview

Create a review to start a one-time review based on the specified configuration. In doing so, you can set the due date and assign default reviewers for all rows. You can also automatically apply decisions to some rows, or customize the time frame for which to review access.

You can create a review as a draft, or publish it right away. Use the Create as draft option to inspect the results and individually assign rows, before triggering any email notifications specified in the review configuration.

Once the review is published, reviewers can log in to Veza to approve or reject access using the reviewer interface.

Before you start

You will need:

Create a new review

1. On the Configurations page, find the configuration you will create a review for.

2. Click the review name to open the Details page.

3. Click New Review to open the review creation wizard.

4. Select Review Configuration:

   • Leave this unchanged to create a review for the configuration you just viewed. Alternatively, you can use the dropdown to pick any saved review configuration.

5. Set Due Date:

   • Pick the date the review will finish. Reminder emails can trigger on, before, and after the due date depending on the notification settings in the configuration.

6. Assign Reviewers:

   • Choose users from the list to assign them as reviewers for all rows. If the configuration includes reviewer notifications, notification emails will be dispatched on review publication.

7. Review Intelligence:
8. Time Frame Options: Use this section to review access at a particular point in time, or based on Veza’s latest graph data:

   • From the moment the review is created: Uses the most recently parsed integration data, including any changes since the last daily snapshot.

   • From the most recent daily snapshot: Uses Veza's most recent snapshot (which might be different from the latest data).

   • From another snapshot: Choose Graph data from a previous date. Use this option to review access at a specific point in time.

9. Data Source Status: Under Time Frame Options, click Data Source Status to view details for the chosen snapshot. Use this option to check if an important integration is inactive or reporting errors.

10. Click Create or Create and Publish to save the review and return to the configuration details page.

See also

• Schedule an Access Review

• Draft Reviews

• Create a Configuration

Overview

Thank you for choosing Veza Access Reviews — we're excited to support you on your journey! This document provides a quick overview to help you get started creating and managing access review campaigns with Veza.

See the included sections to create your first configuration, start a review, and assign it to reviewers.

For users logging in to approve or reject access for the first time, see Get Started: Access Reviewers

Access review concepts

Access Reviews enable you to create user access and entitlement review campaigns using the user, resource, and RBAC metadata that Veza stores in the authorization graph. Two basic concepts enable scalable, repeatable campaigns:

• Configurations: Settings that define the scope of a review, along with scheduling, orchestration, and notification settings. Each review configuration is tied to a graph query. This query can include source and destination entities and requirements for related or unrelated entities such as intermediate groups or roles. The scope can be further constrained with filters on tags, attributes, permissions, or specific entities.

• Reviews: Individual instances of access reviews, each with a unique deadline and reviewers. Each review uses a snapshot of graph data at the time of review creation. Upon review creation, individual reviewers can log in to Veza to view their assigned reviews, approve or reject line items, and sign off on decisions.

Before you start

• The relationships available for review depend on the Veza Integrations you have enabled. This guide assumes you've already added an identity provider, cloud service provider, or other data sources to review.

• To configure Veza Actions, you'll first need to add a destination system by enabling communication with an external target by enabling built-in Veza Actions or configuring custom Webhooks.

• You can choose reviewers from all users in your organization by adding a Veza integration for your identity provider. See Configuring a Global Identity Provider to enable reviewer suggestion and auto-assignment using your IdP.

• To manage access to Veza from within your organization's identity provider and enable single sign-on for reviewers, see Sign-In Settings.

• The Veza support team can customize some settings for your tenant. The exact options and behavior will depend on Access Reviews Global Settings.

Create an access review configuration

A review configuration defines the scope of a periodic or one-time access or entitlements review, including:

• A Query defining the entities and relationships under review, such as Active Directory Users assigned to Active Directory Groups. The rows under review are the results of this query. You can select whether the query runs against the current graph, the most recent snapshot, or historical data, depending on the chosen time frame.

• Default Notification and Veza Action settings, inherited by all future reviews for that configuration.

• Basic attributes such as Name and Description for identification and internal reference.

See Create a Configuration for more details.

Starting and scheduling reviews

After saving a configuration, you can create reviews for it. When creating a review, you will pick a due date, and add default reviewers for all rows.

• The Configurations page shows all saved configurations. Choose one and click New Review to create an individual review instance. See Create a Review for detailed steps.

• To Schedule a review on this page, open the configuration Actions dropdown menu. See Schedule an Access Review to initiate reviews on a set frequency automatically.

• Review Intelligence Policies enable automatic actions on rows that already were signed off in the last review for the same configuration. More sophisticated rules can be configured by administrators using an API. See Review Intelligence Policies to add custom automations.

• Assign Managers: Assign reviewers by email address. These reviewers are assigned to all rows by default, after which row-level reviewers can be assigned.

  • Reviewers can be local Veza users or any user in your organization, from your Identity Provider (IdP). See Configuring a Global Identity Provider to enable assigning IdP users as reviewers.

  • Veza can auto-assign user managers or resource owners based on tags or graph metadata upon review creation.

  • Operators can also assign fallback reviewers for when an owner cannot be identified. See Reviewer Selection Methods for the default fallback behavior and tunable settings.

• See Draft Reviews to inspect the results and assign reviewers for individual rows before publishing it and sending notifications.

The reviewer interface

Opening a review shows the reviewer interface, displaying each row of access to be reviewed. These rows of access are the results of the configured query, shown in a table for individual approval or rejection and final sign-off.

Each row can represent a relationship between two entities, such as Okta users and Okta Admin Roles, or a single entity, such as a list of local users in Snowflake or public AWS S3 buckets. The table can show additional information about each entity, including the resulting permissions for a source and destination pair (such as Okta user permissions on Snowflake tables).

For each result, reviewers will approve or reject, add notes, and finalize their decision before signing off. They can:

• Approve the row. This means that the reviewer agrees that the access described by this row is appropriate.

• Reject, indicating that the level of access on this row is inappropriate.

• Mark as Fixed: If a remediation action has been taken on a rejected row, operators can mark the issue as fixed before completing the review. Notes can provide additional detail (such as a ticket number or remediation steps).

• Re-assign a reviewer: This allows the reviewer to reassign the review of this row to another individual. This is convenient when somebody else has more decision-making authority to approve or reject access for a specific row

• Sign off: Signing off prevents any further decisions. Once signed off the only allowed change is to update the “Marked As Fixed” status if the row was rejected.

• Update the note: This allows reviewers to annotate individual rows of access. This is useful if a reviewer wants to explain or justify their decision.

Reviewers can customize their views by filtering the results and rearranging columns to show important details or hide unwanted information. Using filters in combination with bulk actions enables actions over pages of results for faster decision-making. See Filters and Bulk Actions.

Operators can use the reviewer interface to customize settings unique to the review. Use the sidebar to update the due date or enable unique email notifications or Veza Action settings to override the configuration defaults.

Completing a review

An administrator or operator can close a review by marking it Complete. No further changes are possible after the review is final.

Overview

In Veza, a configuration sets the parameters for conducting access or entitlement reviews. Operators initiate reviews based on these configurations, which occur periodically or as one-time assessments. Each review is tied to a unique due date and a designated set of reviewers.

Configurations allow for varying scope—ranging from broad, covering all users across numerous cloud services and data assets, to specific, focusing on individual departments or applications. Additionally, configurations can address relationships between policies, groups, or roles. Using queries, you can conduct different types of reviews in Veza:

• Access Reviews: Ensure appropriate access levels across services and resources, verifying that permissions align with user roles and pose no security risks.

• Entitlement Reviews: Validate and certify actual permissions on specific resources, ensuring they are necessary and comply with organizational policies.

Each configuration includes a:

• Name and Description: Used for internal reference and identification.

• Query: Defines what to review, with options to filter by tags, attributes, or other criteria.

• Notifications and Veza Actions: Automate communications and actions, inherited by future reviews.

For detailed steps on setting up a new configuration, see the sections below.

Create a new review configuration

To create a configuration and set the underlying query:

1. Open the Configurations page and click the New Configuration button.

2. Give the configuration a unique name and a description.

3. Build a query to define the scope of the review.

4. Add email notifications to inform reviewers of assignments. You can also set reminders based on when the review is due. You can enable these for reviewers, the configuration creator, or additional recipients.

5. Enable Veza Actions by choosing integrations or webhooks to trigger based on decisions and reviewer changes. For example, you can create a service desk issue on row rejection, and send an email when all results are signed off.

6. Preview the results and save the configuration.

Step 1: Add basic configuration details

To create a configuration:

1. Log in to Veza and open the Access Reviews section. On the navigation sidebar, open the Configurations page.

2. Click New Configuration to open the builder.

Give the configuration a name and description.

1. Configuration Name: Enter a brief title to describe the access review. Reviews for this configuration will show the name in email notifications and reminders.

2. Configuration Description (Optional): Describe the query used, and the purpose of the configuration for other administrators and operators.

Step 2: Define the review scope

Each configuration must be scoped to a single graph query that specifies a set of entities or an access relationship, such as "Okta User to Snowflake Database." You can create a query or pick a saved query to scope the review.

To review entities of several types at once, pick an entity type grouping as the source or destination. These appear at the top of the list and contain multiple entity types. Groupings include:

• All Resources: All "resource"-type entities that Veza has discovered, including AWS S3 Buckets, Snowflake Tables, and GitHub Repositories.

• All Principals: Includes all entities that Veza has discovered and labeled as “identities” that can have permissions on a resource, including Active Directory Users, Okta Users, and Snowflake Local Users.

• All Top Level Principals: All identities that cannot be assumed by another identity. Use this entity type grouping to show primary corporate identities, and filter out any low-level identities (such as local users) they can assume. Reviews for this configuration will include any local account users and service accounts that don’t correlate to any upper-level identity.

To define the review scope in the configuration builder, select a query from Saved Queries or create one with using the Query Builder tab:

1. Type to search for a Source entity type. This could be a specific type of user, role, group, or resource, such as “Okta User” or “S3 Bucket.” Reviewers will sign off on source entities and, if defined, the source entity’s relationship to a destination entity, presented in rows for approval or rejection. You can preview these source entities based on the current graph data.

2. Click to add Destination entity types. These could be specific resources, roles, or groups assigned to entities of the source type. In the reviewer interface, each row will contain a source > destination pair (e.g., a single Okta User and an S3 bucket they have permissions on.)

   2.1. Click to open the selection menu.

   2.2. Entity type groupings appear at the top of the list. Scroll down to search for a single entity type.

   2.3. Tick the boxes to enable one or more destinations

   2.4. Click Preview Destination Entities to view the current results in the table.

   The destination can be a data resource or a related IAM or RBAC entity, such as a role or group. You can also reverse the query to certify applications or resources accessible by users.

3. Customize the review with Advanced Options:

   Depending on the query, rows can include extra details about the path connecting the source and destination. Advanced options enable reviewers to evaluate and certify not only an identity's access and permissions, but how that access is granted:

   3.2. Enrich with IdP/HRIS metadata (Early Access): Veza can map identities to a corresponding user in an Identity Provider, or worker record in a Human Resource Information System (HRIS). Enable this option and choose a data source to use for enrichment. In the review interface, additional columns show the linked entity's attributes.

   3.3. Relationship: This option is typically used to enable constraints on an entity that connects the source and destination, such as a Snowflake role granting access to a Snowflake schema.

   • Reviewers can enable extra columns to show details about the intermediate entity, and filter the rows based its properties, such as the name or last updated time of Okta Groups connecting Okta Users and Okta Applications.

   3.4. Summary Entities: Adding Summary Entities enables an additional column in the review, showing intermediate relationships in the path connecting the source and destination entity. These entities can include nested groups or roles, projects, or policies.

   See Review Presentation Options for more about these query parameters.

   3.5. Exclude or Require Entities: Hide or only show source and destination pairs with any of the chosen entity types in the path. Use this option to review, for example, users with no relationships to groups.

4. Add Filters to constrain results (optional):

   Applying filters narrows the scope of a review to find exactly the relationships and entities you want to review. Filter groups can apply to any attribute Veza has collected for entities in the search.

   To create attribute filters:

   4.1. Click +Add Filter Group.

   4.2. Choose the Entity Type to apply the filter to.

   4.3. Choose from possible Attribute Fields available for that entity type.

   4.4. Choose an Operator. Available operators depend on the attribute type, such as contains for lists, before for dates, or equals.

   4.5. Choose an Attribute Value from the dropdown. Possible selections auto-fill when filtering by Name, or you can enter any value.

   You can combine groups of filters to create finely-focused reviews, and filter on tags and permissions. See Filters for more information.

5. Filter by Tags (optional):

   You can optionally filter the review scope by adding tag filters, which support both Veza tags and provider-native tags. For example, you might use a 3rd-party tool to tag certain resources in AWS, or automatically label entities according to business unit, compliance requirement, or environment type.

   5.1. Click +Add Tag Filter.

   5.2. Pick the Entity Type to filter.

   5.3. Choose Tags to Include. Click to show a short list of tags, or type to search from all available tags.

   5.4. Optionally pick Tags to exclude. Any entities with these tags are omitted from the results.

6. Filter by Permissions (optional):

   To only review access for entities with certain permissions on the destination entity, add a permissions filter:

   6.1. Toggle a permission type: Effective or System.

   • To show users with specific Create/Read/Update/Delete capabilities, select Effective Permissions.

   • Use System Permissions to filter by specific permissions based on the provider's native terminology.

   6.2. Select Permissions: Use the dropdown menu to pick one or more individual permissions.

   6.3. Operator: Filter results when they have any of the chosen permissions (OR), or match the specified conditions exactly (AND).

Step 3 (Optional): Enable email notifications

Set default email notifications to alert reviewers and other stakeholders. Reviews for the configuration inherit these notification and reminder settings. See Email Notifications and Reminders for more details.

1. Notifications: Emails to inform reviewers, managers, and stakeholders based on events such as review start or reviewer reassignments.

   1.1 Tick the boxes to enable notification recipients. These can be the assigned reviewers, their managers, and additional recipients specified by email.

   1.1 Pick the events that will trigger notifications (on row reassignment, on review start, and on review completion).

2. Reminders: Action Needed: These emails inform users after a period of inactivity, or before, on, or after the due date.

   2.1 Enable recipients for reminders.

   2.2 Pick the events and relative dates when emails trigger (on row reassignment, review start, and review completion).

3. Final Reminders: Action Needed: Escalated reminders, typically used to emphasize a missed deadline or extended period of inactivity:

   3.1 Enable recipients for final reminders.

   3.2 Pick the events and relative number of days when emails trigger (after a period of no changes, or before, on, or after the due date).

Reviewers can be auto-assigned to Managers and Resource Owners on review creation. To ensure that these users receive a notification, enable reviewer notifications on review start.

Step 4 (Optional): Enable Veza Actions

Veza can trigger actions in external systems on review completion, row reassignment, or sign-off of an approved or rejected row. Enable these in the Veza Actions section of the configuration builder.

1. Tick the box next to an event trigger to enable Veza Actions.

2. Use the dropdown to pick a Veza Action for each event.

If no targets are available, you can skip this step. See Veza Actions for Access Reviews for more details.

Step 5: Save the configuration

Confirm your choices and save the configuration:

1. Click Create Configuration at the top right to save your work.

You can now open the configuration details make adjustments or Create a Review.

Overview

Use bulk actions in the review interface to update many rows at once with a note, decision, or sign-off state. You can also use bulk actions to change reviewer assignments for a group of results.

Filtering the reviewer interface based on specific criteria and acting on rows in bulk is a recommended workflow for working on large access reviews.

For example, bulk actions can:

• Update all rows that already have a decision, note, or an assigned reviewer.

• Reassign reviewers based on an attribute such as department, region, or manager.

• Approve or reject access for specific permissions.

This document describes a recommended workflow for acting on all results that match the current filter.

Filter access review rows

Use filters to apply group actions based on an attribute, decision, or other column for a result row:

1. Click Filters at the top of the review interface.
2. Click Show More to reveal all possible columns.

3. Find an attribute to filter on and click on it.

   Filterable attributes are grouped with a prefix to indicate the element of the access relationship they apply to.

   • Source: Attributes on the entity whose access is under review (e.g., user name or group type).

   • Destination: Attributes on the related entity.

   • Intermediate: Attributes for a waypoint entity connecting the source and destination. This option is enabled at the configuration level by specifying a single Relationship entity type.

   • Summary Entities: The name, ID, or entity type of any entity that appears in the path summary. A path summary can be enabled at the configuration level to show a sequence of several entities connecting the source and destination, such as groups, roles, or other resources.

   • Metadata: Review-specific information such as the decision, notes, and assigned reviewers.

4. Operator: For text strings, options are CONTAINS. EQUALS, NOT EQUALS, STARTS WITH, and ENDS WITH. When filtering on dates, you will instead pick a time range.

5. Parameter: Enter the text to match.

6. (Optional) Add Another to specify more matchers. Strings are grouped with an "OR" statement, for example, "Destination Region" EQUALS "East" OR EQUALS "WEST.

7. (Optional) Click another property on the Filters menu to refine your search with additional attributes.

8. Click Apply to filter the reviewer interfaces based on your selection.

Notes:

• The filter string can be empty, for example, User Department EQUALS (empty value).

• To treat a numeric value as a string (such as to match numbers in user names), enclose the numbers in quotes (Name, CONTAINS, "00000"). Otherwise, the number will be treated as an integer.

• You can include leading or trailing spaces in the search text by enclosing the filter string in quotes, for example, Resource Name = " Bucket "

Bulk actions

Possible actions are Approve, Reject, Reassign Reviewers, or Add Note. To sign off, click the button at the top right.

To apply an action to rows matching a filter:

1. Customize and apply a filter to show just the results you want to act on.
2. Choose the rows with the checkboxes on the left.

3. At the top of the screen, click on an action to apply.

Apply a bulk action to all rows across all pages

To act on all rows on all pages in the review, instead of just the current page:

1. Tick the multi-select box at the top left to select all rows on the page.

2. Click Select all rows above the table of results.
3. Choose an action to apply and confirm your decision.

Overview

Operators can choose to create access reviews in an unpublished, draft state. When a review is in a draft state, it offers an opportunity for the operator to inspect the included rows and adjust default reviewer assignments before commencing the review and notifying reviewers and other stakeholders.

Notes:

• Reviews must be explicitly published. When creating a new review, operators can create the review, which will save the review as a draft, or create and publish the review.

• Reviewers cannot view any unpublished reviews, even when they contain rows assigned to them.

• Operators can act on any results in unpublished reviews, including approving or rejecting, assigning reviewers, and signing off. Veza does not send webhooks for reviewer assignments when reviews are in draft state. All other webhooks (such as actions configured to trigger on rejected row sign-off) will trigger as normal.

• Publishing the review sends notification emails triggered "On review start."

Create a review as a draft

1. Create an access review: Create a Review.

2. When creating the review, click Create (instead of Create and Publish) to create the review in a draft state.

Draft review actions

Operators can make changes to draft reviews without notifying assignees. To prepare a review, you might:

• Use the Review Details sidebar on the left to configure review-specific email notifications and Veza Actions.

• Add row-level reviewers with the Reassign reviewers action.

• Approve or reject rows you can immediately decide on.

• Add notes for other reviewers.

• Sign off on one or more rows using the Sign-Off Selected button at the top right.

Publish a draft review

Review owners can publish drafts directly from the Access Reviews page:

1. Search for the draft review and click Publish.

To see active reviews and publish any drafts for a specific configuration:

1. Go to the Configurations page.

2. Use the search bar to find the configuration containing the review, and click to view Configuration Details.

3. In the Active Reviews section, find the draft review. Click Publish.

Overview

When creating a review, operators will specify one or more reviewers for all the rows. They can also automatically assign rows to the applicable user’s manager or resource owner when auto-assignment is available.

After creating a review as a draft, operators can assign reviewers for each row and validate auto-assignments. Once the review starts, reviewers can reassign their work to others as needed.

Reviews can involve many different reviewers, who might be assigned only some of the rows in a review:

• By default, the possible reviewers are Veza local users or external users who have logged in with single sign-on.

Assign reviewers during review creation

When creating a review, operators may optionally assign one or more default reviewers. These reviewers are designated to act on all rows in the review.

To add default reviewers:

1. On the Configurations page, find the configuration you will create a review for.

2. Click the review name to open the Details page.

3. Click New Review to open the review creation wizard.

4. Under Assign Reviewers, choose users from the list to assign them as reviewers for all rows.

Auto-assign reviewers

Auto-assignment will delegate decision-making to users Veza can identify as the manager of an identity under review, or the owner of a resource the identity can access. Veza supports auto-assignment both for all rows at review creation, and for selected rows when re-assigning reviewers.

• Managers are identified by a user's manager attribute from the global IdP.

• Resource owners are identified by Veza tag on the destination resource, added by API or from the Access Visibility > Graph actions sidebar.

• Fallback Reviewers are assigned when a manager or resource owner cannot be found. Fallback reviewers are also used when a rule, such as a potential reviewer being on the deny list, would prevent the assignment.

To auto-assign reviewers when creating a review:

1. On the Configurations page, find the configuration you will create a review for.

2. Click the review name to open the Details page.

3. Click New Review to open the review creation wizard.

4. Under Assign Reviewers, enable an option to Auto-Assign Reviewers:

Reassign row-level reviewers

Once a review is in progress, operators and assigned reviewers can re-assign rows to another reviewer. In the reviewer interface, the Reviewers column shows any non-default reviewers for each row.

To reassign reviewers for a row:

1. Expand the row actions dropdown menu (⠇) and click Reassign Reviewers.
2. Choose from the list of possible reviewers to reassign the row, or enable an auto-assignment method:

Reassign row-level reviewers with a bulk action

In the reviewer's interface, you can use a bulk action to reassign many rows at a time:

1. Tick the boxes to enable bulk actions on several rows.

2. Click Reassign Reviewers above the table of results.
3. Assign reviewers by type to search for a username or email, or auto-assign the user manager or resource owner.

4. Confirm your selection and click Save.

Early Access: Row grouping is currently provided as an optional feature. Please contact our support team to enable this capability for your Veza tenant.

Overview

Row grouping enables reviewers to organize and consolidate their review data into structured, collapsible sections. This makes it easier to focus on key insights, manage large sets of access data, and take quick actions based on user assignments, risk levels, or changes in access.

With this option, you can group your review results in multiple ways, including by:

• User: View all access associated with a specific user in one expandable section.

• Source: Group rows by the entity granting access (e.g., unique users, roles, or groups).

• Destination: Group access by its target (e.g., applications, roles, or resources).

• Risk Level: Organize access by risk level—Critical, High, Medium, Low, or None.

• Status: Separate changed vs. unchanged rows based on past review decisions.

For example, in this access review of Okta Users to Snowflake Databases, enabling the Group By > User option shows expandable groups of rows for each unique user in the results:

The “Group By” option provides a powerful way to consolidate assigned work into collapsible sections, organized by source ID, destination ID, or risk levels. Rows groupings can also be used to sort changed and unchanged rows, if there is historic decision data for the review.

Using the Group By option

To enable row grouping for an access review:

1. Click on an active review to open the results in the reviewer’s interface.

2. Click + Group By above the table to choose an option:

   • Source: Group by source entity ID (this could be each unique user, role, or group under review)

   • Destination: Group by the destination entity ID (e.g., individual roles, apps, or resources users are assigned to or have permissions on)

   • Risk Level: Group results by risk level (Critical, High, Medium, Low, or None).

   • Status: Group rows that are changed or unchanged since the last review using the same configuration.

3. Expand or collapse each group of rows to focus on different components of the access review.

4. Use group options to apply bulk decisions quickly:

   • Approve or reject rows multiple rows at once.

   • Apply actions, such as signing off, adding notes, or reassigning reviews.

This feature is designed to streamline your review workflow, reducing manual effort and ensuring faster, more effective decision-making.

Overview

Reviews you create can be organization-wide, or constrained to specific applications or populations of users. Use the query builder to scope reviews to meet the needs of your organization based on what data sources you have integrated, the specific compliance requirements of your organization, and existing review processes. For instance, a review configuration might specify:

• All users with specific permissions on all databases of a certain type.

• Users with any access to an individual application.

• Access for a subset of users, based on an attribute, such as "department."

The results of the query are used to compile the list of items included in an individual access or entitlements review. Depending on the objective of the review, these items can be further enriched with:

• System and Effective Permissions for a relationship, such as the permissions that a user has when accessing a particular resource

• A summary of the path that made the access connection - useful to show that an intermediary group or role is granting a user access

• Additional metadata about the source or destination entities to provide more context to reviewers.

Queries are especially powerful when entities in your access graph have attributes or tags defining ownership, applicability to compliance rules or regulations, regional metadata, and other organizational attributes. Additional metadata can include Veza tags, native tags originating from the data source (i.e. AWS tags), and Open Authorization API custom properties, as well as details about a related identity from your Identity provider or HRIS system.

This document provides an overview of all configuration options and guidance on using entity type groupings to review access for many entity types using a single configuration.

This document provides an overview of all configuration options and guidance on using entity type groupings to review access for many entity types using a single configuration.

Reference: Configuration Query Builder

The following table describes the options when defining an access review's scope with the configuration query builder.

Note that these options can differ from those available in the Access Visibility query builder, and include parameters specifically designed for access reviews. The entity types available as query source or destination depend on your configured integrations.

Entity Type Groupings

Use entity type groupings in a configuration to include several entity types in the scope of an access review. Choosing an entity type grouping as the source or destination will include all entities within that grouping. Use these to construct queries such as "All Principals to all Custom Application Role," or "All Top Level Principals to GitHub Repositories."

Generic entity type groupings

• All Principals: Entities with the Identity label, including machine entity types that can have permissions on resources.

• All Top Level Principals: Identity-type entities that cannot be assumed by another identity. Use this option to show primary organizational identities (e.g., IdP users), and filter out any low-level identities (such as local users) they can assume. Reviews will contain local users and service accounts that don’t have an upper-level identity.

• All Local Users: Entities with the LocalUser label (e.g., Google Cloud SQL User, Hashicorp Vault Alias, or MongoDB Users)

• All Resources: All entities with the Resource label.

• AccessCreds: Entities with the AccessCreds label.

Entity type groupings for custom applications

Some special entity type groupings are provided specifically for Access Reviews. These return all "custom" users, roles, resources, and other entities added to Veza using Open Authorization API templates. These groupings enable scoping reviews to for all users or resources in custom applications, identity providers, and HRIS platforms:

• Custom Applications

• Custom Subresources

• Custom Resources

• Custom Users

• Custom Roles

• Custom Role Assignments

• Custom IdP Domains

• Custom IdP Groups

• Custom IdP Users

• Custom Groups

• Custom Permissions

Custom entities and their attributes are defined in the JSON push payload created by OAA connectors. For more information about these entity types and attributes, see OAA Templates.

Overview

Columns in the review interface can be customized to rearrange, show, or hide certain attributes. Configuring default columns can improve overall readability, and offer reviewers valuable context for each row. Note that changes to columns made in the Veza UI will be saved to the browser. If a user has already customized a certification's columns, changes to the default settings will not apply.

You can also change the default order in which rows appear. For example, you might want to show results in descending order by destination resource type. This can be useful to encourage reviewers to focus on particular rows earlier in the review.

A set of global default columns and sort method applies to all reviews. You can also configure custom column orders for all reviews created for a specific configuration.

Example request

Column customizations require a private API call. By default, the customization applies to all reviews. Optionally, it will apply to all reviews created for a given workflow_id (corresponding to a review configuration in Veza).

The following example sets per-workflow default columns, including source tags, custom properties, summary entities, and reviewers:

{
  "value": {
    "default_ordered_columns": [
      "source.name",
      "source.department",
      "source.customprop_worker_status",
      "source.tags",
      "path_summary.name",
      "concrete_permissions",
      "destination.name",
      "destination.customprop_display_name",
      "reviewers"
    ]
  },
  "workflow_id": "002063d2-7898-4183-b5fb-1192758fdec7"
}

Sort order

The default sort value is source.type asc for ascending order. You can default to descending order or sorting on another column by including an order_by value, for example:

{
  "value": {
    "default_ordered_columns": [...],
    "order_by": "source.name desc"
  }
}

Column syntax

Columns for entity attributes have the format:

• source.attribute_name: Source entity attributes.

• destination.attribute_name: Destination entity attributes.

• waypoint.attribute_name: Attributes on the Relationship entity, if specified in the configuration.

• path_summary.name: Shows Summary Entities from the configured scope.

• idp.attribute_name: Attributes on the related IdP or HRIS user for a row, when the Enrich option is enabled for the configuration.

Columns can also show row metadata:

• status

• abstract_permissions

• concrete_permissions

• updated_at

• notes

• reviewers

• decision

• decision_by

• decision_by_id

• decision_by_name

• decision_by_email

• decision_at

• marked_fixed_by_id

• marked_fixed_by_name

• marked_fixed_by_email

• marked_fixed_at

• signed_off_state

• signed_off_by_id

• signed_off_by_name

• signed_off_by_email

• signed_off_at

• notification_status

• automation_run_ids

• no_decision_or_decision_by

• is_signed_off

For organizations with many users and access reviewers, enabling a global Identity Provider (IdP) eliminates the need to manually specify additional reviewers by email, or create additional Veza user accounts for reviewers. When enabled:

• Administrators and Operators can create reviews and assign reviews for any IdP user in a domain.

• Any IdP user able to log in to Veza with single sign-on (SSO) can authenticate without the need to provision an account beforehand. See Sign-In Settings to enable SSO.

• Managers and Resource Owners can be auto-assigned as reviewers.

• Alternate Manager Lookup can be used to assign reviews when you have multiple sources of employee records (e.g., contractors in one system, managers in another).

Typically, Veza support will make the API calls required to customize global IdP settings. See the following sections for prerequisites and the request format.

Before you start

• The authorization graph must contain entities for an integrated provider data source. See the integration guides for:

  • Okta

  • Microsoft Azure

  • Custom Identity Provider

• Use Query Builder to search for a user from your identity provider, and retrieve the provider’s datasource_id.

• Single Sign-On should be enabled to allow external users to log in to Veza.

• Veza support will supply an auth_provider_id for the Veza SSO connection.

Update global identity provider settings request

PUT workflows/access/global_settings/idp_settings

Enable Veza to suggest reviewers from the graph, by specifying the SSO auth provider id and the identity provider data source instance id:

    "value": {
        "enabled": true,
        "idp": {
            "auth_provider_id": "cf9bab40-4e48-4afc-a310-acfdad416233",
            "user_type": "OktaUser",
            "instance_id": "dev-5150036.okta.com",
            "user_identity_property": "idp_unique_id",
            "instance_id_property": "datasource_id",
            "manager_identity_property": "manager_idp_unique_id"
        }
    }

Notes:

• auth_provider_id identifies users with entries in the local user database and will also map correlated graph entities.

• There can be several instances of an identity provider for a given user_type.

• instance_id ensures the user info is pulled from the correct instance and domain.

• Veza will populate the user list by searching for nodes of type user_type with instance_id_property equal to instance_id.

• Setting "instance_id_property": "datasource_id" will typically achieve the correct behavior.

Examples

Okta:

{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "x",
      "user_type": "OktaUser",
      "instance_id": "dev-5150036.okta.com",
      "user_identity_property": "idp_unique_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_idp_unique_id"
    }
  }
}

Microsoft Azure AD:

{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "x",
      "user_type": "AzureADUser",
      "instance_id": "d5d23474-d857-4e12-bf68-75d638867e93",
      "user_identity_property": "idp_unique_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_idp_unique_id"
    }
  }
}

Custom Identity Provider:

{
  "value": {
    "enabled": true,
    "idp": {
      "auth_provider_id": "cf9bab40-4e48-4afc-a310-acfdad416233",
      "user_type": "CustomIDPUser",
      "instance_id": "aa650cf7-2370-406e-bb35-1a8e14b92919",
      "user_identity_property": "idp_unique_id",
      "instance_id_property": "datasource_id",
      "manager_identity_property": "manager_idp_unique_id"
    }
  }
}

Validating global identity provider settings

You can confirm changes are working as intended by starting a review and selecting reviewers:

• If the user_type, instance_id, and instance_id_property are correct, identities from the graph will appear in the suggestions.

• If auth_provider_id is correct, SSO users should only appear once in the scenario above. The local user entry is filtered from the list. Only the user record from the graph entity will appear.

Access Reviews settings can be customized to fit the needs of individual organizations and use cases, such as enabling auto-expiration, setting whether all rows need a decision before review completion, or requiring a note with certain decisions. You can also manage how Veza integrates with a corporate identity provider (IdP) to enable single sign-on and least-privilege review flows. See the following sections for more information:

Some of these options must be enabled by the Veza support team, while others can be configured using an API. See Global Settings APIs for detailed API documentation.

Suggest reviewers from a global identity provider

By configuring a global identity provider, you can select reviewers from all users in your organization that Veza has discovered within an integrated IdP, including users who have never logged in to Veza. This eliminates the need to create user accounts for reviewers before they can be assigned to rows.

For example, if your organization's Okta domain is integrated with Veza and single sign-on (SSO) is enabled for your Veza tenant, all the domain's Okta Users will be suggested as possible reviewers. Those employees can then log in to Veza with SSO to complete their assigned reviews.

• To enable a global Access Reviews Identity Provider, see Configuring a Global Identity Provider. Enabling a global identity provider also enables reviewer auto assignment to Managers and Resource Owners.

• If notifications are enabled for a configuration or review, any new reviewers are notified by email, with a link to log in and make decisions on their assigned rows.

Reviewer auto-assignment

You can choose to auto-assign managers and resource owners when creating a review or re-assigning reviewers. Any rows in the review that cannot be auto-assigned are assigned to fallback reviewer(s).

To enable Veza to automatically identify managers and resource owners, see Managers and Resource Owners:

• Within your IdP, set the corresponding manager property on the user object

• Within Veza, add a Veza Tag that identifies a resource owner.

When an integrated Identity Provider (IdP) is configured as the global identity provider, these managers and resource owners can sign in to Veza without first needing to create an account.

Self-review prevention

You may want to prevent reviewers from being able to review and sign off on their own access in a review. When self-reivew prevention is enabled and a Global IdP is configured, users cannot be assigned to review rows for identities that match their global unique ID:

• SELF_REVIEWER_CHECKING_DISABLED (default)

• SELF_REVIEWER_CHECKING_ENABLED

Self-review prevention with auto-assignment

When auto-assigning reviewers, operators can specify a list of fallback reviewers. These users are assigned when self-review rules or the deny list would prevent the original assignment. They are also used when a manager or owner can’t be found.

If a fallback reviewer is prevented from reviewing their own access or is on the deny list, the other fallback reviewers are assigned to the row.

If there are no fallback reviewers and a rule prevents an assignment, Veza will select a reviewer in the following order:

1. The blocked user’s manager or resource owner (if not explicitly inactive)

2. The configuration creator

3. A Veza system administrator.

See Reviewer Selection Methods to customize this behavior.

Review completion settings

Depending on how your organization conducts access reviews, you may prefer that users be able to complete reviews at any point, or want reviews to autocomplete when certain requirements are met.

Autocompletion

By default, a review must be manually marked "complete" once a reviewer has signed off on all decisions. This setting can be changed so that reviews move are considered complete once a reviewer signs off on the final row. You can also customize autocomplete behavior to allow or prevent autocompletion of reviews that contain "Rejected" decisions.

Example request:

{"value":"COMPLETION_ALLOWED_ALL_ROWS_HAVE_NON_REJECT_DECISION"}

Possible values are

• COMPLETION_ALLOWED_ALL_ROWS_HAVE_DECISION (default): Once all rows have a decision, the review will be automatically marked as complete and no further changes can be made.

• COMPLETION_ALLOWED_ANYTIME Any reviewer can click Complete to finish and close the review at any point.

• COMPLETION_ALLOWED_ALL_ROWS_HAVE_NON_REJECT_DECISION autocompletion occurs only when all rows were signed off as approved or were rejected but marked as “fixed.”

Auto Complete Settings determine whether reviews automatically move to "completed" status once the deadline is passed. Possible values are:

• AUTO_COMPLETE_DISABLED (default)

• AUTO_COMPLETE_ENABLED

Example request:

{"value":"AUTO_COMPLETE_ENABLED"}'}

Enable or disable review expiration

Requiring notes with decisions

By default, adding a note is optional when making decisions on rows. However, you may prefer that reviewers be required to leave a note under certain conditions. For example, you could require a note for rejected rows, while prompting (but not requiring) a note for approved rows.

Notes pop-up behavior sets whether the "Notes" modal appears and if a note is required when making decisions on rows. "Approve" and "Reject" behavior can be customized separately:

• Approved notes behavior:

  • No pop-up (default)

  • Optional

  • Required

• Rejected notes behavior:

  • No pop-up (default)

  • Optional

  • Required

Example request:

{
  "value": {
    "accept_notes_behavior": "POP_UP_OPTIONAL",
    "reject_notes_behavior": "POP_UP_REQUIRED"
  }
}

When "No pop up" is selected, no prompt is shown, and notes must be added by clicking Add Note. Otherwise, a note will be required or optional depending on the decision.

Change default columns and sorting

An administrator can customize row sort order and the default columns shown in reviewer interface. Columns can be customized globally and per configuration. New reviews will use the default columns for the parent configuration.

See Customizing Default Columns for more information about the possible columns and API documentation.

The following example sets global default columns based on the source, destination node, and intermediate (waypoint) node properties, and shows each row's reviewers:

{
  "value": {
    "default_ordered_columns": [
      "source.customprop_worker_status",
      "source.name",
      "concrete_perms",
      "destination.name",
      "reviewers",
      "destination.customprop_asset_id",
      "destination.customprop_bu",
      "destination.customprop_display_name",
      "waypoint.name"
    ]
  }
}

Example sort setting:

{"value":{"order_by":"source.name desc"}}'

Customize reminder and notification emails

Emails sent by Veza can include instructions, unique branding, and placeholders for metadata specific to the review. See Notification Templates to customize notification emails sent to reviewers and other stakeholders.

• A template can be set for each potential usage (review created, row assigned, due date reminders, and others).

• Placeholders can be used to include direct links to the review, dates, and reviewer metadata such as Name, depending on the selected usage.

• Custom HTML/CSS can be included in a base64-encoded body template.

• Templates can include links to images hosted externally or you can upload small files to Veza.

• In addition to emails, administrators can add customized instructions that will be shown in a splash page when opening the reviewer interface. See Help Page Templates for more information.

See Notification Templates API for preview API usage details.

Review interface presentation rules

To enable easier identification of potentially dangerous results, Veza supports custom styling rules to highlight disabled (inactive) users. In addition to these rows appearing in red during review, the text summary shown when hovering the row will indicate that the user is inactive.

Please contact your Veza customer success team to enable this option. To highlight results based on a custom presentation rule, provide:

• The filter string to use (for example source.is_active eq false). The property to match can be on the source or destination entity types in the configured query.

• (Optional) a list of review ids the presentation rule will apply to (affecting all reviews on that configuration). Otherwise, rules apply to all reviews.

Saved filters

Administrators can add preset filters for users to choose from. Quick filters can be accessed under the Filters menu in the reviewer interface. When creating a saved filter, you can enable it for all reviews or just one.

See Quick Filters for more information about adding pre-built filters.

Overview

Alternate manager lookups provide enhanced review auto-assignment by allowing Veza to identify managers from multiple sources of identity metadata. This is particularly useful if your organization has complex identity structures with more than one identity provider (IdP).

You may need to configure an alternate identity provider for manager assignments to enable:

• Automatic manager assignment for contractors tracked in a separate IdP (e.g., a custom OAA IdP) with managers from a primary IdP (e.g., Okta).

• Auto-assigning access reviews involving users in the main IdP (e.g., Okta Users), when manager information is maintained in another system (e.g., Oracle HCM).

By supporting cross-source manager lookups, Veza ensures consistent and accurate access review assignments, regardless of where user or manager identities are maintained.

Example Implementation

Alternate lookups are intended for situations where you have a primary identity provider and additional sources of identity in another system. For example, you might import identity data for contractors via a custom CSV, and want to have their access reviewed by managers who are Okta users. In this case, you want to ensure that:

• Contractor access reviews are assigned to their actual managers (who are Okta users).

• Even if the contractor identity lacks a direct manager attribute in the custom IdP, Veza can still identify the correct manager from Okta.

With an alternate manager lookup, you can configure Okta as a primary IdP, and a the imported CSV provider as the secondary IdP. When a contractor's access is reviewed, the system will first check if they have a linked user in Okta. If no linked user or manager is found, it uses the alternate lookup settings to find the appropriate manager in Okta.

How It Works

When creating an Access Review, administrators can choose to auto-assign rows to individual managers. Veza will identify managers using one or more identity providers.

For auto-assignment to function:

• Users in the review must be linked to an identity, either in the main IdP, or one of the alternate lookups. This connection is made based on the attribute mapping in your Global IdP settings.

• The connected identities must have an attribute that contains one or more identifiers used to look up each user's manager(s). The attribute could be managers or any other attribute configured in your settings (manager_identity_property). The value in this attribute must match the value of the main IdP's user_identity_property.

Veza supports looking up managers from both primary and alternate identity providers:

2. Alternate Manager Lookup Settings: When the primary lookup fails, the system can use one or more alternate IdP settings to find managers.

The lookup settings configuration includes:

• User Type: The type of user in the alternate IdP User, e.g., OAA.Oracle HCM.HRISEmployee

• User Identity Property: The property used to identify users across systems, e.g., customprop_manager_employee_number

• Manager Identity Property: The property containing the manager reference, e.g., customprop_manager_employee_number

• Instance Id Property: The property containing the instance ID, e.g., datasource_id

• Instance Id: The ID of the alternate IdP instance, e.g., 05bbc13d-bf25-45f2-ba09-03e5625a3b66

Order matters when configuring more than one alternate source of identity. Veza will check the primary IdP first, then the first alternate lookup, then the second, and so on, until a manager is found or all options are exhausted.

Notes:

• For reviews initiated using the main IdP (e.g., Okta), the system will look up managers from alternate sources (e.g., Oracle HCM).

• The system will also try alternate lookup methods if the primary lookup fails.

• The manager identity property can contain a single value or a list of values.

Manager Lookup Process Flow

API Configuration

Currently, identity providers for review auto-assignment are managed using a private/ API request. Your Veza support representative can help configure this global setting.

• PUT /api/private/workflows/access/global_settings/idp_settings

• GET /api/private/workflows/access/global_settings/idp_settings

The global IdP settings request takes an idp settings object for the primary IdP configuration, and one or more secondary IdPs defined in alternate_manager_lookup_settings

For example:

{
    "value": {
        "enabled": true,
        "idp": {
            "auth_provider_id": "87549440-ef3d-4f8c-a3d8-ed1569a79ed6",
            "user_type": "OktaUser",
            "instance_id": "instance.okta.com",
            "user_identity_property": "employee_id",
            "instance_id_property": "datasource_id",
            "manager_identity_property": "x_manager_id"
        },
        "alternate_manager_lookup_settings": [
            {
                "user_type": "OAA.Oracle HCM.HRISEmployee",
                "instance_id": "05bbc13d-bf25-45f2-ba09-03e5625a3b66",
                "user_identity_property": "employee_number",
                "instance_id_property": "datasource_id",
                "manager_identity_property": "managers"
            },
            {
                "user_type": "OAA.Contractors.IDPUser",
                "instance_id": "9fb32fc1-4db2-4ac6-9ab1-b5c24836ddd4",
                "user_identity_property": "idp_unique_id",
                "instance_id_property": "datasource_id",
                "manager_identity_property": "customprop_manager_employee_number"
            }
        ]
    }
}

Overview

Email notifications inform reviewers and other stakeholders of important events, such as when a review starts, re-assignments occur, and deadlines pass. Veza includes three types of email notifications, which an administrator can customize with templates.

• Notifications: Event-based, sent when a review starts or finishes, or on row reassignment.

• Reminders: Time-based, sent around the deadline or period of activity when there is remaining work.

• Final Reminders: Similar to reminders, highlighting missed deadlines or extended periods of inactivity.

Operators assign default notification settings when creating a configuration. Reviews created for the configuration will inherit these settings. Operators can later customize notification settings for specific reviews.

For multi-user access reviews, you will typically want to fine-tune reminders to meet your requirements, for example:

• Reviewers and review owners, informing them when rows are re-assigned.

• Reviewers and their managers, if users are inactive when further action is required.

• External stakeholders, on review completion or after a deadline passes.

This document describes notification options for Veza Access Reviews, and how to edit notifications for a configuration or a review.

Configuring notifications & reminders

You can add reminders when creating a configuration by enabling them in the Notifications section of the configuration builder. To enable notifications, specify the recipients and the conditions that will result in an email.

Recipients can be:

• Reviewers: Users assigned to rows in the review, including default reviewers and any reassigned reviewers.

• Reviewer Managers: Users identified by Veza as the manager of an assigned reviewer, possible after enabling a global identity provider for Veza Access Reviews.

• Additional Recipients: Any other stakeholders, provided as a comma-separated list of emails. You can use this option to inform external users about completion status, deadlines, and delays.

Notifications can trigger:

• On review start: Upon review creation or after publishing a draft review. Use this option to inform reviewers who are auto-assigned on review creation.

• On row reassignment: After a reviewer is assigned to a row by a user operation (API or GUI-initiated). It does not include reviewers assigned at review creation.

• On review completion: When the review is marked "Complete".

Reminders can trigger:

• Every (number of days) if no changes by reviewers in (number of days): Periodic reminders when reviewers have not acted on their assigned rows.

• On (number of days) before review due date: Sent based on an upcoming due date.

• On due date: Sent when the review is due.

• (Number of days) after due date: Sent when the review deadline has passed.

Final Reminders have the same triggers and use the same template as “Action Needed” reminders. Use them to add escalated reminders, emphasizing missed deadlines or extended periods of inactivity. For example, a reminder might notify the reviewer after a few days of no activity, and a final reminder might notify both the reviewer and their manager if there have been no changes in a week.

Edit notifications and reminders for a configuration

Saving changes to email notifications at the configuration level causes both active reviews and new reviews for that configuration to use the updated settings.

To change the default email notifications for an existing configuration:

1. Go to Access Reviews > Configurations.

2. Click the configuration name to view details.

3. On the Configuration Details page, click Edit.

4. Scroll down to the Advanced Notifications section.

5. Configure notification settings using the checkboxes to enable recipients and triggers:

   • Review Notifications:

     • Under When, select events that trigger notifications (Review has been started, Review has been completed, Review row has been reassigned)

     • Under Notify, select recipients (Reviewers, Managers, Additional Recipients)

   • Reviewer Notifications:

     • Under When, select timing conditions (Review is due, days before a review is due, days after a review is due, or reminders when no changes have been made)

     • Under Notify, select recipients (Reviewers, Managers, Additional Recipients)

6. Save your changes.

Edit notifications and reminders for a review

Operators and administrators can customize notifications for individual reviews. These settings appear in the reviewer's interface on the review details sidebar.

To edit email notifications for an in-progress review:

1. Go to Access Reviews > Reviews, or open the review from the Configuration Details page.

2. Click on the review's name to open the reviewer's interface.

3. On the Review Details sidebar, find Notifications and Reminders and click Open.
4. Use the Edit Configuration Notifications & Reminders form to add recipients and triggers.

5. Click Save when finished.

See also

Overview

While some reviews may be one-time procedures, you will typically want to conduct reviews on a schedule to proactively mitigate security risks and ensure that access is evaluated consistently over time.

In Veza, you can create a schedule for any saved review configuration. The cadence for new reviews can be biweekly, monthly, every other month, or every quarter, depending on your operational practices and compliance requirements.

Before you start

You will need:

• The administrator or operator role for viewing and managing review configurations.

Scheduling access reviews

To schedule reviews for a configuration:

1. Choose a configuration on the Configurations page. Click ⠇to expand the actions menu and choose Create Schedule.
2. Configure the schedule:

   1.1 Add a Name and Description for the created reviews.

   1.2 Assign one or more Default Reviewers for the review. These users can act on any row and reassign them to other users. By default, Veza will suggest default reviewers based on prior reviews for the configuration.

   1.3. Pick a Frequency to create reviews.

   Options are Weekly, Biweekly, Monthly, Every other Month, and Quarterly.

   Check the Next Run On date below the form to preview when the review will run based on the current frequency and start date.

   1.3. Pick a Start Date for the schedule.

   1.4. Pick a Time to run review and the Time Zonewhen the review will be run.

   1.5 Set the Review Duration. This is the number of days until the review expires at the specified time.

   1.6. (Optional) Under Use Review Intelligence Policies, enable automation to apply decisions based on a filter or prior decisions.

   1.7. Set Review Time Frame.

   Each new Review runs the workflow query parameters against the most recent graph data, the latest graph snapshot, or can run against a historical snapshot.

   Click View Datasource Statuses to inspect the current status of all Veza integrations involved in the query. Review the last sync time, status, and errors in the modal.

3. Click Save to create the schedule.

To edit a schedule later, find the configuration on the Configurations page and click Edit Schedule.

Overview

The reviewer's interface implements strict role-based access controls:

• Review creators and administrators have full visibility into all rows and review metadata. This includes all reviewer assignments and overall progress.

• Access Reviewers only have visibility into rows assigned to them and cannot see the full review metadata. They can see their individual progress, including the number of items they have acted on or completed and their total assigned rows.

Reviewers use this page to:

• Approve or reject their assigned rows.

• Assign other reviewers for a row.

• Sign-off on their decisions.

Operators and administrators can use the reviewer's interface to:

• Annotate rows and mark rejected rows as "Fixed."

• View and edit review details, notifications, and Veza Actions.

• Review overall progress, action logs, and automation status.

• Mark the review "Complete" after all rows have decisions.

• Export the view to share findings or import rows into another system.

The sections below describe actions and features after opening a review as an operator or access reviewer:

Accessing the reviewer interface

Opening the reviewer interface

You can access the reviewer interface from the Access Reviews overview. Click a review name on the Active Reviews tab to open it.

To open the results of an active review for a single configuration:

1. Find the configuration on the Access Reviews > Configurations list.

2. Click a configuration name to open the details page.

3. Find a review on the list of Active Reviews and click Open to open it.

Mobile view

In addition to a full-featured UI for desktop use, Veza provides a mobile experience for reviewers on tablets and other devices with smaller screen sizes. Users can approve, reject, and sign off on results with a simplified "swipe" layout. The card representing a row is similar to the details view for desktop users, showing the attributes and permissions for each entity under review.

In swipe mode, reviewers can:

• Swipe left to reject access.

• Swipe right to approve access.

• Use the options menu (...) to view details or reassign reviewers.

• Add filters and apply bulk actions to update many cards at a time.

The mobile interface is only available for users with the Access Reviewer role. Administrators and operators can use the full reviewer interface when browsing reviews on mobile devices.

The behavior of swipe actions in mobile view can be configured by the Veza support team. Depending on your settings, left and right swipes can map to: APPROVE, APPROVE_AND_SIGN_OFF, REJECT, or REJECT_AND_SIGN_OFF.

Reviewing and managing rows

Row actions

Apply actions to individual results using the dropdown menu (⠇) to the right of each row. The available actions vary depending on your role and the row's state.

• Approve

• Reject

• Re-assign reviewer

• Sign off

• Add Note

• Clear Decision

• Mark as Fixed

• Open in Authorization Graph

Note that decisions can be reverted until they are signed off.

Row action logs

See all historical activity for a row by opening the action log:

1. Expand the row actions menu.

2. Click View Action Log.

3. Review the events by type, description, user, and timestamp.

Row fixed status

Administrators can denote rejected rows as fixed following remediation.

"Fixed" is a unique state that denotes an access rejection is successfully remediated. Depending on your system settings, you can require that access reviews cannot be marked complete until all rows are either "Approved" or "Fixed."

To update the fixed status of a row:

1. Expand the actions menu for a Rejected row.

2. Click Mark as Fixed.

Annotating rows

Use the Add Note action to document a decision, suggest a resolution, or leave a comment on any row. Notes are visible to the review owner and other reviewers assigned to the row.

To add a note to a row, use a bulk action or the row actions dropdown.

• Adding a note replaces the current one.

• Only the most recent note appears in the "Notes" column.

• Earlier entries are available under Actions > View Action Log.

Tags in the reviewer interface

To show tags in the reviewer interface, source and/or destination tags must be included in review configuration (Advanced Options).

When enabled, all tags are shown in an additional column. Click a tag key to show the tag values.

Show access for a single user

Early Access: The option to filter by a user is currently provided as an optional feature and must be enabled by the Veza support team.

When reviewing access for a few different identities, it can be helpful to focus on rows related to a single user in the results. You can use the Show Users button to list each unique user involved in a review and open a filtered list of all the results related to an individual user.

To filter the reviewer interface on rows related to a single identity:

1. Click the Show Users button above the results. The button only appears when the query's source node is a principal.

2. The list of Unique Users will open, containing the full list of unique source entities in the query results.

3. Choose an identity from the list. You can search by username, id, or email address to find a specific user.

4. Click View Details to open the results related to that user in a new tab.

Note that in the current release, for users with the access reviewer role, the Show Users button lists all unique users in the review, which can include users from rows that are not assigned to the current reviewer.

Exporting review rows

Owners and administrators can export rows directly from the reviewer interface. CSV exports include all entity attributes and row metadata, suitable for importing into another tool. PDF exports include a title page and additional pages for metadata about the overall review status.

To download row metadata in CSV format:

1. From the reviewer interface, click Export > Export to CSV.

2. Enter a name for the downloaded file.

3. Choose specific columns to export, or export all columns by default.

4. Add transformations to convert Column Names > Export Names.

5. Click Export.

To export rows in PDF format:

1. From the reviewer interface, click Export > Export to PDF.

2. Enter a name for the downloaded file.

3. Enter a title for the document cover page.

4. Pick columns to include (up to 12).

5. Reorder and transform column names for readability.

6. Click Export.

Customizing the reviewer interface

By default, the reviewer's interface shows each row's source (usually a user or other principal) name and type, effective permissions (if available), and the name and type of destination entity (usually a resource). Reviewers can resize, rearrange, and show or hide columns to focus on critical details. Any changes are saved to the browser.

Show enriched columns in the review interface

Access reviews involving local user accounts that are associated with external IDP users can optionally support an IDP User column group. This group contains attributes specific to external users associated with the source user.

Reviewers and Operators can use the column selector to display these additional IDP User fields, such as risk score, title, department or activity status. These columns will be empty for local users without an ßassociated IDP user:

Completing a review

After all results are signed-off, operators can click Complete to finish the review, preventing further changes:

1. Open the reviewer interface.

2. Click Complete at the top right to finish the review.

Early Access: Enrichment is currently provided on an opt-in basis. Please contact Veza Support to enable this feature. Enrichment requires an IDP or HRIS integration such as Okta, Active Directory, Azure AD, Workday, or a Custom Identity Provider.

Overview

You can configure access reviews to show additional human resource or identity metadata for users under review. When enabled, Veza will check for matching entities in an integrated Identity Provider or HRIS platform when creating the review. The linked user attributes are shown in columns, which reviewers can show, hide, or filter by for faster and more accurate decision-making.

For example, when reviewing local Snowflake user access to Snowflake databases, enabling this option will show the attributes of the linked Okta user for each local user, such as their risk score, first and last name, and whether MFA is enabled. Local users with no linked Okta users could be machine identities, or represent risky misconfigurations.

Similarly, an access review of Okta users to Okta applications can use this option to show information about the Workday Worker associated with each user, such as the cost center, hire date, or active status.

Enabling IDP/HRIS Metadata Enrichment

To enable IDP User columns in the reviewer interface, enable enrichment in the configuration scope:

1. Create or edit a configuration.

2. In the review scope, enable Advanced Options > Enrich with IdP/HRIS data.

3. Select from the list of supported entity types to enable result enrichment (such as "Workday Worker" for "Okta User"):
4. Save the configuration and create a review.

5. In the reviewer interface, use the column selector to enable columns for the "IDP User."

Filters on IDP/HRIS Enrichment

In the configuration builder, choosing an entity type under the Enrich with IdP/HRIS data option enables filters on that entity type. For example, you might choose 'Okta User' as the source entity type under review and enable 'Workday Worker' as the enrichment entity type. You can then apply filters on both Okta User and Workday Worker attributes.

It is important to understand how these filters affect the review results. If an enrichment attribute does not meet the filter criteria, the enrichment data for that row is hidden, but the original access relationship remains visible. This behavior ensures that you can still see all source and destination entities, and identify rows where the enrichment data does not match the filter.

• Filters on enrichment data do not remove source or destination entities from the review. You will still see all access relationships.

• If the enrichment data does not meet the filter criteria, only the enrichment columns are affected.

• This behavior helps identify users who may not have corresponding enrichment data, potentially presenting misconfigurations.

Example:

Suppose you have a review of Local Users to Local Groups, enriched with Okta User data:

Now, you apply a filter on the Okta User column to exclude users whose names start with "A" (e.g., Okta User does not start with "A"). The updated review results will be:

In this filtered view:

• Bob's enrichment data continues to appear because it meets the filter criteria.

• Alice's enrichment data is blank because it does not meet the filter criteria (Alice starts with "A").

• The access relationship between Alice and Group2 remains visible.

Controlled Access: This feature is currently only enabled for customer tenants on a controlled basis.

Veza Access Reviews optionally supports a two-tier review and approval process, where two different parties sequentially review and approve a Review.

When second-level reviewers are enabled for a new review, two levels of review and sign-off are needed before rows in the review are marked "completed.". Each review level is assigned to different reviewers. Both levels of a review support reviewer auto-assignment, though options vary depending on the review level.

Note that each review level can have multiple reviewers assigned per row — just like a typical single-level review.

Key concepts for multi-level reviews include:

• First-Level Review: The initial review phase where primary reviewers make decisions.

• Second-Level Review: The final review phase where secondary approvers act after all rows have first-level decisions.

• Sequential Approval: The first-level review must be completed before moving to the second level.

• Unanimous Approval, Single Rejection: Both levels must approve for acceptance. A rejection at either level is final.

Multi-Level Review Process

Multi-level reviews allow organizations to optionally configure reviews that require multiple parties to review rows of access and sign off sequentially to complete the review. For instance, the first level of review may be performed by a user's manager while the subsequent second level of review is completed by the application owner. When enabled, reviewers at each level must approve the row before a decision is finalized.

1. First-Level Review

   • Starts upon creation of a multi-level review.

   • First-level reviewers can see and act on all assigned rows.

   • All rows must be signed off before the review progresses to the second level.

2. Second-Level Review

   • Begins after first-level reviews are complete.

   • By default, second-level reviewers only see rows approved by first-level reviewers. They may approve or reject previously approved rows but cannot change decisions on rows that were rejected at the first level.

Rejection at any level is final. Second-level reviewers do not sign off on access that a first-level reviewer rejected.

Notifications Behaviors for Reviewers in Multi-Level Reviews

The following rules apply with second-level review enabled:

• If configured, review start notifications are sent to first-level reviewers.

  • Second-level reviewers are notified when their review phase begins.

• If configured, reminders are sent only to reviewers at the current level.

• If configured, completion notifications are sent to all reviewers.

Veza Actions in Multi-Level Reviews

• Veza Actions configured for when rejected rows are signed off will trigger at the first level that the rejection decision is made and signed-off. This could be the first- or second-level of the review.

• Veza Actions for approved rows only trigger when a row is signed off in the second and final approval level.

Enabling and Assigning Second-Level Reviewers

You can assign second-level reviewers explicitly (by username or email) or through auto-assignment. In addition to auto-assigning the manager of a source user or the owner of a destination resource, second-level reviews can be assigned to the manager of each first-level reviewer using information from your identity provider.

To enable and assign second-level reviewers:

1. Go to Access Reviews > Configurations and click New Review to create an access review.

2. Define the scope, set a due date, and assign initial reviewers.

3. In the Second Level Reviewers section, click Enable.

4. Assign specific reviewers, or auto-assign the user's manager, the resource's owner, or the first-level reviewer's manager.

6. Click Create and Publish to start the review (notifying reviewers), or Create to save it as a draft.

Multi-Level Approval in the Reviewer Interface

Users with an Operator or Administrator role can view all rows at the current review level. Users with the Access Reviewer role can only view and update their assigned rows in their review level.

In the reviewer interface, an information bar above the rows shows whether the review is in the first or second approval level. A progress bar displays the status of rows (approved, rejected, or without decisions) at the current level.

FAQs

• What happens if a row is rejected at the first level? The row is considered rejected and is hidden by default during second-level review.

• Can a first-level reviewer view or change their decisions on a review after they have signed off on the review and it has proceeded to second-level review? No.

• Can second-level reviewers see first-level reviewers' comments? Yes, comments and annotations are visible to second-level reviewers, enabling communication between review levels.

Overview

When creating an access review, operators can choose to assign the review to managers and resource owners as reviewers based on graph metadata:

• Veza can automatically assign reviewers to rows involving entities they own or manage.

• Veza will suggest default reviewers if the review scope is a single named identity or resource with an assigned owner.

• For natively-supported identity providers, such as Okta, you can assign a manager by setting a user's Manager attribute from the provider's admin console.

• Any entity in the Veza graph can have a resource owner. Apply a tag with key SYSTEM_resource_managers. The tag's value is the comma-delineated list of user ID's, for example:

Assigning resource owners (Graph Search)

From the Veza UI, you can add a manager tag to any entity in Graph Search:

1. In Veza, go to Access Visibility > Graph.

2. Search for the entity.

3. Click the entity in the search results to open the sidebar.

4. Click Set Resource Owner.

5. In the Add Resource Owner box, type to search for users by email and Save the changes.

Assigning resource owners (Tags API)

Add tag:

Remove a tag by providing the entity id and the tag key to delete:

Validating manager assignments

To test resource owner assignment using tags:

1. Pick a resource on the graph that doesn't yet have an owner.

2. Apply a system_resource_managers tag with the email address of another Veza user.

3. Create an Access Reviews configuration. Select the entity type of the tagged resource, and Select a single entity and specify the resource name.

4. Save the configuration and create a review.

5. The resource owner's Veza account should be selected as the default reviewer.

To test manager assignments using Okta:

1. Pick an IdP entity (such as OktaUser) on the graph.

2. If the user already has a manager, create a corresponding Veza user for the manager's email address (you can give it the Access Reviewer role).

3. Otherwise, log in to Okta and set the user's Manager attribute to your Veza email address.

4. Create a configuration. Select the entity type (OktaUser) and choose to Select a single entity. Enter the Okta user name.

5. Save the configuration and start a review.

6. The manager's Veza account will be a suggested default reviewer.

Assigning owners for custom applications and identity providers

Assigning managers (Custom IdP)

Assigning owned entities (Custom IdP)

To assign an IdP user or group as the manager of any resource Veza has discovered (from another integration), list the node type and node ID in the entities_owned field, for example:

When Veza parses the payload, graph entities are assigned a system_resource_managers tag. The owner(s) will be suggested as reviewers for any reviews when the configuration scope is a single named resource with a matching tag.

Assigning resource owners (Custom Application)

When using the custom application template to submit application and resource metadata, assign resource owners by applying a Veza tag:

Early Access: Please contact the Veza support team to enable this feature.

Overview

1-step access reviews enable administrators to quickly create, delegate, and initiate access reviews, without first creating a reusable review configuration.

The 1-step review wizard provides a streamlined builder for defining the scope of the review based on:

• Pre-defined scopes for common scenarios and applications such as Okta, AWS, and Salesforce.

• A saved query, either built-in or constructed using the query builder.

Creating a 1-step review

When 1-step reviews are enabled, administrators and operators can choose from two options when creating a review on the Access Reviews > Reviews page:

• 1-Step: Create a review using the quick builder by giving it a name, defining the scope, and configuring optional settings such as reviewers and due date.

To create a review with the 1-step builder:

1. On the Access Reviews > Reviews page, click Create Review > 1-Step.
2. Enter the required details:

   • Review name: This will be used to identify the review in Veza and reviewer notifications. Names should be unique to simplify tracking and reporting.

   • Scope: Choose an option to define the entities and relationships to review:

     • Quick Builder:

       • Review Type: The type of entities and relationships to review: e.g., "Okta user AWS IAM group memberships"

       • Narrow Scope: Choose specific data sources Veza has discovered.
   • Due date: Specify the Date (UTC) and Timezone when the review must be completed.

   • • Assign Reviewers: Assign default reviewers for all rows in the review.

     • Auto-assign reviewers: Assign row-level reviewers based on Veza metadata like managers or resource owners.

     • Fallback reviewers: Used when an auto-assignment is prevented or can't be found.
3. Click Create and Publish to make the results available to reviewers, or click Create to save a draft and preview the results.

Notes:

• New reviews created using the 1-step builder have the "1-Step" review type.

• A review configuration is created in the background, which can be used to re-initiate reviews with that scope and provide historical decision data.

Early Access: On-Demand Reviews are currently provided as an Early Access feature. Please contact the Customer Success team to enable this functionality on your Veza platform.

Overview

Veza Access Reviews support on-demand reviews using Access Intelligence alert rules. By attaching review creation rules to saved queries, you can trigger the creation of new reviews in response to changes in your authorization environment. This type of access review might be initiated whenever new user accounts are detected within an application, new entitlements are granted, a user's risk level increases, or if MFA is removed or disabled for an account.

On-demand reviews support Review Intelligence rules, and are created with a duration and reviewer assignments based on the rule configuration.

Common scenarios for implementing on-demand reviews include:

• Automatically reviewing access for terminated employees

• Certifying access when users are added to new roles

• Validating permissions after attribute changes

• Reviewing orphaned or inactive accounts

Important concepts:

• Rules are conditions attached to saved queries that trigger automated actions when met.

• Review Creation Plans are rule settings that define how new reviews will be created.

• Rule Triggers are attribute-based or change-based criteria that initiate review creation (for example, when the query results have increased, or when an entity's is_active attribute changes).

• Creation Source: On the Access Reviews page, you can identify the source of a review by checking the Creation Source column. On-demand rules will have the source RULE_TRIGGERED.

Implementing On-Demand Reviews

Prerequisites

Before configuring on-demand reviews, you will need to:

1. Create at least one access review configuration defining the scope of reviews.

2. Build and save a query that identifies the entities requiring review, or use a built-in query.

Add a Rule for On-Demand Reviews

To add a review creation rule:

1. Navigate to the saved query

2. Select "Manage Rules" from the actions menu

3. Click "Add New Rule"

4. Configure the rule details:

   • Name and description

   • Severity level

   • Trigger conditions

5. Click Action -> Create Review to open the review creation plan.

6. Configure the plan and save it.

7. Save the rule, and click Save again to finish modifying the query.

To configure the review creation plan

1. Click Configure New On-Demand Review

2. Select an existing review configuration

3. Set the duration for the review

4. Specify the reviewer assignment logic

5. Enable any Review Intelligence Rules

6. Save the plan.

New reviews will start based on this creation plan when the rule conditions are met. Note that on-demand reviews are always created from the most recent graph snapshot data when the rule activates.

Rule Evaluation

• Rules are evaluated on a regular schedule aligned with data extraction intervals

• Multiple rules can be attached to a single query

• Each rule can include more than one review creation plan

• The same review configuration can be used across multiple rules

Related Topics

Overview

Veza Actions enable external processes when decisions and other events occur during an access review. Actions might trigger automated remediation, or announce to a team when a row is rejected, reviewers change, or the review is complete.

For example, you can use Veza to create a Jira issue or ServiceNow ticket for rejected access, or trigger actions in a custom application using a webhook.

Configuring Veza Actions

Administrators and operators can add actions when creating or editing a configuration, or by opening the Review Details sidebar in the reviewer's interface. Then, map actions to events they will trigger.

Events that can trigger Veza Actions:

• Reassign reviewer: When a user reassigns a row to another user.

• Approve row: When an approved row is signed off.

• Reject row: When a rejected row is signed off.

• Complete review: When the review is marked "Complete."

Possible actions depend on the event:

• Webhooks: Supports Reassign Reviewer, Approve Row, Reject Row, and Complete Review.

• Email Notifications: Supports Approve Row and Reject Row.

• Jira: Supports Reject Row.

• ServiceNow: Supports Reject Row.

When adding a configuration, use the Veza Actions section of the configuration builder to map events to actions in a target system. To enable default actions at the configuration level:

1. Go to Access Reviews> Configurations to create or edit a configuration.

2. In the configuration editor, scroll down to Veza Actions:

3. Toggle events that will trigger actions.

4. Pick a Veza Action for each event.

5. Save the configuration.

To configure Veza Actions for a 1-step review:

1. Go to Access Reviews > Reviews, or open the review from the Configuration Details page.

2. Click on the review name to open the reviewer's interface.

3. On the Review Details sidebar, find the Veza Actions section and click Configure Veza Actions.
4. Use the modal to assign or change the actions associated with different event types, and click Save when finished.

Lifecycle Management Auto-Revocation

Access Reviews integrate with Lifecycle Management for auto-revocation. When access is rejected during user access review, Veza Lifecycle Management can revoke a user's group membership automatically. For example, if the scope is Active Directory user to Active Directory security group, a lifecycle management workflow can remove a user from the group described in a rejected row.

Benefits:

• Revoke users from groups, roles, profiles, and permission sets automatically on reject.

• Supports all target apps supported by Lifecycle Management

• No custom integration - no webhooks

• To enable LCM integration, edit a review configuration and choose the Veza Action "Revoke access on Sign-off of Rejected Rows".

Requirements:

• Lifecycle Management and Access Plans must be enabled for your tenant.

• The Lifecycle Management integration for the target application must have permissions to remove roles, group membership, or otherwise manage relationships for users.

Implementation Considerations:

• The Revoke access on Sign-off of Rejected Rows action appears in Veza Actions for Configurations with supported source and destination pairs.

• Reviews must be structured with users as the source and the destination being roles, groups, or permission sets within the same target application.

• Auto-revocation does not support source-only Reviews.

• Source and destination have to be entities from a common application, such as Active Directory for a review covering Active Directory Users to Active Directory Security Groups.

• Auto-revocation does not support heterogeneous scenarios, such as Okta Users to Snowflake Databases.

Webhook payload

Access review events can trigger a JSON payload sent to an external listener, which parses the payload to trigger remediation actions.

The message from Veza will include the configuration (workflow) and review (certification) name and ID, and the event message or details about the review.

You must configure a service (such as an AWS Lambda function) to read the payload and take action, typically with an API call to the 3rd-party application.

Example webhook: review completed

Example webhook: rejected row

Access review events trigger this JSON payload. The payload includes critical identifiers and names for both the review configuration (workflow) and the specific review (certification), and details about the row and relationship under review.

If available, the response will include the accumulated raw system permissions a source has on a destination, and their equivalent effective permissions.

• details: The payload includes the full entity details for rejected or approved rows, including information about the source node, destination node, and possibly a related intermediate entity.

• Included entity attributes are: canonical_name, datasource_id, id, name, department, email, guest, idp_type, idp_unique_id, is_active, manager_email, manager_idp_unique_id, manager_name, property_*, provider_id, provider_name, type.

• decision: possible values are decisions are 1: NONE, 2: ACCEPTED, 3: REJECTED, 4: FIXED.

Tags and enrichment metadata

Tag example:

Enrichment data example:

Overview

Veza Access Reviews support a wide range of compliance scenarios, due to the flexibility of the query builder and the power of Veza's authorization graph. This document provides conceptual overviews to help scope access reviews for common use cases, based on your unique requirements.

The topics in this section include step-by-step instructions for common types of access reviews, which you can use to familiarize yourself with the configuration builder and customize to meet your needs.

• Access Reviews: Okta Group Membership

• Access Reviews: Okta App Assignments

• Access Reviews: Okta Admin Roles

• Access Reviews: Azure AD Roles, including built-in administrative roles.

• Access Reviews: Active Directory Security Groups (Including admin groups such as Active Directory Domain Admins, Enterprise Admins, and Schema Admins).

• Access Reviews with Saved Queries

• Source-Only Access Reviews

User access and entitlement reviews

You can use Veza to conduct both user access reviews and entitlement reviews:

User Access Reviews (UARs) are a specific type of review focused on inspecting access granted to users, whether directly or through inherited roles and group memberships. User access reviews can also be conducted to review the access-granting relationships assigned to a user, such as reviewing a user’s group membership or role assignments in an application.

Users whose access is under review can include:

• Employees: Full-time, part-time, or temporary staff.

• Contractors: External individuals engaged by the organization for specific tasks or projects.

• Consultants: External advisors given access to specific parts of the organization’s IT environment.

• Partners: Business partners with access to specific systems or data due to collaborative relationships.

An Entitlement Review is a review verifying that permissions on a resource, such as a database, file repository, or object store, are appropriate for the entities granted access. Entities may be users or non-human entities. Veza can show both the normalized effective permissions or the native system permissions for each row of access, with the option to filter on specific permissions of interest, such as reviewing all users with WRITE access to a database.

For either UARs or Entitlement Reviews, Veza can assign responsibility for completing these reviews to managers, department heads, application owners, IT system administrators, and others based on business requirements.

Review scopes

Veza operators define the settings and scope for a review (its configuration) with a flexible step-by-step builder. Each review will have an underlying query that defines the scope of the review. The query can be very broad (All Users to all Applications) therefore increasing the scope of the entities included in the review. Or, the scope can be quite specific and narrow to drill down on individual providers, resources, or identities (Okta Users in the finance department with "Update" permissions on Snowflake Table "Transactions"). The scope will define the entities and access relationships included in the review.

Reviewers approve, reject, annotate, or re-assign the entities or access relationships defined by the review scope, represented as rows in the reviewer interface. Each row is assignable to reviewers for a decision and sign-off. Depending on the review configuration, reviewers may be asked to certify individual entities, source-destination pairs, and optionally permissions:

Types of review scope

See Access Reviews Query Builder for more about query builder options.

Constraining the review scope

Adding different types of filters to the review scope allows for finer-grained scoping of the review. Multiple filters and filter types can be combined for greater expressive power:

• Single Entity: Constrain the review scope to a specific source and/or destination entity, such as reviewing all access for a single named Okta User, or all users assigned to a group named “Administrators”.

• Entity Attributes: Constrain the review scope to entities with some common attribute(s), such as Active Directory Users belonging to Active Directory Groups containing ‘admin’ in the name.

• Tags: Constrain the review scope to entities with specific tags applied, such as AWS IAM Users with access to S3 Buckets tagged as containing PII.

• Permissions: Constrain the entitlements review scope to entities with specific permissions on resources, such as Snowflake Local Users with Update and Delete permissions on Snowflake Databases.

Tag filters

For more information about tags and tag filters, see Filters and Tags. For reviews that involve tagged entities, two additional options are available:

• Promoted Tags: Administrators can promote tags to appear as custom attributes with dedicated columns in the reviewer interface. See Promoted Tags for more details.

• Show Source/Destination Tags: Enable this option in the configuration builder to show columns containing all tags on the source or destination entities in the reviewer interface. Reviewers can refer to the tag keys and values to better inform their decisions, and use the columns for filtering.

Permission filters

• Filtering by permissions helps constrain the scope of reviews to the riskiest access.

• Permission filters can specify either type of permission - System or Effective. Effective and system permissions cannot both be specified for the same query. See Review Presentation Options for more about permission types.

• Applying a permissions filter on a relationship that does not involve permissions (e.g., User-Group) will yield no rows.

Related entity requirements

• The query can require a specific Relationship entity connecting the query source and destination (such as an AWS IAM role connecting users and storage buckets).

• When a Relationship is specified and an entity of that category exists for a result, node details appear in additional review interface columns.

• This can offer reviewers visibility into the role-based access controls such as groups or roles, or the local user account used to access a resource.

Excluded and required entity types

• Specifying Excluded entity types will filter out any search results with a relationship to the chosen entity category. This option enables reviews, for example, on groups that do not have a corresponding IAM role, or users that are not part of a group. This option is not available when "All Parent Principals" is the query source.

• Specifying Included entity types will only return results that have a relationship to the chosen entity types. This option enables review of users and resources connected to a specific intermediate group, role, or policy.

• See Intermediate Entities for more on these query parameters.

You may have just received an email inviting you to participate in an access review using Veza. If so, welcome! Being assigned as a reviewer means that your expertise is needed to confirm that an identity (such as a user or service account) in your organization has the correct access to a particular application or resource.

How did you become a reviewer?

• A compliance officer or another individual at your company has assigned you as a default reviewer, such as for an audit of all employees you manage, or applications or resources that you own.

• Another assigned reviewer has requested your help to review, since you might have unique context into the identities and systems under review.

• Veza has identified you as the manager of an employee or owner of an application or resource, and auto-assigned you as a reviewer.

This guide provides some quick instructions to get started with:

Accessing the Veza platform

Log in to Veza with the Single Sign-On option, using your workplace's identity provider.

1. Browse to your organization's Veza login page:

   Follow the link in your notification email or use your identity provider's app portal to open Veza in your browser.

2. Click Login with SSO to sign in with your Identity Provider:

Viewing and continuing your reviews

After you log in, you will see the Veza Access Reviews page. Here, you can see all your assigned reviews and open the one you want to work on.

Pick a review from the list to open it:

1. Find the review to continue on the Access Reviews page.

   You could be assigned to reviews that are part of a recurring certification campaign, or a one-off review. If you have a few access reviews to work on, you can organize them by name, configuration, or due date.

2. Click Open to go to the review interface.

Reviewing access

The review interface is a spreadsheet-like view for reviewing an access relationship between two entities.

Use this page to approve or reject your assigned rows, sign off on the decision, and finish the review. You can close the window to resume later - progress is always saved.

To approve or reject a single row, click the Reject (❌) or Approve (✔️) button on the right. Depending on how your administrator has configured Veza, you might need to add a note explaining some decisions.

To see prior actions or undo a decision that you've made:

1. Expand the row Actions dropdown and pick an option:

   • View Action Log: View past decisions, notes, and other activity for the row.

   • Clear Decision: Clear the current "Approved" or "Rejected" decision.

Signing off on decisions

After your decisions are final, you can finish the review by signing off on your choices. Signing off on a row prevents further changes:

To sign off on rows:

1. Click Approve (✔️) or Reject (❌) to apply one or more decisions.

2. Click Sign Off at the top right.
3. In the confirmation window, review the decisions and click Confirm.

Bulk actions

To act on groups of rows, mark the checkbox for one or more rows, and pick an action to apply:

• Approve or Reject the rows.

• Reassign reviewers: Reassign the row to another user by email to perform the review.

• Add a note: Add a brief message explaining the decision, or details about how to remove the access.

Row details sidebar

Click the icon to the left of each row to open the details sidebar. Working from this view can be useful for quickly switching rows to inspect their full attributes, and signing off on individual decisions.

Change rows with your keyboard arrow keys, and click to approve, reject, or sign off on the current selection:

Filter by user

It can be useful to focus on one identity at a time when working on a large review. To quickly filter on a single user in the table:

1. Click Show Users.

2. Find a user name on the list.

3. Click View Details to only show rows that involve that user.

Filters

If you have any results to review, you can filter the view and use a bulk action to update all rows that meet a given criteria.

Filters can apply to source or destination entity attributes, or row metadata such as current decision or assigned reviewers.

To apply a filter:

1. Click Filters at the top of the review interface.
2. Find an attribute to filter on and click on it.

   For example, you can filter to find users whose Name starts with "A", any rows that have a "Rejected" decision, or show only users whose "Is Active" status is "True."

3. Pick an Operator, such as "Equals" or "Contains" to set the filter behavior.

4. Type in a Parameter: Enter the text to match. Click Apply to filter the reviewer interfaces based on your selection.

For more information, see Filters and Bulk Actions.

Reassigning reviewers

If you do not have the information or authority required to make a decision, assign another reviewer. If you're not sure, assign the review's creator. Otherwise, you can pick another employee at your organization.

To change the reviewer for a row:

1. Expand the row Actions menu and click Reassign Reviewers.

2. Pick from the list or enter the email of another reviewer.

3. Click Save to reassign reviewers and send a notification email.

For more information, see Assign Reviewers

Overview

Digest Notifications consolidate notifications for Access Reviews into digestible summaries, helping engage reviewers without excessive individual alerts. When enabled, reviewers will receive periodic emails with a list of pending tasks across multiple access reviews. Digest notifications can be configured on the Access Reviews > Settings > Notifications tab.

To limit the total number of emails to reviewers while keeping them engaged and informed of their assignments, Veza recommends enabling Digest Notifications as a global setting, on a daily, hourly, or weekly basis. Administrators can supplement these with additional notifications as needed by configuring notifications and reminders for specific reviews.

Administrators can enable Digest Notifications on the Access Reviews > Settings page, and customize the delivery interval and snooze periods. Digest Notifications are disabled by default.

Key Concepts

Digest Email: Reviewers receive a summary of all reviews where they have remaining work to do (i.e., assigned rows that are not yet signed off). This includes:

• The list of reviews with incomplete review tasks.

• The number of remaining rows assigned to the reviewer.

• A reminder if any of the reviews are new or overdue.

Normal Delivery: The regular frequency for digest emails (weekly by default). Administrators can adjust the delivery interval based on your review cadence and reviewer feedback.

Snooze: Use the Snooze feature to prevent notifications on certain days, such as weekends. Administrators can customize the days of the week when emails are not sent.

Global Digests: Review Notification Settings coexist with individual review notification settings. This setting affects all assigned reviewers, excluding denied recipients managed under Access Reviews > Settings > Reviewer Deny List.

Configuring Digest Notifications

To configure Digest Notifications:

1. Navigate to Access Reviews > Settings.

2. Locate the Digest Notifications section.

Enabling Digest Notifications

1. Toggle the Enable switch to turn Digest Notifications on or off.

Setting Normal Delivery

1. Under Normal delivery, select how often users should receive digests for regular notifications:

2. Choose the frequency:

   • Set the number (1-6 for days, 1-23 for hours)

   • Select the unit (day, hour, or week)

For example, "Deliver every 1 day" will send daily digests. When enabled, daily digests are sent at 11:AM PST, and weekly digests at 11:AM PST each Monday.

Configuring Snooze Days

1. Under Snooze, select the days of the week when notifications should not be delivered.

2. Check the boxes next to the days you want to exclude from notification delivery.

Overview

When creating a review or choosing to Reassign Reviewers, administrators can assign one or more default reviewers for all rows and auto-assign reviewers for individual rows. When auto-assigning reviewers, fallback reviewers are used for any rows where an owner or manager cannot be identified, or would be prevented from review for any reason.

This document describes how possible candidates are evaluated, and the behavior when a reviewer can’t be found or automatically assigned. The Veza support team can help you customize reviewer selection methods for your tenant.

Learn more:

Reviewer selection logic

Rows in an access review can be assigned to the possible candidates:

• Reviewers: Default reviewers assigned to all rows, specified at review creation. There can be more than one default reviewer for a review.

• User Managers / Resource Owner: A user identified as the manager of the employee whose access is under review, or a resource owner.

• Fallback Reviewers: Assigned when a user manager or resource owner cannot be found, or if a rule would prevent assignment (such as self-review prevention or the reviewer deny list). There can be more than one fallback reviewer.

Veza uses the following logic when assigning reviewers for a new review, and when rows are re-assigned after review creation:

• Reviewers are all candidates for assignment. User and Resource Managers are also candidates.

• Fallback Reviewers become candidates when no candidates are available or allowed for assignment.

• If a rule prevents a candidate's assignment, the other specified Reviewers are assigned.

• If all candidates are not allowed, Veza will try to assign alternate reviewers based on the selection method.

Changing the reviewer selection method

When a valid candidate can’t be found, Veza can assign that reviewer's manager, fallback reviewers, the workflow creator, or a Veza local user with the administrator role.

The Veza Customer Success team can change this global setting to enable any of the following selection methods. If the first selection method can find at least one allowed alternate reviewer, the user is assigned. Otherwise, the next selection method is attempted. Possible selection methods are:

• REVIEWERS_MANAGER | Assign the manager of the prevented candidate.

• CERTIFICATION_ALTERNATE_REVIEWERS | Assign to the first valid Fallback Reviewer, for certifications created using auto-assignment.

• WORKFLOW_CREATOR | Assign to the workflow creator.

• ADMIN | Assign to an arbitrary local Veza admin user.

For example, with the selection methods:

"value": {
    "selection_methods": [
        "REVIEWERS_MANAGER",
        "CERTIFICATION_ALTERNATE_REVIEWERS"
    ]
}

Veza will not assign the workflow creator or a system administrator as a fallback behavior. Instead, Veza will:

1. Assign the denied candidate's User Manager (if allowed).

2. Otherwise, assign the first valid Fallback reviewer.

3. Assign no reviewers for results where a valid manager or fallback reviewer does not exist.

Overview

Review Intelligence Policies can reduce the time reviewers spend working on reviews by automatically making decisions on rows based on filter criteria or previous decision status. They define rules to compare the current review rows with the most recently completed or expired review for the same configuration, and act on rows that are the same in the new and previous certification.

For example, a policy can "Reject rows where identities have no recent activity" or "Approve previously approved and unchanged" access.

Two default rules are optionally available for all reviews, and can be added when creating a review:

• “Approve previously approved and unchanged”

• “Rejected previously rejected and unchanged”

An automation definition includes:

• The criteria, such as “Row is unchanged from the previous review and was previously approved”

• The action, such as “Approve & Sign-off”

• Whether it is available for all or some configurations

• Whether it runs by default

Add policies during review creation

Operators can apply available Review Intelligence Policies when creating a review. These rules can also run by default at the start of any review.

1. Create a configuration or search for an existing one on the Access Reviews page.

2. Start or schedule a review for the configuration and enable automation by clicking Use Review Intelligence Policies.

3. Enable the rules to run from the dropdown and save your changes.

Review intelligence action logs

Open the result actions dropdown and click View Action Log to see when a rule was executed for a single result.

Administrators and operators can review all automated decisions by opening a review and checking the status bar above the table. A chart indicates the total action count.

Assign policies to some or all configurations

The options when creating reviews will depend on the Review Intelligence Policies available to the review configuration.

Overview

Veza enables access reviews across systems that involve assumed roles, inherited group assignments, and other complex hierarchies. The Relationship and Summary Entities query settings offer visibility into the exact path of access between a source and destination entity. These options can be especially useful to show relationships such as nested groups in Active Directory, SharePoint Sites and Libraries, or nested roles in Snowflake.

These configuration options enable reviewers to approve or reject not only the level of existing access, but whether the assignment is correct:

1. Show relationship: Choose one intermediate entity type (such as Okta Groups that connect Okta Users to Okta Apps). The review interface will include columns showing the name and attributes of intermediate entities, when they exist.

2. Show summary entities: Choose one or more intermediate entity types. The review interface will include a single column listing any entities of that type in the path between source and destination, and their sequence.

Effective and system permissions

• System Permissions: Specific to each application, resource or platform, System Permissions are the security metadata that define what actions can be performed against a given resource. When filtering by system permissions or using system query mode, reviewers can sign off on native permissions in the provider's unique terms. System permissions ranges from simple (file shares) to extensive and extremely complex (AWS), and can be unknowable and unactionable for non-technical users.

• Effective permissions: These represent the canonical CRUD equivalents of system permissions. These are an easy-to-understand, normalized “translation” of system privileges, making technical, complicated, and application-specific concepts consistent across all applications, resources, and platforms. Access Reviews based on Effective Permissions can simplify entitlement reviews for non-technical reviewers.

In the reviewer interface, the Permissions column will be empty for configurations that use system-mode queries. In this case, an optional column lists System Permissions.

Show intermediate relationship

If a configuration includes a Relationship to show, rows in the reviewer interface represent connections from one entity to another, by way of the related intermediate entity. For example, AWS IAM User to AWS S3 Bucket with AWS IAM Role for the Relationship will return rows with unique connections of User connected by Role (or directly) to an S3 Bucket. A query can specify only one Relationship.

These reviews will include optional columns showing the properties of the related entity, populated whenever an entity of the chosen category exists in a results authorization path. For example, when choosing a Role for the Relationship to show, reviews will include filterable and sortable Intermediate Role columns.

This option can be preferable when access paths are relatively simple and reviewers can benefit from details about the intermediate node.

Summary entities

If a path involves several related entities, access reviews can include details including the exact entity types and their sequence. Note that this option will change the total number of results, and show a row for each unique source and destination path.

Selecting Summary Entities is similar to selecting an intermediate Relationship, except that several entity types are selectable at once. When included in a query, the review rows will be entities of the source category with a relationship of the destination category, and will include a summary of the path that made the connection.

The entity types selected as Summary Entities for the query appear in the summary column. For example, a query from User to Bucket with a summary including Group and Role will return all the unique results of Users connected to Buckets, along with a summarized path. The summarized path might be GroupA -> Role1, or just Role2 (if no groups are in the path). If the user has direct access to a bucket (not by way of group or role), the summary will be empty.

Access reviews that use System mode in combination with Summary Entities will not include effective permissions calculations (the "Permissions" reviewer interface column will be empty). Instead, users will be able to review the "System Permissions" and "Summary Entities" columns for their assigned results.

By inspecting the relationships between intermediate entities and the resulting system permissions, reviewers can certify how access is actually configured for identities within an organization:

For example, for a well-managed Google organization, the authorization path will typically include roles bound to groups that a principal is a member of. However, the access summary indicates possible issues — such as when a policy is directly attached to the resource it grants permissions on, and when permissions are not granted by group assignment.

Generating the summary can add additional time to review creation, and summaries can contain a limited number of total entities:

• Path Summaries that contain too many nodes will have a placeholder (...) indicating the missing intermediate entities.

• Summary details for these results will indicate that additional nodes exist, but are not shown.

Examples

Path summaries are a review visualization option that can be especially useful for understanding role-based access controls for providers such as Microsoft Azure and Google Cloud. Choosing Summary Entities when creating a configuration enables reviewers to judge whether the configured permissions are appropriate based on security policies, including:

• If permissions are granted by group or role membership, or direct assignment

• The name of the role or group granting permissions

• The objects policies apply to, such as the query destination resource (for directly applied policies) or an upper-level resource in the resource hierarchy (for inherited policies)

• For Google Groups, the kind of membership (such as owner or member)

Possible entities for the summary depend on the provider and the search mode. For instance, when searching Google User to Google Cloud Project, options include:

• Google Cloud Folder

• Google Cloud IAM Policy

• Google Cloud Role Binding

• Google Cloud Organization

• Google Service Account

• Google Service Account Role Binding

• Google Group

• Google Group Membership

Policy inheritance and resource hierarchy

A Google Cloud organization has a hierarchical structure of folders containing projects, which contain individual services. A policy applied at the organization applies to all resources beneath it. Projects and services within a folder likewise inherit policies on that folder. See Intermediate Entities for more about searching for directly applied policies.

To create a query that returns results with any access, including a summary column indicating where in the resource hierarchy the permissions apply:

1. Create a configuration, and enable System mode

2. Pick the source and destination (Google User to Big Query Table)

3. Expand Advanced Options > Summary Entities

4. Pick the entity types Folder, Organization, Project, IAM Policy, Role Binding, and Group Membership

5. Finish customizing the configuration and save it

Reviews for this configuration will include a Path Summary column that indicates where a group, policy binding, or role exists in each result's authorization path. Reviewers can click on a role's name to verify the exact resource it is bound to. Reviewers can click an entity name to view more details.

Attribute filters on related entity properties

When applying an attribute filter on a required related entity, the following behavior applies:

• Attribute filter on Role: only the paths whose Roles meet the constraint appear in the Path Summary column.

• Attribute filter on Group: only the paths whose Groups meet the constraint appear in the Path Summary column.