ISO 27001 access control,
backed by a verifiable log.

Annex A of ISO/IEC 27001:2022 includes controls on access control (5.15 to 5.18) and on logging (8.15). In a certification or surveillance audit, that typically turns into requests for evidence that access changes happen the way your policy says, and that the logs recording them are kept and protected.

The second part matters as much as the first. A log is only useful as evidence if you can show it has not been edited after the fact.

Screenshots of an admin console and spreadsheets compiled for the audit are snapshots that someone produced by hand. They do not show the order of events, and nothing in them shows whether they were changed between being produced and being handed over.

Logs that live inside each tool have their own problem: each tool keeps its own format, its own retention and its own idea of an event. Microsoft keeps directory audit records for 7 days on a tenant without a Premium licence, for example, so anything older is gone unless it was recorded elsewhere.

Governax reads access and configuration changes from your tools and writes each one into an entity's ledger in one shared event shape. The ledger keeps everything it has recorded, and nothing in it can be edited.

• Continuous recording from Slack, GitHub, Okta, Google Workspace, AWS, Microsoft Entra ID and GitLab, through connectors that read from each tool and never grant, revoke or block access.
• A baseline snapshot of current access when each tool is connected, so later changes are changes from a known position.
• Append-only storage enforced by the database: triggers reject every update, delete and truncate on the ledger table, for any connection, not only the application.
• A per-entity SHA-256 hash chain. Each event is hashed over its contents and the previous event's hash, so editing a covered field or deleting an event breaks the chain from that point on.
• Verification on demand. Anyone with read access to the entity, your auditor included, can re-walk the whole chain and see whether it comes back verified or broken.
• Access approvals from Slack: /governax requests and the Approve or Deny decision are recorded as ordinary ledger events.

Ledgers are per entity, not per organisation, and an entity can be a headquarters, a branch, a department or a business unit. If your certification scope covers one part of the business, its tools can feed one entity, and you can give the auditor the reader grade on that entity's ledger without giving them every other entity's.

Plan entities around your tooling. A connector belongs to exactly one entity, so if the whole company shares one Slack workspace, that workspace feeds one entity.