Access Reviews
Access Reviews periodically examines every IAM principal (user, role, group) on a single connection (AWS account), and turns "who kept, revoked, or reduced which permission, and why" into a signed record.
1. Creating a review
Starting a new review on a project's Access Reviews screen builds an evidence snapshot by combining the IAM inventory at that moment with the results of the most recently completed IAM permission analysis (paths, excessive access). That snapshot is written to your own storage, and every decision in the review from then on is made against it.
A review is never created without evidence behind it:
- if this connection's storage (your own S3 + KMS) isn't set up yet, a review can't be created;
- if no IAM permission analysis has ever completed, a review can't be created — run and complete one first.
2. Identity classes: human, machine, service-linked, unknown
Once a review is created, every IAM principal is automatically assigned an identity class.
| Class | Meaning |
|---|---|
human | Signs in through the console or an identity provider (SAML/OIDC), or a role a person or account can assume |
machine | A role only a service may assume, or a user with access keys and no console sign-in |
service_linked | A service-linked role owned and managed by the cloud provider itself |
unknown | None of the above, or not enough evidence to tell (includes groups) |
Classification gives top priority to a tag you set explicitly (IdentityType or similar) — a label you assigned by hand outranks anything inferred. After that it follows observable facts, in order: trust policy, console sign-in, and access-key possession. Opening any item's detail shows the basis for that classification — which rule fired and what values it read — so a reviewer who disagrees can see exactly why the system said what it said, and override it.
3. Usage evidence: was this credential actually used
Each item shows the last time a password was used, each access key's creation and last-use dates, whether MFA is enabled, and — for a role — when it was last assumed. Whether it's unused comes back as one of three values.
- Yes (unused) — every credential that could be read was last used before the threshold, or was never used at all.
- No (in use) — at least one credential was used within the threshold.
- Cannot tell — one of: the asset inventory hasn't collected usage history for this principal yet; a lookup failed; listing the access keys failed (this is never read as "no keys" — treating a failed lookup as "no keys" risks flagging a key that's actually in daily use as unused); or it's a group (groups have no credentials of their own).
The absence of collected usage history is not evidence that a credential is safe. The review screen and PDF show "cannot tell" and "confirmed unused" as visibly different states, never the same one.
The threshold for "unused" follows your organization's risk criteria (90 days by default — see Risk Score Explained, section 4). Since this value isn't a requirement of any framework, both the on-screen basis and the report mark it accordingly.
4. Decisions
For each item, a reviewer picks one of:
- Keep — leave the access as it is.
- Revoke — this access should be removed.
- Reduce — this access should be narrowed.
- Exception — leave it for now, but an exception expiry date is required. An exception with no expiry is not saved.
Decisions can be made one item at a time, or in bulk across a selection. A reason can be attached to a decision, and follow-up can be marked as requested or done.
A decision and its follow-up are a record. Actually editing an IAM policy or revoking a credential happens in your own AWS account. To confirm a change actually took effect, create the next review and compare the two (see section 6).
5. Completing a review: signed, and frozen from that point
Once every item has a decision, run Complete. At that point:
- a report of the review — every item's decision and basis, the snapshot hash, who completed it, and when — is written to your own storage, and
- that report is signed.
Items on a completed review can no longer be edited. The signature covers the decisions as they stood at that moment; changing them afterward would leave the signature pointing at content that no longer matches. If a judgement needs to change, create a new review.
A completed review also gets its next due date (completion time plus the review's cadence, 90 days by default). You can set the cadence when creating the review.
6. Comparing two reviews (diff)
Comparing two reviews shows:
- principals that are new or gone
- principals whose decision changed (for example, if a principal marked "revoke" in the last review is still present, that's worth checking against what actually happened in AWS)
- principals whose classification changed
- whether any access path (confirmed or potential) newly appeared or was resolved
Use this to confirm whether what a previous review flagged was actually addressed.
7. Report, PDF, and verification
A completed review can always be checked through:
- Report (original) — exactly the content the signature covers.
- PDF — a document with tables by identity class, a decisions table, the exceptions list, follow-up status, and the signature information.
- Verify — checks three things independently: that the evidence snapshot is still readable from storage, that the report's hash matches, and that the signature is valid.
Someone signed in with auditor access can view all of these screens read-only. To receive this review's output bundled with the control report, data location, and audit history as a single signed package, see Evidence Package.