SOC 2 access evidence,
recorded as it happens.

SOC 2 auditors commonly test logical access under the Common Criteria CC6 series, including CC6.1, CC6.2 and CC6.3. However the criteria are worded, the requests that reach your team tend to be concrete: who held access to an in-scope system, who approved a particular grant, when access was removed after someone left or changed role, and who holds administrative privilege today.

Each of those questions is about a sequence of changes over the audit period, not a single moment. An answer is only as good as the record it comes from.

A screenshot shows one screen at one moment. A spreadsheet assembled the week before the audit shows whatever someone exported, pasted or typed into it. Neither shows the order in which changes happened, and neither can show that it has not been edited since.

Approvals are often worse. Access requests normally happen in direct messages and disappear: someone asks for production access, someone else says yes, and six months later nobody can reconstruct who approved it or on what basis.

Governax connects to the tools where access changes happen and writes each change into an append-only ledger for one entity. It records; it does not enforce. Events arrive after a change has taken effect in the source tool, and nothing in Governax grants, revokes or blocks access.

• Continuous recording from seven tools: Slack, GitHub, Okta, Google Workspace, AWS, Microsoft Entra ID and GitLab. Slack, GitHub and Okta push events within seconds; the other four are polled every 10 minutes.
• A baseline snapshot when each tool is connected, recording who already has access, so the ledger has a starting position rather than only the changes from then on.
• Slack access requests: /governax captures a free-text request and the approver you tag, and records the Approve or Deny decision and who made it. Approving records the decision; a human still performs the grant.
• A per-entity, append-only SHA-256 hash chain. Database triggers reject every update, delete and truncate, and each event carries the hash of the one before it, so an altered or removed entry breaks every link after it.
• Verification by the auditor. Give your auditor the reader grade on the entity and they can read the ledger and re-run verification themselves, without being able to disconnect the tools feeding it. Every verification run is itself recorded.
• Filtering that answers the question directly: tool, event type, actor and a date range that matches when the change happened in the source tool.

An auditor asks for every permission change in GitHub last quarter. You filter the entity's ledger by tool and date range, open any event to see its normalised fields, raw payload and recomputed hash, and run a full verification so the auditor can see the chain is intact.

For privileged access, one event type spans several tools. access.admin_role_granted is shared by Okta, Google Workspace, Microsoft Entra ID and GitLab, so a single filter lists admin role grants across all four.

Be precise with your auditor about the limits. Verification proves that what was recorded has not changed; it cannot prove that everything that happened was recorded. Completeness comes from the connectors, and the baseline gives you a known starting point. The hash also does not yet cover the actor and subject fields, which is documented as a known limitation.