Back

How Revocation, Remediation, and Reconciliation Work in Veza Access Reviews

A deep dive into Veza’s closed-loop remediation for access reviews

Access reviews are only meaningful when decisions are turned into real-world outcomes. Approvals need to be honored, rejections must lead to revoked access, and organizations must be able to prove that remediation actually happened. Veza Access Reviews was designed with this principle at its core: a closed-loop access governance system where reviewer decisions trigger action, remediation is verified, and reality remains reconciled with reviewer intent.

This blog walks through how revocation, remediation, and reconciliation work across the Veza platform, including what happens when reviews close, how Veza Actions automate remediation, common use cases, and why reconciliation is essential for completeness and accuracy.


1. What Happens When a Review is Closed

When an access review reaches completion, Veza triggers backend processes that ensure reviewer decisions, especially rejections, lead to the correct remediation actions. Completion itself can be defined in two different ways:

  • Completion when all rows are decided:
    The review is considered complete only when every review row item has a decision (approved or rejected) and is signed off. This approach prioritizes completeness and is very common.
  • Completion when the review due date is reached:
    A review can be configured for the system to automatically decide and sign off at the configured due date, even if not all rows have been decided. This model prioritizes timely certification cycles and ensures reviews don’t remain open indefinitely.

Regardless of how completion is defined, once the review enters the completed state, Veza administrators can optionally activate three core capabilities to enforce and validate decisions:

  • Auto-Decisioning: If reviews are set to complete on the review due date, Veza can automatically apply a default decision on undecided rows.  This ensures all rows on a review are completed – either by reviewers or the system.
  • Auto-Revocation: Removes rejected access on target applications where configured, ensuring unwanted entitlements are quickly remediated.
  • Auto-Validation: Continuously checks the Access Graph to confirm that access associated with rejected rows has indeed been revoked—and marks items as “Fixed” when access revocation is detected. (a recent platform update).

Together, these mechanisms ensure that review outcomes not only reflect reviewer intent and review completeness, but also translate into measurable, auditable changes across your environment.

1a. Auto-Decisioning | Default decision applies to unactioned rows

Veza Access Reviews supports the ability for an administrator to configure the system to apply a default decision (i.e., approve, reject, and, in some cases, no decision) on rows that remain unactioned by reviewers by the review due date.  This setting helps administrators ensure that all rows in a review will be completed.

1b. Auto-Revocation | Actual removal of rejected access

As a feature of Veza Access Reviews Advanced, Auto-Revocation automatically removes access marked as rejected and signed off..

Key Highlights:

  • Can revoke access through integrated systems natively
  • Removes access for rejected entitlements as soon as the row rejection is signed off
  • Ensures prompt remediation without waiting for manual operator action
  • Can revoke access for supported applications and entitlement types for the following scenarios:
    • Review is structured user-to-entitlement (i.e. Active Directory User to Active Directory Group)
    • The entitlement is a summary entity for a user-to-resource review (i.e. Active Directory User through Active Directory Groups to SQL Databases).

Auto-Revocation is ideal for scenarios with broad entitlement-level access grants where the organization prefers automated revocation on rejection. Veza Access Reviews supports Auto-Revocation for the same set of enterprise applications and platforms supported by Veza Lifecycle Management, Access Requests, and Access AuthZ. 

1c. Auto-Validation | Verifying that rejected access was actually removed

While Auto-Revocation removes access, Auto-Validation verifies that the access removal truly occurred – irrespective of whether it was removed out-of-band by an application administrator                                                                                                                                                                                                                        or triggered automatically using Auto-Revocation.

When Auto-Validation is enabled, Veza periodically checks the Access Graph after the review is done to confirm whether rejected access still exists in the graph.

If the rejected access is no longer detected in the graph, then the system can infer that access was revoked successfully and automatically marks the item as Fixed and logs:

“Rejected access no longer detected by Veza.”

