Access review is painful when IAM naming is not standardized
Access reviews become harder when IAM users, roles, groups, policies, and permission sets are named without a clear convention.
Problem
Access review takes too long because IAM identities and roles are hard to understand.
Why it happens
Role names, permission sets, users, groups, and policies are created without a consistent naming pattern or ownership model. Reviewers then have to infer purpose from attached permissions instead of understanding it from the identity itself.
Fix / Approach
Standardize IAM naming around environment, system, role, and access level. Make ownership and purpose visible from the name so reviewers can understand risk and intent quickly.
Command / Config
Example naming pattern:
text
<company>-<env>-<system>-<role>
<company>-prod-platform-admin
<company>-staging-app-readonly
<company>-audit-log-readonlyAccess review checklist:
- Who owns this role?
- What system does it access?
- Which environment does it affect?
- Is it admin, write, or read-only?
- Is it still needed?
When to use
- AWS IAM
- GCP IAM
- SSO permission sets
- Kubernetes RBAC
- Database access
- Compliance reviews
When not to use
- Very small personal labs
- One-off temporary accounts with no review expectation
Extra context
Naming is not a cosmetic issue here. It directly affects review speed, approval quality, and the ability to defend access decisions during audits.