How to Conduct an IAM Access Review: A Practical Checklist

Begin with the highest-risk identities: those with administrative or elevated privileges. In AWS, this includes identities with the AdministratorAccess managed policy, identities with iam:* permissions, and those with sts:AssumeRole permissions to administrative roles. In Azure, examine Global Administrators, Subscription Owners, and custom roles with write permissions on role assignments. In GCP, focus on Organization Administrators, Project Owners, and identities with roles/iam.admin.

For each privileged identity, validate three things. First, is the privilege still required for the individual's current job function? People change roles, teams reorganize, and projects end, but their elevated permissions often persist. Second, is the privilege appropriately scoped? An administrator who only manages networking resources does not need full administrative access. Third, is the privilege protected with appropriate controls — multi-factor authentication, conditional access policies, and session time limits? Privileged accounts without MFA should be flagged as critical findings.

Document the business justification for each privileged identity. If the owner or their manager cannot articulate why the access is needed, that is a strong indicator that it should be revoked. Maintain a privileged access registry that is reviewed quarterly and updated whenever personnel changes occur. The goal is to keep the population of administrative accounts as small as possible and to ensure every one is individually justified.

Service accounts, machine roles, and workload identities are often the most over-permissioned and least-reviewed identities in a cloud environment. They are created by developers during application deployment, configured with broad permissions to avoid trial-and-error debugging, and then forgotten. Unlike human accounts, service accounts do not have owners who leave the organization — they simply persist, sometimes long after the application they support has been decommissioned.

For each service account or machine identity, verify the following: Is there an assigned owner — a specific team or individual responsible for the account? Is the account actively in use, as evidenced by recent API activity in cloud provider audit logs? Are its permissions aligned with the application's actual requirements, or does it carry broad administrative access? Are long-lived credentials (access keys, service account keys) rotated regularly, or better yet, replaced with short-lived federation-based credentials?

Pay particular attention to service accounts that have not authenticated in 90 or more days. These dormant accounts represent pure risk — they provide an attack surface with no corresponding business value. Disable them immediately and schedule deletion after a validation period. For active service accounts, compare their granted permissions against their actual API usage over the past 90 days and flag any with significant unused permission gaps for scoping.

Separation of duties (SoD) is the principle that no single identity should hold permissions that would allow it to both initiate and approve a critical action. In cloud environments, common SoD violations include identities that can both deploy infrastructure and modify IAM policies, identities that can both access production data and manage encryption keys, and identities that can both create billing resources and approve budgets. These combinations create insider risk — whether from malicious intent or compromised credentials.

Map your critical processes and identify where SoD controls should apply. For each identified SoD boundary, verify that no single identity (human or service) can bypass it. Cloud providers offer tools to support this analysis: AWS Organizations service control policies can enforce SoD boundaries at the organizational level, Azure management groups can restrict role combinations, and GCP organization policies can limit permission grants.

Simultaneously, identify orphaned accounts — identities that belong to individuals who have left the organization, contractors whose engagements have ended, or vendor accounts for integrations that have been discontinued. Orphaned accounts are particularly dangerous because they have legitimate credentials but no one monitoring their usage. Cross-reference your cloud IAM user list against your HR system or identity provider to identify discrepancies. Any cloud identity without a corresponding active employee or contractor record should be immediately investigated and disabled.

Modern cloud architectures often involve multiple accounts or projects with trust relationships between them. In AWS, cross-account IAM roles allow identities in one account to assume roles in another. In GCP, service accounts can be granted permissions across projects. In Azure, guest users and cross-tenant access policies enable inter-organizational access. Each of these trust relationships is a potential lateral movement path for an attacker who compromises a single account.

Review every cross-account trust relationship and validate its ongoing business necessity. For each trust, document which identities in the source account can access the target account, what permissions they obtain in the target account, and whether the trust includes external principals such as third-party vendor accounts or partner organizations. External trusts deserve the highest scrutiny because they extend your security boundary to encompass another organization's identity management practices.

Verify that cross-account roles use external ID conditions (in AWS) or equivalent safeguards to prevent confused deputy attacks. Ensure that cross-account access is logged and monitored in both the source and target accounts. For third-party vendor access specifically, confirm that access is time-bounded, scoped to the minimum necessary permissions, and subject to regular reauthorization by the business owner who sponsors the relationship.