Overview

Once a governance policy is active, Torii checks it on a recurring basis and flags every user whose access is out of policy. This article explains the types of deviations, how to review them on the Policy Deviations tab, how you're notified about them, and how they get resolved. It's part of the Access Governance guide; for what the feature does and how it works, start with What is Access Governance?. To set up policies, see Configuring access governance policies.

Policy deviations

There are three deviation types, called Access Issues:

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

Unauthorized access 
The user has access to this app (with any role or IdP group) but isn't allowed access of any kind, based on your policies.

Missing access 
The user doesn't have access to this app, but is expected to have it based on a Birthright access type in your policies.

When a deviation is not flagged

Two settings can keep a user from being flagged even when no rule covers their access:

• App owners. When Allow app owner access is on (the default), the primary app owner and everyone listed in All app owners are never flagged for Role mismatch or Unauthorized access on the apps they own. They are still flagged if a Denied rule applies to them, or for Missing access if they should have Birthright access and don't. See Access governance settings.

• Grace period. When a user's attributes change (a "mover" event) and they no longer meet a policy, Torii can keep them in policy for a set time. This lets them finish or hand off their current work while they immediately get the access their new position requires. Users in a grace period appear on the Grace Period tab, not as deviations. You can read more about Torii's grace period here.

   

The Policy Deviations tab

The Policy Deviations tab is a centralized view of all detected deviations. It's designed for auditing, investigation, and ongoing monitoring.

Deviation cards

Four cards above the table group deviations by risk. Click a card to filter the table to that category. The tab opens on Critical deviations by default, so the highest-risk issues show first.

The deviations table

By default, the table shows:

• User
• App
• Account
• Access Issue
• Details (an explanation and additional information about the issue)
• Detected date

You can also add deviation-specific columns, such as remediation date (when the deviation was resolved), deviation age, discovered role, and expected roles or groups. This gives admins immediate context, so they don't need to piece together the reason manually.

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

Deviation notifications

Torii admins receive a recurring email about open policy deviations.

• Which deviations are included: set in Access governance settings → Deviation notifications. You can choose any combination of the four card categories above. By default, only Critical deviations are included. See Access governance settings.

• How often you get the email: set by each admin in the notification settings page. Each admin chooses their own frequency.

   

Resolving policy deviations

A deviation is closed when it is no longer detected. This can happen when:

• The user's access changes to an allowed role (through automatic remediation or manually).
• The user joins a group that allows the access, either because their attributes changed or because the group definition changed.
• The policy is updated and the user's current role is now allowed.
• The policy is disabled. This closes all of its open deviations.
• The relevant integration is disconnected. This closes all open deviations for it.
• Allow app owner access is turned on and the user owns the app. Torii re-evaluates all active policies within a few minutes.

When a deviation task is marked as done, the deviation doesn't close automatically. Instead, Torii re-evaluates the policy and closes the deviation if the issue was actually fixed.

Who gets deviation tasks

Tasks to resolve an open deviation are assigned to the app's primary owner. If the app has no primary owner, the first user in All app owners gets the task. If the app has no owners at all, the first user with the Admin role gets it. This makes sure every task has an owner, so the deviation actually gets resolved.

Remediating a deviation from the table

Each row in the Policy Deviations table has actions you can use on hover:

• Remediate now: Torii fixes the access directly. Depending on the deviation type, it adds or removes the access, or sets the user to the expected role.
• Create task: When the deviation can't be remediated automatically, Torii opens a task for the app owner to resolve it.

The Actions Taken column links to the resulting workflow execution or task, so every manual remediation is fully traceable, the same way automatic remediations are recorded.

Permissions and availability

Access Governance is available to customers with the Torii Identity module. Users with the Access Governance: View Only scope can see deviations; remediating requires Take Action.