Least Privilege IAM Review Checklist for AWS, Azure, and Google Cloud

Overview

A solid least privilege IAM review is not just a permissions inventory. It is a risk review of who can do what, where, and under which conditions. In cloud environments, that means looking beyond obvious administrator accounts and examining service identities, inherited roles, automation pipelines, temporary elevation paths, external identities, and inactive accounts that still retain access.

The goal is straightforward: every human user, workload, and integration should have only the access needed to perform an approved task, for only as long as needed, and only in the scope where that access is justified. That matters for security, but it also supports broader data protection compliance efforts. If a team cannot explain who can access production data, change network controls, read backups, or export logs, it will struggle with governance, incident response, and vendor risk assessment.

Use this checklist as a recurring audit resource. It works well for quarterly reviews, pre-audit preparation, post-incident hardening, and access reviews after reorganizations. If your environment spans multiple clouds, the most useful approach is to review the same control themes in each platform rather than treating every provider as a separate program.

Core review principles:

• Prefer role-based access over direct user grants.
• Reduce permanent administrative access.
• Separate production from non-production access.
• Review service accounts and machine identities as closely as human accounts.
• Watch inheritance, group nesting, and wildcard permissions.
• Document exceptions with an owner and expiration date.
• Map high-risk permissions to actual business need, not convenience.

If your team is also formalizing broader governance controls, this checklist pairs naturally with a Zero Trust Architecture Checklist for Cloud-Native Teams and a Privacy by Design Checklist for Product and Engineering Teams.

Checklist by scenario

Start with the scenario that matches your current need, then work through the cloud-specific checks under it. In practice, most teams will use more than one scenario in the same review cycle.

1. Baseline account and tenant review

Use this when you need a general cloud access review across AWS, Azure least privilege controls, and GCP IAM audit practices.

• List all active human identities, service accounts, managed identities, and federated identities.
• Identify privileged roles at every scope: organization, management group, subscription, project, folder, account, resource group, and resource level.
• Find direct permissions assigned to users instead of groups or roles.
• Flag dormant accounts, orphaned identities, and accounts with no recent business justification.
• Check whether break-glass accounts exist, are tightly controlled, and are excluded from daily use.
• Confirm MFA is enforced for privileged human accounts.
• Review whether contractors, vendors, and temporary staff still have access.

AWS IAM review checklist:

• Review IAM users and ask whether federation should replace long-lived user accounts.
• Audit IAM groups, attached managed policies, and inline policies for overly broad grants.
• Inspect roles trusted by external accounts and validate cross-account trust relationships.
• Review AWS Organizations delegated administrator roles and service control policy alignment.
• Check for wildcard actions, wildcard resources, and permissions such as iam:PassRole without strict limits.
• Identify unused roles and stale access keys.

Azure least privilege checklist:

• Review Microsoft Entra ID role assignments and Azure RBAC assignments separately.
• Check management group, subscription, resource group, and resource-level role inheritance.
• Identify broad roles such as Owner, Contributor, or User Access Administrator assigned too widely.
• Review guest users and business-to-business external identities for ongoing need.
• Inspect Privileged Identity Management settings if available, especially eligible versus active role assignments.
• Confirm app registrations and enterprise applications are not over-privileged.

GCP IAM audit checklist:

• Review organization, folder, project, and resource-level IAM bindings.
• Identify broad primitive roles and replace them where possible with predefined or custom roles.
• Review service accounts, service account keys, and who can impersonate them.
• Check Google Groups used in IAM bindings and verify group membership is still appropriate.
• Inspect external identities and workload identity configurations.
• Review inherited permissions that create unintended broad access at lower levels.

2. Privileged access review

This is the most important scenario in any least privilege IAM checklist. Focus on permissions that can change access, alter logging, disable security controls, create credentials, or reach sensitive data stores.

• List all roles that can create users, assign roles, reset credentials, or grant themselves broader access.
• Identify accounts that can alter audit settings, delete logs, disable alerts, or modify retention.
• Find identities that can access secrets, KMS keys, vaults, certificates, or backup systems.
• Review who can create or attach compute roles, run workloads with elevated identities, or modify CI/CD pipelines.
• Restrict database administrative access and direct storage access outside approved workflows.
• Prefer just-in-time elevation or approval-based workflows over standing privilege.

For privacy and governance teams, this review is especially useful because privileged access often overlaps with control over personal data, records of processing, and retention settings. Related governance work may also benefit from the Records of Processing Activities Guide: What Cloud and SaaS Teams Need to Track and the Data Retention Policy Checklist for SaaS Applications and Cloud Backups.

3. Service accounts, managed identities, and workload access

Many environments remove excess human admin rights but leave machine identities largely untouched. That is a common blind spot.

• Inventory service accounts, workload identities, managed identities, and automation principals.
• Check whether each identity is tied to a named application, owner, and documented purpose.
• Remove unused credentials, especially long-lived keys and secrets.
• Reduce access from broad environment-wide grants to resource-specific scopes.
• Review CI/CD pipelines for excessive deployment permissions.
• Confirm workloads do not share the same powerful identity across unrelated functions.
• Rotate secrets and move away from static credentials where platform-native options exist.

In AWS, pay close attention to role trust policies and the ability to pass roles to compute services. In Azure, review managed identities attached to automation, apps, and functions. In GCP, inspect service account key usage, impersonation rights, and whether service accounts have broad project-level roles that should be reduced.

4. Sensitive data and production boundary review