Importantly, Auto-Validation is completely agnostic to how access has been revoked (via Access Reviews, via application console, via API, etc.), but rather ensures that rejected access has been verifiably removed when Auto-Validation has completed.

With Auto-Validation, administrators can configure:

  • Validation triggers, such as the review due date or review completion event
  • Maximum validation duration (default: run for 30 days)
  • Whether a review can be completed before all rejected items are validated

Validation at the configured trigger and the system continuously checks the Access Graph for the defined period of time to confirm that access associated with rejected rows has indeed been revoked.  If the access no longer exists in the graph, Auto-Validation marks the rejected row as “Fixed”, meaning that remediation is detected; this ensures accuracy.

Why this matters:
Auto-Validation eliminates manual reconciliation work and provides auditors with irrefutable evidence that rejected access no longer exists.


2. How Veza Actions Enable Remediation and Revocation

Veza Actions turn identity governance from a passive review process into an active remediation engine. Instead of simply surfacing risks or generating notifications, Veza Actions allow organizations to operationalize reviewer decisions and enforce an action in near real-time. This ensures that rejected access is not only identified it is also removed, tracked, and validated through automated workflows.

Veza Actions act as the operational layer of the Veza platform, executing the changes required to enforce identity decisions at scale. They power a wide spectrum of identity use cases, but their role in Access Reviews is especially critical. When a reviewer rejects access, Veza Actions can translate that decision into actual downstream system action.

Supported Remediation & Revocation Actions

Veza Actions support a wide set of enforcement operations, including:

  • Email, Slack, or Teams Notifications — Notify the relevant stakeholders when a rejection is triggered.
  • Trigger ServiceNow Workflows — This could run the gamut of available services in an organization, but typical uses might be Disable User Accounts or Remove Group Membership
  • Trigger Jira workflows — automatically create Jira tickets intended for human-led remediation
  • Invoke automation via webhooks — integrate with orchestration engines, custom APIs, or in-house tooling

Each action is tied directly to reviewer decisions, ensuring that no rejected item stalls, gets lost, or requires manual follow-up.


3. Use Cases for Each Veza Action in Remediation & Revocation

Veza Actions give organizations the flexibility to remediate rejected access through direct automation, integrations with IT systems, or operational workflows. Whether a revocation is automatic, delegated to an application team, or requires a ticketing process, Veza Actions ensures every rejected entitlement has a defined, traceable path to remediation.

Below are the most common categories of real-world use cases.

Use Case 1: Automatic Revocation

Purpose: Immediately revoke access once a reviewer rejects a row and signs off.

Action Types:

  • Revoke Access on Sign-Off of Rejected Rows

Note: Auto-Revocation is a native feature of Veza Access Reviews Advanced.

Examples:

  • Removing an AD or Okta group membership when the reviewer rejects the entitlement.
  • Revoking a Snowflake role once the review is signed off.

Why it matters:
High-volume access (roles, groups, policies) demands fast revocation with minimal operator involvement; this is the most e

Use Case 2: Workflow-Based Remediation Through ITSM Tools

Purpose: When revocation must be tracked, approved, or executed by another team.

Action Types:

  • Jira ticket creation on “Reject Row”
  • ServiceNow incident or change request

Examples:

  • Creating a ServiceNow ticket when a privileged production role is rejected.
  • Support closed loop — Pull the updated ServiceNow/Jira ticket information back to Veza and onto the rejected row for better auditability.
  • Triggering a Jira issue for the AppOps team to remove database or application access not managed by IGA.

Why it matters:
Not all systems support direct automation. For these, Veza Actions ensure every rejected item still has a documented remediation path.

Use Case 3: Notification-Based Remediation for Human-In-The-Loop Processes (Webhook-based Veza Actions)

Purpose: Alert specific teams or owners when rejected access requires attention.

Action Types:

  • Slack notification
  • Microsoft Teams notifications
  • Email (Reject Row / Approve Row)

