What does an access review need?

An access review asks a simple question that is hard to answer well: who has access to this system, and should they? To answer it, a reviewer needs a list of current access, the changes since the last review, and a way to show the auditor afterwards that the list they reviewed was accurate.

Privileged access gets the closest attention. An administrator role granted months ago, or an automation holding a directory role, is exactly the kind of finding a review exists to catch.

Why point-in-time exports are weak evidence

Most reviews start from an export taken on the day: a user list from the identity provider, a members page from the code host, a spreadsheet stitched together from both. An export says nothing about what happened between reviews, so a grant that was added and removed again in the meantime never appears.

An export also carries no proof of its own. Once it has been through a few hands, nobody can show that the list the reviewer signed off is the list the system produced.

How Governax helps

Governax records every access change from your connected tools into one ledger per entity, and opens that record with a snapshot. As the Microsoft Entra ID docs put it, the event stream says what changed, and the snapshot says what is true now, which is the question an access review actually asks.

  • A baseline snapshot when each tool is connected, recorded as access.baseline_observed events. In Entra ID it includes every holder of every activated directory role, service principals included.
  • Every change between reviews, from Slack, GitHub, Okta, Google Workspace, AWS, Microsoft Entra ID and GitLab, filterable by tool, event type, actor and date range.
  • Privileged access across tools with one filter: access.admin_role_granted is shared by Okta, Google Workspace, Microsoft Entra ID and GitLab.
  • Approvals recorded alongside the changes: /governax requests in Slack, and the Approve or Deny decision with who made it.
  • A per-entity, append-only SHA-256 hash chain that a reviewer or auditor with read access to the entity can re-verify at any time.

What to check before each review

Know what each baseline covers. Slack records which channels exist and how many members each has, but not who is in which channel. GitLab's snapshot covers group-level membership, not every project. Entra ID's leaves out group membership. In each case, changes from connect time forward are still captured.

Reconnect GitHub before a review. GitHub sends no webhook when someone is promoted to organisation owner; the change is caught by comparing a fresh snapshot at connect and reconnect.

Check connector health. Nothing alerts you when a connector goes quiet, so look at the last event time on the Integrations page as part of your review cadence.

Governax does not run the review itself. It does not assign reviewers, collect sign-offs or revoke access; those decisions happen in your process and in the tools themselves.

Questions

User access review evidence FAQ

Can Governax tell us who had access on a specific date?

The ledger holds the inputs: the baseline snapshot taken when the tool was connected and every recorded change since, filterable by date range. It does not produce a point-in-time access list on its own; you read it from the baseline and the changes after it.

Does Governax revoke access that a review finds?

No. Governax records access changes; it does not grant, revoke or block anything. Remove access in the tool itself, and the removal is then recorded in the ledger.

How do we show an auditor the review evidence?

Give the auditor the reader grade on the entity. They can read and filter the ledger and run a verification themselves. Governax has no data export today.

What does the baseline not cover?

It varies by tool. Slack does not baseline channel membership, GitLab's snapshot is group-level only, and Entra ID's does not include group membership. Changes from connect time forward are captured in every case.