This scenario is useful when your main concern is data protection compliance or cloud security best practices around production systems.

• List identities that can read production databases, object storage, backup repositories, and analytics exports.
• Separate operational support access from direct data access wherever possible.
• Confirm developers do not have routine write or administrative access to production unless justified.
• Review support tools, jump hosts, and incident workflows that provide indirect data access.
• Check whether test and development environments inherit permissions intended only for production.
• Restrict access to encryption key administration from general platform administration.

If personal data crosses borders or is shared with cloud vendors and subprocessors, access governance should also align with your cross-border and vendor review practices. See Cross-Border Data Transfer Checklist for Cloud and SaaS Providers and Vendor Security Questionnaire Checklist: What to Ask Before Buying a SaaS Tool.

5. Joiner, mover, leaver and external access review

Least privilege weakens quickly when HR, engineering, and IT processes drift apart.

• Test whether new starters receive only baseline access rather than broad inherited access.
• Check whether role changes remove old permissions promptly.
• Verify offboarding disables cloud and identity provider access, tokens, keys, and shared credentials.
• Review emergency access granted during incidents and confirm it was removed afterward.
• Audit third-party, auditor, partner, and vendor accounts for expiry and owner approval.
• Ensure external support access is time-bound and scoped to a ticket or approved task.

6. Incident readiness and escalation path review

A good IAM audit also asks how an attacker, careless admin, or compromised workload could move from limited access to broad control.

• Identify permissions that allow role creation, role attachment, policy editing, or identity impersonation.
• Review who can disable logging, change network rules, or snapshot and export sensitive data.
• Check whether helpdesk, automation, or deployment accounts have hidden escalation paths.
• Test whether alerts exist for privileged role assignment, key creation, and policy changes.
• Verify incident responders have enough access to investigate without giving them broad standing admin rights.

This review connects directly to response planning. For follow-on work, see the Cloud Incident Response Plan Checklist for SaaS Teams and the Breach Notification Requirements Tracker: GDPR, US State Laws, and Key Global Rules.

What to double-check

After the first pass, slow down and verify the items most likely to create false confidence.

• Inherited access: Broad access often comes from parent scopes, nested groups, or legacy role assignment patterns rather than obvious direct grants.
• Non-human access: Service accounts, application registrations, and workload identities frequently outnumber human admins and may be less reviewed.
• Exception handling: Temporary access without an expiry date becomes permanent access.
• Unused does not always mean harmless: A dormant account with privilege is still a risk even if it has not been used recently.
• Logging coverage: You need enough audit visibility to confirm changes to identities, policies, group membership, and key material.
• Shared responsibility assumptions: The cloud provider secures the platform, but your team still controls who can access your workloads and data.
• Documentation quality: If an identity has no owner, no purpose, and no review history, treat it as a candidate for removal or containment.

It is also worth checking whether your internal reviews line up with external vendor expectations. If your organization depends heavily on SaaS tools, compare your internal access governance posture with how you assess third parties in SOC 2 vs ISO 27001 for SaaS Vendor Reviews: What Each Report Actually Tells You.

Common mistakes

Most IAM programs do not fail because teams lack good intentions. They fail because routine shortcuts become normal.

• Using admin roles as a default starting point. Convenience-based access expands quickly and is rarely rolled back.
• Reviewing only human users. Machine identities and automation often carry more privilege than employees.
• Ignoring cross-account or cross-project trust. Access may look narrow in one location while remaining broad through federation or trust relationships.
• Keeping direct user assignments. Direct grants are harder to review and easier to forget.
• Not separating production from development. Broad cross-environment access increases both operational and privacy risk.
• Leaving emergency access in place. Incident-driven changes need a cleanup step.
• Failing to tie permissions to a business function. If a permission cannot be explained in business terms, it is difficult to defend in an audit and hard to maintain safely.
• Overlooking privacy impact. Access to logs, backups, exports, and support tooling may expose personal data even when the primary application path appears controlled.

A helpful operating rule is to challenge every powerful permission with three questions: who needs this, for what exact task, and for how long? If the answer is vague, the permission is probably too broad.

When to revisit

Least privilege IAM review should be part of routine cloud operations, not an annual scramble. Revisit this checklist whenever underlying inputs change, especially before seasonal planning cycles and whenever tools or workflows shift.

Good triggers for a fresh review include:

• Quarterly or semiannual access certification cycles.
• Hiring waves, reorganizations, or contractor changes.
• Cloud migrations, acquisitions, or new environment builds.
• Deployment of new CI/CD tooling, identity providers, or secrets management workflows.
• Introduction of new SaaS integrations, analytics pipelines, or data-sharing processes.
• Audit preparation for security or privacy compliance work.
• Any security incident, near miss, or suspicious access event.

A practical recurring workflow:

1. Export current identities, role assignments, policies, and key service account details from each cloud.
2. Tag high-risk permissions and privileged identities first.
3. Meet service owners to validate actual need, not assumed need.
4. Remove stale access and convert direct grants into role- or group-based assignments.
5. Add approvals, expiry dates, and review owners for exceptions.
6. Document findings and carry unresolved items into the next review cycle with due dates.

If you want this process to stay manageable, keep one shared checklist, one exception register, and one cadence. The details of AWS, Azure, and GCP differ, but the operating discipline is the same: know your identities, reduce privilege, review changes, and treat cloud access as a living control surface. That is what makes a least privilege IAM checklist useful not just once, but every time your environment changes.