Cloud access reviews: a checklist that ends in decisions, not spreadsheets

Once a quarter, someone exports a list of users and their roles, splits it by team, and emails each manager a spreadsheet with a column headed "Still needed? Y/N". Most rows come back "Y". Some do not come back at all. The spreadsheet is filed as audit evidence, and the access stays exactly as it was.

That is the typical cloud access review. It satisfies an auditor's checkbox and changes very little. This post covers why, and a checklist for a review that actually removes access that should not exist.

Why cloud access reviews are harder than they look

Access reviews were designed for applications with a handful of roles and a list of human users. Cloud accounts break that model in several ways:

• Most identities are not people. Service accounts, function execution roles, instance profiles, pod identities and managed identities often outnumber human users, and none of them has a manager to ask.
• Attached is not effective. What an identity can actually do depends on its policies, group memberships, permission boundaries, organisation-level guardrails and the roles it can assume. A reviewer looking at the attached policy names sees only part of it.
• Access crosses accounts. A role in one account may be assumable from another, or by an external party. That access does not appear in the target account's user list at all.
• Reviewers lack evidence. Asking "is this still needed?" without showing whether the access has been used invites a reflexive yes.
• Nothing tracks the outcome. A "no" in a spreadsheet does not remove anything. Someone has to turn it into a change, and that step is often lost.

What a good review needs to answer

For each identity in scope, the reviewer should be able to see:

1. Who or what is this identity, and who owns it?
2. What can it effectively do, after all policies and role chains are resolved?
3. What has it actually used recently?
4. Can it reach admin-level permissions, directly or through a chain of roles?
5. Can anyone outside this account or organisation use it?
6. Has it been active at all?

With those answers on the page, most decisions become obvious.

A checklist for cloud access reviews

Before the review: set scope and ownership

• Include every cloud account and subscription, not only production.
• Include non-human identities explicitly. They need an owning team, not a manager.
• Assign an owner to every identity. Identities with no identifiable owner are a finding in their own right.
• Define the usage window you will use as evidence, and confirm the activity logs that cover it are enabled.

Prioritise what gets reviewed first

You cannot review everything with the same care. Put these at the top:

• Identities that can reach admin without holding an admin role, often called shadow admins, usually through a chain of role assumptions or a permission such as the ability to pass a role to a service.
• External and cross-account access to privileged roles in production.
• Zombie identities: users, roles and keys with no recent activity at all.
• Privileged identities without MFA.
• Identities with a large gap between what they are granted and what they use.

During the review: give reviewers evidence

• Show effective permissions, not policy names.
• Show recent usage next to granted permissions, so the gap is visible.
• Show why the identity was flagged, if it was.
• Offer concrete outcomes rather than yes or no: keep, reduce to a suggested policy, remove, or defer with a reason.

Record decisions as states, not answers

Each identity should end the review in a clear state, for example:

• Reviewed: access confirmed as appropriate.
• Needs remediation: access should change, with a ticket or change attached.
• Deferred: a decision is postponed, with a reason and a date.
• Pending: not yet reviewed, and visible as such.

States make the review measurable. You can see what was decided, what is outstanding and what changed since last quarter.

After the review: close the loop

• Turn every "needs remediation" decision into a change in IAM, ideally a reduced policy based on observed usage rather than a manual edit.
• Remove zombie identities and stale keys, after confirming nothing depends on them.
• Re-check after the change, so the review evidence reflects what is actually in place.
• Keep the review record, with decisions and reasons, as audit evidence.

Between reviews: keep it continuous

• Alert on new privileged grants and new cross-account trust to production.
• Re-flag identities that become inactive.
• Shorten the cycle for the highest-risk identities rather than reviewing everything quarterly.

Common mistakes

• Reviewing humans only. Machine identities often hold the broadest standing access.
• Approving by default. Without usage evidence, reviewers say yes.
• Ignoring database grants. An identity with no cloud IAM path to production data can still hold a standing grant inside the database.
• Treating the review as the outcome. The outcome is reduced access. The review is how you get there.

How Onam approaches it

Onam's CIEM engine resolves effective permissions for users, roles and service accounts from the posture inventory, walking policies, group memberships, conditions, explicit denies and cross-account trust. On AWS, CloudTrail activity over the last 30 days is joined against granted permissions, which produces the used and unused actions per identity, a high-risk unused list and a 0–100 risk score; a suggested right-sized policy is in development, so today the replacement policy is built from the used actions. Machine identities such as Lambda execution roles, instance profiles, CI/CD roles over OIDC and EKS service accounts are classified and analysed alongside users. Unused-permission analysis, shadow-admin detection, the risk score and automatic access reviews run on AWS identities today.

For review, Onam lists shadow admins, zombie identities, stale keys, external principals that can assume privileged roles, and MFA coverage for privileged identities. Escalation paths are searched on the identity graph and cross-checked against Onam's cloud detection and response, so a path that has actually been used is separated from one that is only reachable. Database CIEM extends this to grants inside managed databases.

Access reviews in Onam are an attestation and remediation workflow: every identity carries a state (pending, needs remediation, reviewed or deferred), and the finding that triggered the review stays attached, so the reviewer can see why it was flagged.

Request a demo to run a review against your own accounts. For the background on CIEM itself, see CIEM vs IAM security.