Examples:

  • Slack notification to the DevOps channel when a repository writer role is rejected.
  • Microsoft Teams alert sent to the cloud security team when elevated cloud access is removed.
  • Email to an application owner when a user’s role is denied.

Why it matters:
Lightweight channels like Slack and Teams can be ideal when the remediation is simple but still requires a human step.

Use Case 4: Custom or Complex Revocation Through Webhooks

Purpose: Trigger remediation in custom-built systems or multi-step revocation workflows.

Action Types:

  • Webhooks for Reject Row, Approve Row, Reviewer Reassignment, and Review Completion
  • Webhook to custom automation
  • Trigger multiple Veza Actions

Examples:

  • Triggering an internal API to disable a legacy system account.
  • Pushing revocation events into an orchestration engine (e.g., StackStorm, Rundeck).
  • Integrating with in-house privilege management or entitlement cleanup tools.
  • Multiple Actions for a single rejection – Send Email Notification and Create a Jira Ticket.

Why it matters:
Many organizations have bespoke systems where neither ITSM nor native integrations are sufficient. Webhooks provide complete flexibility.


4. Why Reconciliation Matters: Ensuring Completeness & Accuracy

Reconciliation is the foundation of a trustworthy user access review program. Decisions made by reviewers—whether approvals or rejections—only hold value if the underlying access data is complete, accurate, and consistently aligned with the real-world state of entitlements. This is where reconciliation becomes essential.

Veza’s reconciliation approach ensures that the Access Graph reflects the truth of your environment, and that every reviewer’s decision can be tied back to verifiable evidence. Auditors evaluating SOX, SOC 1, and SOC 2 controls expect strong management review controls, which require organizations to prove that the Information Produced by the Entity (IPE) used in the review is reliable. Reconciliation provides that assurance.

Closed-Loop Reconciliation: From Reviewer Decision to Verified Remediation

Reconciliation does not end once the review is completed. Veza continues validating that rejected access is actually removed through Auto-Validation, which:

  1. Checks the Access Graph on a periodic schedule
  2. Confirms when rejected entitlements no longer exist
  3. Automatically marks rows as “Fixed”
  4. Logs evidence (“Rejected access no longer detected by Veza”) for auditors

Reconciliation connects reviewer decisions to actual outcomes—closing the loop between certification and enforcement.

Audit-Ready Evidence: Why Reconciliation is Non-Negotiable

Regulators and auditors expect organizations to demonstrate:

  • That the review included all relevant users and entitlements (completeness)
  • That the data used in the review accurately represented system state (accuracy)
  • That rejected access was truly revoked (remediation validation)
  • That processes were logged and traceable (audit evidence)

Veza supports all these requirements with built-in completeness checks, snapshot validation, event logs, and automated remediation confirmation.


Bringing It All Together: Closed-Loop Access Governance

Veza’s approach ensures access reviews are not just check-the-box exercises.
Each rejection sets off an automated chain:

  1. Reviewer rejects access
  2. Revocation occurs (automatically or through Veza Actions)
  3. Validation confirms the access is removed
  4. Reconciliation ensures system state aligns with decisions
  5. Mark as Fixed (manual or automatic) provides final audit closure

With these capabilities, organizations achieve:

  • Higher accuracy
  • Faster remediation cycles
  • Reduced operator workload
  • Reliable audit evidence
  • Stronger compliance posture

Conclusion

Revocation, remediation, and reconciliation are the pillars of a trustworthy Access Review program. Veza’s User Access Review product delivers all of them through Auto-Revocation, Auto-Validation, Veza Actions, and Access Graph–driven reconciliation.

The result is a truly closed-loop access governance system—one where reviewer decisions directly lead to secured systems, reduced risk, and airtight auditability.


Next steps

Learn the practice

See it in action

Talk with us

  • Request a Demo
    See a live walkthrough of Veza Access Reviews with Access Graph context, Auto-Revocation, Auto-Validation, and Veza Actions. Close the loop from review to fix.

Table of Contents