Cloud Privileged Access Review Checklist: Run Recurring IAM Certifications for AWS, Azure, and Google Cloud

Overview

A cloud privileged access review, sometimes called an IAM certification, is a documented decision about whether each elevated identity should retain, change, or lose access. It is more than exporting a list of users from a cloud console. A useful review connects identities to owners, business responsibilities, resources, authentication controls, recent activity, and approval records.

For many organizations, a quarterly access certification is a practical baseline. That interval should not replace event-driven reviews. Review access sooner after a role change, termination, security incident, major architecture change, merger, acquisition, or migration between identity providers. High-risk administrator roles and emergency access may warrant monthly review or continuous monitoring, depending on the sensitivity of the environment and the organization’s risk assessment.

Start by defining the review scope. Include production subscriptions, accounts, projects, management groups, organizations, identity directories, privileged groups, federated roles, break-glass accounts, workload identities, and third-party access. Document anything intentionally excluded and explain why. This scope record becomes part of your cloud compliance and audit evidence rather than an informal assumption.

Access reviews should support the organization’s wider cloud shared responsibility compliance checklist. The provider secures the underlying service, but your team remains responsible for identity configuration, authorization decisions, account lifecycle controls, and evidence that those controls operate as intended.

Checklist by scenario

1. Prepare the review

• Set a review period, scope, completion deadline, and accountable owner.
• Identify the person who can approve access and the person who will perform technical remediation. Separate these duties where practical.
• Export or query current identities, groups, roles, policies, permissions, authentication methods, and last-activity information.
• Record the source, extraction date, and method for each report so another reviewer can reproduce it.
• Map each privileged identity to a person, team, application, vendor, or documented business purpose.

2. Review AWS IAM access

• Review users, groups, roles, cross-account trust relationships, organization-level permissions, and federated access paths.
• Check administrator, security, billing, identity, key-management, and production deployment permissions separately; broad permissions can be hidden in attached or inherited policies.
• Look for unused credentials, long-lived access keys, inactive console access, and roles that can be assumed by unexpected accounts or external principals.
• Confirm that workload roles are tied to specific services or deployment workflows rather than shared human credentials.
• Require the reviewer to record retain, modify, revoke, or investigate for every elevated identity.

3. Review Azure privileged access

• Review directory roles, management group roles, subscription roles, resource-group assignments, privileged groups, and application registrations.
• Check both direct assignments and access inherited through groups. A user may appear low-risk in a subscription while receiving powerful permissions from a directory or management-group assignment.
• Confirm that temporary elevation, approval, authentication, and justification controls are used where the environment supports them.
• Review guest users, external collaborators, service principals, managed identities, and app permissions separately from employee accounts.
• Validate that inactive assignments and standing administrator privileges have a documented business need.

4. Review Google Cloud IAM access

• Review organization, folder, project, and resource-level bindings, including access inherited from higher levels.
• Examine primitive or broad roles, custom roles, service accounts, impersonation permissions, and external identity access.
• Check whether service accounts can be used by unintended principals or have credentials that are no longer required.
• Confirm that production access is assigned through controlled groups or approved identities rather than individual, undocumented grants.
• Review audit activity and recent use, but do not treat a lack of recent activity alone as proof that access is unnecessary; validate with the owner.

5. Review special scenarios

Dormant accounts: Identify identities with no recent activity, but investigate before removal. A dormant account may support a scheduled process, disaster recovery procedure, or infrequent operational task.

Emergency access: Confirm that break-glass accounts are limited, protected by strong authentication, monitored, and tested according to documented procedures. Review every use and record the reason, time, approver, and follow-up actions.

Service identities: Assign an accountable owner, purpose, environment, credential or token expiry expectations, and rotation method. Avoid approving a service identity simply because an application still exists; confirm that its permissions remain necessary.

Third parties: Verify the supplier, contract or engagement, named business owner, access boundary, expiration date, and monitoring method. Coordinate this work with your vendor risk assessment workflow when external access reaches sensitive systems.

What to double-check

Before closing a review, test the quality of the evidence rather than only the completeness of the spreadsheet.

• Identity ownership: Every account should have a named human or accountable team. “IT” or “engineering” may be too vague for remediation.
• Effective permissions: Review inherited, nested, cross-account, and policy-based access. Direct assignments are only part of the result.
• Privilege level: Confirm whether the identity can change IAM settings, disable logging, access secrets, alter security controls, read sensitive data, or deploy to production.
• Authentication: Check the required authentication method, federation status, privileged-session controls, and exception records.
• Approvals: Capture who approved access, when, for what purpose, and for which scope. Technical evidence without a decision record is difficult to defend during an audit.
• Remediation: Record the ticket, change reference, completion date, executor, and validation result for every revoked or modified permission.
• Retention: Store exports, decisions, exceptions, and remediation evidence in a controlled location with a retention period aligned to your policies and audit needs.

Use a consistent evidence structure: review metadata, identity inventory, permission snapshot, owner decision, exception rationale, remediation record, and closure sign-off. This makes the review easier to compare from one quarter to the next and supports an always-ready evidence library.

Common mistakes

• Reviewing only human users: Service accounts, application registrations, workload identities, and federated roles can carry substantial privilege.
• Using a single annual review for every identity: A fixed annual cycle may be insufficient for production administrators, emergency accounts, or high-risk third parties.
• Approving access in bulk without context: Group approval can be efficient, but it should include a clear scope and exceptions requiring individual review.
• Relying only on last-used data: Activity reports can be incomplete, delayed, or misleading. Combine technical activity with owner confirmation and system purpose.
• Deleting before documenting: Revoke unnecessary access, but retain the original state, decision, change record, and validation evidence.
• Ignoring inherited permissions: A role may look limited at the resource level while a parent scope or nested group grants broader authority.
• Leaving exceptions open-ended: Every exception should have a reason, compensating control, approver, owner, and expiry or review date.

These failures also weaken broader SOC 2, ISO 27001, and other cybersecurity compliance efforts because reviewers may be unable to show that access decisions were consistent, authorized, and followed through. For related control planning, see the SOC 2 readiness roadmap for startups.

When to revisit

Schedule the next routine certification before closing the current one. A quarterly cycle is a useful starting point for many teams, but adjust it based on risk, system sensitivity, workforce changes, and the volume of privileged access. Add event-driven reviews after administrator turnover, identity-provider changes, major cloud migrations, new production environments, acquisitions, material incidents, or changes to regulatory and contractual obligations.

Revisit this checklist before seasonal planning cycles and whenever provider workflows, identity tools, role models, or reporting capabilities change. Console labels and export methods can change even when the control objective does not. Refresh the technical steps, but preserve the core questions: who has access, what can they do, why is it needed, who approved it, and how can the organization prove the decision?

To run the next review, assign an owner and deadline, export current access from each cloud, classify identities by risk, send decisions to accountable owners, track every remediation item to closure, and archive the evidence package. Finish with a short retrospective: note recurring exceptions, unclear ownership, excessive standing privilege, and manual steps that should be improved before the next quarterly access certification.