1. Purpose
The Cloud Access Review Checklist provides a structured method for reviewing user, administrator, service-account, workload, application, API, and other identities that can access cloud environments.
The objective is to verify that:
- Access is authorized.
- Access remains necessary.
- Permissions are appropriate for the person’s role.
- Privileged access is properly controlled.
- MFA is enabled where required.
- Dormant and unnecessary accounts are removed or disabled.
- Excessive permissions are identified.
- Production access is appropriately restricted.
- Former employees and third parties no longer retain access.
- Service accounts and machine identities are properly controlled.
- Review results are documented and evidence is retained.
The review should be risk-based and proportionate to the sensitivity and criticality of the cloud environment.
2. Scope
This checklist may apply to:
- Cloud administrators
- Standard cloud users
- Developers
- DevOps engineers
- Security personnel
- Database administrators
- System administrators
- Contractors
- Suppliers
- Managed-service providers
- Temporary users
- Service accounts
- Workload identities
- Application identities
- API credentials
- Access keys
- Federated identities
- Break-glass accounts
- Root or equivalent accounts
Cloud environments may include:
- AWS
- Microsoft Azure
- Google Cloud
- Private cloud
- SaaS administration platforms
- Cloud-hosted databases
- Cloud security platforms
- Cloud monitoring platforms
- Cloud CI/CD platforms
3. Core Review Principle
The review should follow:
Identity → Business Need → Role → Permission → Resource → Environment → Risk → Approval → Evidence → Action
The objective is not simply to verify that an account exists.
The reviewer should determine:
Who has access, why they have it, what they can access, whether that access is still required, whether the level of privilege is appropriate, and whether evidence supports the decision.
4. Review Information
| Field | Details |
|---|---|
| Review ID | |
| Review Date | |
| Cloud Provider | AWS / Azure / GCP / Other |
| Cloud Account / Subscription / Project | |
| Environment | Production / Staging / Development / Test |
| Review Period | |
| Business Owner | |
| Technical Owner | |
| Security Reviewer | |
| Reviewer Department | |
| Review Frequency | |
| Previous Review Date | |
| Next Review Date | |
| Review Trigger | Periodic / Incident / Role Change / Other |
| Status | Open / Completed |
5. Cloud Environment Identification
Confirm:
- Cloud account/subscription/project is identified.
- Environment is identified.
- Business owner is identified.
- Technical owner is identified.
- Environment criticality is documented.
- Information processed is identified.
- Information classification is understood.
- Production status is confirmed.
- Customer or personal data exposure is considered.
- Relevant regulatory or contractual requirements are considered.
6. Access Population
Obtain the current access population from the cloud platform.
The population should include, where applicable:
- Human users
- Administrators
- Privileged users
- Developers
- Contractors
- Supplier accounts
- Federated users
- Service accounts
- Workload identities
- API credentials
- Access keys
- Application roles
- Break-glass accounts
- Root/equivalent accounts
The reviewer should establish that the population used for the review is complete and obtained from a reliable source.
7. User Account Review
For each user account, verify:
| Review Question | Result |
|---|---|
| Is the account assigned to an identifiable individual? | |
| Is the user currently employed/authorized? | |
| Is there a valid business need? | |
| Is the assigned role appropriate? | |
| Are permissions appropriate? | |
| Is MFA enabled where required? | |
| Is production access required? | |
| Is privileged access required? | |
| Is access excessive? | |
| Is the account active? | |
| Has the account been reviewed previously? | |
| Is continued access approved? |
Possible decisions:
- Retain
- Modify
- Remove
- Disable
- Further Investigation
- Risk Acceptance
8. Employment and Personnel Validation
Access should be compared with current personnel information where appropriate.
Check for:
- Employees who have left
- Employees who changed roles
- Employees transferred to another department
- Contractors whose engagement ended
- Suppliers whose contracts ended
- Temporary personnel whose authorization expired
- Users on extended leave where applicable
- Accounts with unknown ownership
Former personnel should not retain unnecessary cloud access.
9. Privileged Access Review
Privileged access requires enhanced review.
Review:
- Administrator roles
- Root/owner access
- Security administration
- IAM administration
- Billing administration where sensitive
- Database administration
- Network administration
- Production administration
- Key-management administration
- Logging/security-monitoring administration
For each privileged user verify:
- Business justification exists.
- Approval exists.
- MFA is enabled.
- Privileges are appropriate.
- Access is assigned to a named user.
- Privileges are not broader than required.
- Privileged activity is logged where appropriate.
- Access remains necessary.
- Periodic review is performed.
10. Least-Privilege Review
Review whether permissions exceed actual business requirements.
Look for:
- Administrator permissions without justification
- Wildcard permissions
- Broad resource access
- Unrestricted production access
- Unrestricted database access
- Excessive read/write permissions
- Unused permissions
- Permissions inherited through multiple roles
- Access to unrelated business environments
- Permissions that remain after role changes
Where excessive permissions are identified, the organization should assess whether they can be removed or reduced.
11. Production Access Review
Production access should receive enhanced scrutiny.
For each user with production access, determine:
- Why is production access required?
- What resources can the user access?
- Is the access permanent or temporary?
- Is privileged access required?
- Is MFA enabled?
- Is the access logged?
- Is there a separation-of-duties concern?
- Could the task be completed through a controlled deployment process instead?
- Is the access still required?
Production access should not be granted simply because an individual is part of the engineering team.
12. Development and Non-Production Access
Review access to:
- Development
- Testing
- Staging
- QA
- Sandbox
Confirm that non-production access does not unintentionally provide access to:
- Production systems
- Production databases
- Customer information
- Production secrets
- Production credentials
- Sensitive monitoring systems
Where production data is used in non-production environments, additional security and privacy controls should be considered.
13. Third-Party and Supplier Access
Review all external access.
Examples include:
- Cloud consultants
- Managed service providers
- Security vendors
- Developers
- Support providers
- VAPT providers
- Implementation partners
Verify:
- Supplier identity
- Business purpose
- Contractual relationship
- Named users
- Access scope
- MFA
- Privilege level
- Production access
- Expiration date
- Last activity
- Approval
- Monitoring
- Offboarding requirements
Supplier access should be removed when the business need ends.
14. Temporary and Emergency Access
Review temporary access for:
- Start date
- Expiry date
- Business justification
- Approval
- Scope
- Privilege
- Actual usage
- Closure
Emergency or break-glass access should be separately reviewed.
The organization should verify that emergency access was:
- Authorized
- Used only when necessary
- Logged
- Reviewed after use
- Revoked or returned to controlled status
15. MFA Review
Verify MFA requirements for relevant cloud identities.
Review:
- Administrators
- Privileged users
- Remote users
- External users
- Federated users
- Security administrators
- Break-glass accounts
Record exceptions and their risk treatment.
Example:
| User | Role | MFA | Required? | Exception | Action |
|---|---|---|---|---|---|
| User A | Administrator | Yes | Yes | No | Retain |
| User B | Developer | No | Yes | Approved | Remediate |
16. Service Account Review
Human-user review alone is insufficient.
Review service accounts and machine identities.
For each account determine:
- Owner
- Business purpose
- Application/service
- Permissions
- Resources accessed
- Authentication method
- Credential type
- Credential age
- Last activity
- Rotation requirement
- Expiration
- Environment
- Whether the account is still required
Unused service accounts should be disabled or removed.
17. Workload Identity Review
Where cloud-native workload identities are used, review:
- Application
- Workload
- Assigned role
- Permissions
- Resource scope
- Environment
- Owner
- Business purpose
- Trust relationship
- Cross-account access
- Cross-environment access
Workload identities should receive only the permissions required by the application.
18. Access Keys and API Credentials
Review long-lived credentials such as:
- Access keys
- API keys
- Service tokens
- Application credentials
- Integration credentials
Check:
- Owner
- Purpose
- Last use
- Age
- Permissions
- Storage location
- Rotation
- Expiration
- Exposure history
Long-lived credentials should be minimized where temporary or workload-based authentication is available.
Credentials should never be recorded directly in the review document.
19. Federated and SSO Access
Where cloud access is integrated with an identity provider, verify:
- SSO configuration
- Group-to-role mappings
- User lifecycle integration
- MFA
- Role assignments
- Privileged groups
- Deprovisioning
- Administrative access
- Authentication logs
A user removed from the organization’s identity system should not continue to have independent cloud credentials unless specifically authorized.
20. Role and Group Review
Review roles and groups for:
- Appropriate ownership
- Current membership
- Appropriate permissions
- Excessive privileges
- Nested groups
- Dormant groups
- Unused roles
- Privileged groups
- Cross-account trust
- Cross-environment access
Group-based access should be reviewed at both the group level and effective permission level.
21. Cross-Account / Cross-Project Access
Review relationships between cloud environments.
Examples:
- AWS account-to-account roles
- Azure subscription/resource-group access
- GCP project/service-account access
Determine:
- Source
- Destination
- Purpose
- Role
- Permissions
- Owner
- Business justification
- Duration
- Monitoring
- Whether the trust remains necessary
Unnecessary trust relationships should be removed.
22. External Identity Review
Review identities originating outside the organization.
Examples:
- Customer administrators
- Supplier users
- Consultants
- Contractors
- Temporary users
Confirm:
- Identity is known
- Business relationship exists
- Access is approved
- Scope is appropriate
- MFA is enabled where required
- Access is monitored
- Expiration is defined where appropriate
23. Root / Owner Account Review
Review the cloud provider’s root or equivalent account.
Verify:
- Account owner is identified.
- MFA is enabled.
- Credentials are securely controlled.
- Routine use is prohibited or minimized.
- Recovery mechanisms are controlled.
- Activity is monitored where available.
- Emergency use is documented.
24. Separation of Duties
Assess whether incompatible responsibilities have been combined.
Examples:
- Developer + production administrator
- Developer + security approval
- User + access approver
- Application developer + unrestricted database administrator
- Cloud administrator + independent audit role
Not every organization requires strict separation for every activity. The assessment should consider:
- Organization size
- Risk
- Privilege
- Compensating controls
- Business practicality
Where segregation is not practical, compensating controls should be considered.
25. Dormant Account Review
Identify accounts with:
- No recent activity
- No known owner
- Expired authorization
- Old access keys
- Unused roles
- Unused service accounts
- Former employees
- Former suppliers
Investigate before removal to avoid disrupting legitimate automated services.
26. Access Review Decision
Each reviewed identity should receive a documented decision.
| Decision | Meaning |
|---|---|
| Retain | Access remains appropriate |
| Modify | Access needs adjustment |
| Remove | Access is no longer required |
| Disable | Account should be disabled |
| Investigate | Additional information required |
| Risk Accepted | Exception is formally accepted |
27. Findings and Corrective Actions
Record issues such as:
| Finding | Risk | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|
| Developer has unnecessary admin role | High | Replace with application-specific role | Cloud Team | Open | |
| Former contractor account active | High | Disable account | IAM Team | Closed | |
| Service account has unused permissions | Medium | Reduce permissions | Engineering | In Progress |
Findings should be tracked to closure or formally risk accepted.
28. Access Review Evidence
Evidence may include:
- IAM user export
- Role assignments
- Group membership
- Permission reports
- MFA status
- SSO configuration
- Access-key reports
- Service-account inventory
- CloudTrail activity
- Azure activity logs
- GCP audit logs
- HR personnel confirmation
- Supplier access list
- Access approval records
- Previous review
- Remediation tickets
- Screenshots where appropriate
- Automated compliance reports
Evidence should show what was reviewed, by whom, when, and what decision was made.
29. AWS SaaS Example
Consider a SaaS startup running its platform on AWS.
The review population may include:
| Identity | Access | Review Focus |
|---|---|---|
| CTO | AWS Administrator | Business need + privileged access |
| DevOps Engineer | Production deployment role | Least privilege |
| Developer | Development account | Environment separation |
| Security Engineer | Security Hub/CloudTrail | Security administration |
| Support Engineer | Limited production support | Customer-data access |
| VAPT Provider | Temporary testing role | Scope + expiry |
| ECS Task Role | Application resources | Workload permissions |
| CI/CD Role | Deployment resources | Pipeline permissions |
| Break-glass Account | Emergency admin | Emergency controls |
For example, a developer may have:
AdministratorAccess
The review should not simply mark the access as valid because the person is a developer.
The reviewer should determine whether the developer actually needs administrator privileges.
A more appropriate configuration might be:
Developer → Application-specific role → Required development resources
while production deployment is performed through a controlled CI/CD role.
30. AWS Access Review Evidence
For an AWS environment, evidence may include:
- IAM users and roles
- IAM policy assignments
- IAM Identity Center assignments
- MFA status
- Access Analyzer findings
- Access-key information
- Role trust relationships
- CloudTrail activity
- Privileged-user list
- Production access list
- Service-account/workload-role inventory
- Access review sign-off
- Remediation tickets
Actual credentials, secret keys, or tokens must never be included in the review evidence.
31. Risk-Based Review Frequency
Review frequency should be defined according to risk.
An illustrative model:
| Access Type | Example Review |
|---|---|
| Root / Emergency | Frequent monitoring + periodic review |
| Privileged production | Frequent/periodic review |
| Standard production | Periodic review |
| Development | Periodic review |
| Third-party access | Periodic + event-driven |
| Temporary access | At expiry and during relevant reviews |
| Service accounts | Periodic review |
| High-risk applications | Enhanced review |
Additional reviews should be triggered by events such as:
- Employee termination
- Role change
- Supplier termination
- Security incident
- Privilege escalation
- Major architecture change
- New cloud environment
- New production application
- Significant access-policy change
These frequencies are examples; the organization should define its own requirements based on risk.
32. Access Review Register
A centralized register may contain:
| Field | Description |
|---|---|
| Review ID | Unique review identifier |
| Identity ID | User/service identity |
| Identity Type | Human/Service/Workload/etc. |
| User/Account | Identifier |
| Owner | Responsible person |
| Role | Assigned role |
| Environment | Prod/Dev/Test |
| Privileged | Yes/No |
| MFA | Yes/No/N/A |
| Production Access | Yes/No |
| Business Need | Reason |
| Permission Scope | Resources accessible |
| Last Activity | Where available |
| Previous Review | Date |
| Decision | Retain/Modify/Remove/etc. |
| Finding | Issue identified |
| Action | Corrective action |
| Action Owner | Responsible person |
| Due Date | Target date |
| Status | Open/Closed |
| Reviewer | Reviewer |
| Approval | Approver |
| Evidence | Evidence reference |
| Review Date | Date |
33. Review Approval
The completed review should be reviewed and approved by an appropriate authority.
Approval should demonstrate that:
- The access population was reviewed.
- Exceptions were considered.
- Findings were identified.
- Corrective actions were assigned.
- Significant risks were escalated.
- Continued access was authorized where appropriate.
For high-risk or privileged environments, security or management approval may be appropriate.
34. Exceptions and Risk Acceptance
Where access cannot immediately be reduced or removed, the exception should be:
- Documented
- Justified
- Risk assessed
- Assigned to an owner
- Approved
- Time-bound where practical
- Monitored
- Revisited during subsequent reviews
Example:
A senior engineer retains temporary elevated production access for a critical migration project. The access is approved for a defined period, monitored, and scheduled for removal after migration completion.
35. Common Mistakes
Avoid:
- Reviewing only human users
- Ignoring service accounts
- Ignoring workload identities
- Ignoring API keys
- Assuming SSO means access is automatically appropriate
- Treating all developers as administrators
- Ignoring supplier accounts
- Failing to review root accounts
- Reviewing permissions without checking business need
- Recording only “Access Valid” without evidence
- Failing to track remediation
- Allowing temporary access to become permanent
- Reviewing only IAM users while ignoring roles
- Ignoring cross-account trust relationships
- Keeping production access simply because it was previously approved
36. Internal Audit Checklist
An auditor may verify:
- Cloud environments are identified.
- Access populations are complete.
- User accounts have identifiable owners.
- Business need is established.
- Access is approved.
- Least privilege is considered.
- Privileged access receives enhanced review.
- MFA is implemented where required.
- Production access is reviewed.
- Third-party access is reviewed.
- Temporary access is controlled.
- Service accounts are reviewed.
- Workload identities are reviewed.
- API keys/access keys are reviewed.
- Root/equivalent accounts are controlled.
- Dormant accounts are investigated.
- Former personnel access is removed.
- Cross-account access is reviewed.
- Separation-of-duties risks are considered.
- Findings are tracked.
- Exceptions are documented.
- Review results are approved.
- Evidence is retained.
37. Relationship With Other Cloud Artifacts
The access review should feed information into:
Cloud Services Register
→ identifies the cloud service and owner.
Cloud Access Register
→ records authorized access.
Cloud Security Risk Assessment
→ evaluates access-related risks.
Cloud Secure Configuration Standard
→ defines configuration expectations.
Supplier Access Review
→ handles external supplier access.
Identity and Access Management Policy
→ defines overall access-management principles.
Joiner-Mover-Leaver Process
→ supports user lifecycle management.
Risk Register
→ records significant access-related risks.
Corrective Action Register
→ tracks remediation.
38. ISO/IEC 27001 Connection
The checklist supports the organization’s implementation of applicable ISO/IEC 27001:2022 controls relating to areas such as:
- Access control
- Identity management
- Authentication information
- Access rights
- Privileged access
- Information access restriction
- Secure authentication
- Supplier access
- Cloud services
- Logging and monitoring
- Segregation of duties
The organization should determine the exact applicability of controls through its:
- ISMS scope
- Risk assessment
- Risk treatment process
- Statement of Applicability
- Legal and contractual requirements
- Business requirements
This checklist is therefore an organizational control mechanism, not a universally mandatory ISO form.
39. Final Cloud Access Review Audit Trail
A complete review should demonstrate:
Cloud Environment Identified → Access Population Extracted → Identity Validated → Business Need Checked → Role Reviewed → Permissions Reviewed → Privileged Access Checked → MFA Checked → Production Access Checked → Service/Workload Identities Reviewed → Third-Party Access Reviewed → Exceptions Identified → Findings Recorded → Corrective Actions Assigned → Access Decision → Approval → Evidence Retained → Follow-Up Review
For a specific access issue:
Excessive Access Identified → Risk Assessed → Access Reduced/Removed → Validation → Evidence → Closure
40. Final Principle
A cloud access review should answer five fundamental questions:
Who has access?
Why do they have access?
What exactly can they access?
Is that level of access still necessary?
What evidence proves that the decision was reviewed and approved?
The objective is not simply to maintain an access list.
Effective cloud access governance means continuously aligning identity, business need, privilege, resource access, risk, and evidence.
Right identity + Right access + Right privilege + Right time + Right evidence = Controlled cloud access.