How can we help?

Configuring and monitoring access governance policies

Uri Hershkovitz
Uri Hershkovitz
  • Updated
Torii Identity

Overview

This article discusses the specifics of the Access Governance page, and how to configure and monitor access governance policies. To read an overview about Access Governance in Torii, click here

In many organizations, access decisions happen across many systems and over time. People join teams, change roles, take on temporary responsibilities, or keep access they no longer need. As a result, access can drift away from what the organization intended.

This creates two common problems:

  • Some users end up with more access than they should have.

  • Some users are missing access they should have in order to do their jobs.

Torii's Access Governance feature is designed to solve both. This gives admins a structured way to define access intent per app and account, and then surface deviations when actual access no longer matches that intent.

 

The Access Governance page

Access Governance has a dedicated page in Torii where admins can manage policies and review deviations.

The page includes three tabs:

Governance Policies
A table of all defined access policies.

Policy Deviations
A centralized table of users whose access does not match policy.

Groups
A shared groups experience used to define and manage the user groups referenced by policies. These groups are shared with the app catalog feature. 

Grace Period
A centralized table of users who retain temporary access during a job function change. You can read more about Torii's grace period here.

 

You can also configure access governance feature settings here by clicking on the Access governance settings button.

 

The Governance Policies tab

The Governance Policies tab is where admins create and manage policies for connected apps.

From this tab, you can:

  • View all policies in one table

  • Create, edit or delete a  policy

  • Enable or disable monitoring for a policy

  • Run policy monitoring manually

Each row in the Governance Policies page represent one policy. 

The tables also includes information such as the number of groups affected by the policy, the number of deviations found, the last policy evaluation time and whether the policy is active.

This makes it easy to understand which apps are governed, which policies are enabled, and where issues are being detected.

 

Creating a policy

Creating a policy is designed to be straightforward and app-focused.

To create a policy:

  1. Click on the [+ Add Policy] button

  2. Under Governance scope, select and app you want to create a policy for

  3. Select how the app is governed:

    • Direct integration (role-based) - and select the app account to monitor

    • Via IDP group (group membership-based) - and select the relevant IdP (and account) to compare access to

Note: If the app does not have a connected integration, only the "via IDP group" option is available.

  1. Under Access rules, Add rules that constitute the policy:

    • Each rule applies to one role users can have in the selected app and account.

    • Each rule can apply to multiple groups, each with their own access type.

    • A policy can have any number of rules.

    • For IDP-governed policies, access type still applies, but instead of checking roles in app, Torii checks membership in the configured IDP group.

Note: Policy rules act as an allowlist - any user discovered with app access that no rule applies to will be considered out of policy (a deviation). Make sure to set rules for all app roles / relevant IdP groups before enabling the policy to avoid incorrect deviations.  

The available access types are:

Allowed
Users in the selected group are permitted to have this access.

Birthright
Users in the selected group should automatically have this access.

Denied
Users in the selected group should not have this access.

  1. Under Enforcement settings, select your policy's remediation level. Available remediation levels are:

    1. Default configuration (default) - the policy will inherit the global remediation level setting configured in the Access governance settings page. 

    2. None - Torii will monitor policies for deviations, but will not take autonomous action. 

    3. Open Task - Torii will automatically open a task assigned to the app owner to fix discovered deviations.

       

Note: Task-based remediation is not currently available for IdP group-membership based policies. 

  1. Click on Review & Save

  2. Select whether the policy should be saved and immediately activated or not.

 

Important notes

  • For Direct Integration policies, user access is reviewed at the app role level. For connected apps which do not provide role data, you can either upload user data manually, or use the "any access" option to govern general app accessibility.
  • For IdP group-based policies, user access is reviewed in comparison to the defined IdP groups. A user with access to the app (as reported by the IdP) but not in the correct IdP group are out of policy. 
  • Policy rules act as an allowlist - any user discovered with app access that no rule applies to will be considered out of policy.
  • A policy must include at least one fully defined group rule before it can be saved.

  • If your app has roles that for some reason were not discovered by Torii, you can create custom roles directly during the policy configuration process
     
  • Access governance settings (for both remediation level and grace period) only affect future changes - they do not retroactively update current deviations etc. 
  • Tasks to resolve an open deviation are, by default, assigned to the primary app owner. If one does not exist for the app, the first selected app owner (from the All app owners field) is assigned to the task. If no app owners exist for the app, the first user with the Admin role is assigned instead. This makes sure that the task is always assigned to someone so that the deviation is actually resolved. 
  • The same app and account can only have one role-based policy, but can have both a role-based policy and an IdP group-based policy. You can combine them to monitor (and fix) issues with both IdP group membership and actual app role. 

 

