Skip to main content
Auditors ask the same questions every cycle: who has access, was that reviewed, were backups taken and restore tested, who approved production deploys, and what were the security settings. This page covers the two features that answer them from records the control plane already keeps: access reviews and evidence packs.

​
What this is, and what it is not

An evidence pack is a signed export of platform records for a date range. It is evidence an auditor can examine, for example for SOC 2 or ISO 27001 style requests about access control, change management and backup practice. It is not a certification, an attestation, or proof that you meet any framework. It only covers what this control plane knows about. Controls that live elsewhere (laptops, HR onboarding, the cloud console) are outside it. Treat it as supporting material, not a verdict.

​
Access reviews

An access review is a campaign that snapshots every grant at the moment it starts: Reviewers mark each row keep or revoke. Nothing changes while you decide. When every row has a decision, Complete review applies the revocations through the same operations the Users, Teams and Tokens screens use, and writes one audit row per revocation. Guards still hold: you cannot remove yourself, the last user or the last root account. If a revocation fails, the successful ones stay applied, the failing rows show the reason, the campaign stays open, and you can retry or switch the row to keep. A campaign is only marked completed when every revocation applied. A campaign has a due date. An open campaign past its due date appears in the attention center for root accounts. Set repeat every N days to have the next review opened automatically after the previous one is completed and N days have passed since it started.
Database roles created through database access are not part of a review yet. Review them from each database’s access page.

​
Evidence packs

Pick a date range (up to 366 days) in Security center, Compliance, or:
Generation runs as a background job with progress, so it never blocks a request, and large packs are written to disk and streamed on download. A pack is only listed as ready after the archive was fully written, hashed and moved into place. If generation fails or the control plane restarts mid-way, the pack is marked failed and no partial file is offered.

​
Contents

Values that look like secrets are replaced with a placeholder before they reach the archive, using the same classifier as environment variable display.

​
Verifying a pack

Verification recomputes every file hash against the manifest and checks the signature, and fails if a file was changed, added or removed, or if the manifest or signature was altered. The signature key is derived from the control plane master key and never leaves it, so verification is done by the control plane that produced the pack. After a master key rotation, packs signed before the rotation can no longer be signature checked, though their file hashes still match the manifest. Keep the archive and its SHA-256 (shown in the pack list) with your audit records. Everything here is root only. Without a master key configured, access reviews work but packs cannot be generated.
Last modified on October 15, 2026