# What is an access review?

> An access review is a periodic check that every person and machine still needs the access they have. What to review for secrets, and how often.

URL: https://crunu.com/learn/access-review
Language: en
Updated: 2026-10-30

An access review is a scheduled check in which an owner of a system goes through who and what has access to it, person by person and machine by machine, and confirms or removes each grant based on whether it is still needed for the job.

## Why it is needed

Access grows by default and shrinks only on purpose. People change teams and keep their old permissions. A contractor's access outlives the contract. A pipeline gets production access for one migration and keeps it. None of this is a breach; it is drift, and it widens what any one compromise can reach.

Reviews are also a standard control. NIST SP 800-53 asks organizations to "review accounts for compliance with account management requirements" at a frequency they define, and to align account management with "personnel termination and transfer processes" ([NIST SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), AC-2).

## What to review for secrets

- **People per environment.** Who can read production? Who can edit it? Does each still need it?
- **Groups and profiles.** Group membership is where access hides. Check what each group grants, then who is in it.
- **Machines and tokens.** Each server and pipeline credential: what it reads, whether it is still used, when it expires.
- **Outstanding links and invitations.** Anything that grants access to someone without an account.
- **Admin rights.** The few accounts that can grant access to everything deserve the closest look.

## Making it work

- **Review by the owner of the resource**, not by a central team that can't judge need.
- **Default to remove.** If nobody can say why a grant exists, take it away; it can be requested again.
- **Keep it small and frequent.** A quarterly review of production access is more likely to happen than an annual review of everything.
- **Record the outcome.** What was checked, what was removed, by whom.

## Common mistakes

- **Rubber-stamping.** Approving every line because the list is long. Shorter lists, grouped by role, help.
- **Reviewing permissions but not credentials.** A removed permission doesn't revoke a token that is still valid.
- **Forgetting the moves.** Transfers between teams are where excess access builds up fastest.

## How Crunu supports a review

Crunu has no built-in review campaign or reminder, and access granted to people has no expiry date, so the schedule is yours. What Crunu gives you is a clear picture to review:

- **Access per environment.** Each environment's access list shows who holds Editor, Reader, **Specific files** or Operator, directly or through an **access profile**. Changing a profile changes access for everyone in it, and each version of a profile is signed.
- **Machines and service tokens** with their environments, leases and usage limits.
- **Organization status**: machines online and offline, certificates near expiry, open alerts.
- **The audit log**, filterable by person, action, environment and period, for evidence of what changed.

*Figure: Example: in Crunu, Kiteline’s owner opens Jonas Lindqvist’s member page. Environment access shows him as an Editor on development and staging through the “Developers” access profile, and every production cell says none. A card beside it shows what the server stores: environment keys sealed to Jonas for payments-api development and staging, and no production key sealed to him at all.*

When a review takes someone out of an environment where they had the key, Crunu marks that environment as needing rotation, and **Pending actions** tracks it until a key holder rotates it. Removing someone from the organization rotates the keys as part of the removal and produces the [exposure report](https://crunu.com/learn/exposure-report) of what they received. For departures specifically, see [what to rotate when a developer leaves](https://crunu.com/guides/developer-offboarding-secret-rotation).

## Sources

- [NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), control AC-2, checked October 30, 2026.