Best Practices

  • For non-integrated apps, you can upload a user file and then create a governance policy for the app. You can do the same with Google Sheet integrations and custom integrations (including data uploaded via Torii Sheets)
  • Alternatively, if you govern access today using IdP groups (for either integrated or non integrated apps in Torii), you should use the IdP group-based policies to match your current processes for these apps.
  • Because policy rules act as allowlists, make sure to set rules for all app roles / relevant IdP groups before enabling the policy to avoid incorrect deviations.  
  • If working with others to set up complex policies, save the policy in-between updates but do not active the policy until you've finalized the configuration.
  • Test out your policy configurations with remediation level set to None. Once you're happy with the results, change remediation level to Open Task.

 

Other actions in the Governance Policies page

When hovering over a policy in the governance policies tab, you will see three additional action buttons:

  • Edit policy - this allows you to edit an existing policy, using the same flow as policy creation. Please note that once a policy is created, you cannot edit the app and account it refers to.
  • Delete policy - this will delete the policy completely. Any open deviations will be marked as resolved. 
  • [For inactive policies] Preview deviations - this will send you an email with the policy deviations preview, similar to the button in the policy creation flow.
  • [For active policies] Evaluate now - this will run the policy evaluation monitoring process immediately. 

 

Policy deviations

Once monitoring is enabled, Torii checks policies on a recurring basis and identifies users whose access is out of policy. There are three deviation types, which are called Access Issues:

Role mismatch
The user has a different access level (or access via IdP group) than expected by configured policies.

Unauthorized access
The user has access to this app (with any role/IdP group) but are not allowed access of any kind, based on your policies.

Missing access
The user does not have access to this app, but is expected to have access based on birthright access type configured in your policies.

You can see these issues and additional details on them in the policy deviations tab.

 

Delayed Privilege removal

With Access Governance policies, you can easily set what the correct state is for each user's position. This sets the standard from which Torii detects any deviations. 

Additionally, you can define Torii access governance policies to include a grace period: a configurable time frame that starts when a user no longer meets an access policy due to a change in their attributes (a “mover” event).

Instead of immediately marking the user as out of policy, Torii keeps them temporarily in policy for a defined period of time. This allows employees who transition between roles, departments or projects to retain their previous access levels and finish, clean up or pass on tasks they are currently engaged with, while also immediately receiving required access based on their new position. You can read more about Torii's grace period here

 

The Policy Deviations tab

The Policy Deviations tab provides a centralized view of all detected deviations.

It is designed for auditing, investigation, and ongoing monitoring. From this tab, admins can view all deviations in one table, and the context for each deviation.

By default, the table shows:

  • User

  • App

  • Account

  • Access Issue

  • Details (these provide an explanation and additional information on the issue)

  • Detected date

You also have access to deviations-specific columns such as remediation date (when was the deviation resolved), deviation age, discovered role, expected roles/groups etc. in the table. This gives admins immediate context, so they do not need to piece together the reason manually. 

Policy deviation information and all applicable columns are also available in Torii Dashboards so you can create dedicated widgets and dashboards for them. 

Torii admins are also notified about open governance policy deviations on a recurring schedule. You can find the setting for this notification in the notifications settings page (available to users with the Admin role only).

 

Resolving policy deviations

A deviation is considered closed when it is no longer detected. This can happen for several reasons, which include:

  • The user’s access changes to an allowed role

  • The user becomes part of a group that allows the access 

    • Either due to user attribute change

    • Or due to group definition change

  • The policy is updated and the user now is allowed their current role

  • The policy is disabled (This closes all open deviations)

  • The relevant integration is disconnected (This closes all open deviations)

Please note, when a policy deviation task assigned to a user is marked as done, the deviation does not automatically resolve. Instead, the policy is reevaluated, and the deviation resolved if the issue was, indeed, resolved. 

 

The Groups tab

The Groups tab is where users can view and manage the groups used in Access Governance policies. These groups are also shared with the app catalog. 

Groups are the foundation of governance policy eligibility in Torii. They define which users a policy applies to based on their attributes, such as department, team, location, or any other user segment you want to govern. When you create a policy, you choose one or more groups and define what access the users in those groups should have for a specific app and account.

From the Groups tab, admins can:

  • View existing groups

  • Create , edit and delete groups that can be used in governance policy confgurations.

  • View the users that compose these groups.

This makes it easier to reuse consistent user segments across policies instead of redefining eligibility each time.

 

Creating a group

To create a new group:

  1. Click on the [+ Add group] button in the groups page
  2. In the sidebar that opens, name the new group
  3. Select filters to fine tune the list of users in your group
  4. Preview the user list by expanding the discovered user list
  5. Save the group by clicking Save.

You can also create groups directly from the policy configuration page using a similar experience.

 

Permissions and availability

The Access Governance feature is available only to customers with the Torii Identity module. It is available to all user plans. 

Access to this feature is controlled by a dedicated scope: Access Governance

  • Take Action scope allows users to create, edit, enable, disable, and delete policies and groups. 

  • View Only scope allows users to see policies, deviations and groups but cannot make changes

  • Users with No Access cannot enter the Access Governance page

By default, users with the Read Only role have the Access Governance: View Only scope, and users with the Admin role have the Access Governance: Take Action scope.

 

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request