1. Purpose
The Identity Review Checklist is used to periodically verify that identities within the organization remain valid, authorized, necessary, appropriately protected, and aligned with current roles and business requirements.
The review helps identify:
- Unknown identities
- Dormant accounts
- Unauthorized accounts
- Incorrect ownership
- Excessive access
- Privileged identities
- Expired contractor accounts
- Orphaned accounts
- Service accounts without owners
- Inactive identities
- Access inconsistencies
- Identity lifecycle failures
- Authentication weaknesses
Core Principle
Identify → Reconcile → Validate → Review → Correct → Verify → Record
2. Scope
The checklist may cover:
- Employee identities
- Contractor identities
- Consultant identities
- Temporary identities
- Third-party identities
- Privileged identities
- Service accounts
- Application identities
- API identities
- Emergency/break-glass identities
- Cloud identities
- SaaS identities
- Database identities
- VPN identities
- Source-code identities
- Customer-environment identities
Systems may include:
- Identity Provider/SSO
- SaaS applications
- AWS/Azure/GCP
- Servers
- Databases
- Source-code repositories
- CI/CD
- VPN
- Security tools
- Business applications
- Customer environments
3. Review Information
| Field | Details |
|---|---|
| Review ID | |
| Review Period | |
| Review Date | |
| Reviewer | |
| Department/System | |
| Identity Population | |
| Systems Reviewed | |
| Review Scope | |
| Previous Review Date | |
| Review Frequency | |
| Approver | |
| Report Reference | |
| Status | Open/In Progress/Completed |
4. Review Objectives
The reviewer should confirm that:
- Every important identity is known.
- Each identity has an appropriate owner.
- Each identity has a valid purpose.
- Active users are still authorized.
- Access is appropriate for the person’s current role.
- Privileged identities are justified.
- Contractor/third-party identities remain valid.
- Service accounts remain necessary.
- Dormant accounts are identified.
- Expired identities are disabled.
- Authentication controls remain appropriate.
- Access changes are reflected in systems.
- Leaver accounts have been removed.
- Exceptions are documented.
- Findings are corrected and verified.
5. Identity Population Reconciliation
Obtain the current identity population from relevant systems.
Compare the population against:
- Identity Register
- HR/People records
- Contractor records
- Supplier records
- Application user lists
- Cloud IAM
- SSO/Identity Provider
- SaaS platforms
- VPN
- Source-code repositories
- Database accounts
- Security platforms
Checklist
- Identity population obtained
- Identity Register available
- HR records reconciled
- Contractor records reconciled
- Third-party identities reconciled
- Cloud identities reconciled
- SaaS identities reconciled
- Service accounts reconciled
- Privileged identities reconciled
- Unknown identities identified
- Duplicate identities identified
6. Identity Ownership Review
For each identity, verify:
- Owner identified
- Manager/sponsor identified where applicable
- System owner identified
- Business purpose documented
- Identity type documented
- Organization/department current
- Role current
- Owner is still responsible
- Ownership changes recorded
Finding Example
Service account
svc-reportingexists in the production environment, but no current owner is recorded.
Action:
Assign an accountable owner and update the Identity/Service Account Register.
7. Employee Identity Review
For employee identities, verify:
- Employee still active
- Employee ID valid
- Department current
- Job role current
- Manager current
- Account required
- Access matches current role
- Privileged access remains justified
- Dormant account reviewed
- Recent role changes reflected
- Authentication controls active
8. Contractor Identity Review
For contractors, verify:
- Contractor still engaged
- Internal sponsor still valid
- Contract/SOW active
- Access still required
- End date recorded
- Expired access removed
- Access matches current project
- Privileged access remains justified
- Customer access remains authorized
- MFA enabled where required
Contractor accounts should not remain active simply because the account still works.
9. Third-Party Identity Review
For supplier/vendor identities:
- Supplier relationship remains active
- Business purpose remains valid
- Internal sponsor exists
- Contract remains valid
- NDA/security requirements remain applicable
- Access remains necessary
- Permissions remain appropriate
- Expiry date is appropriate
- Privileged access reviewed
- Access removal requirements understood
10. Privileged Identity Review
For privileged identities:
- Identity is listed in the Privileged Access Register
- Business justification exists
- Owner exists
- System is identified
- Privilege level is documented
- Access remains necessary
- Least privilege applied
- MFA enabled where supported
- Dedicated privileged identity used where appropriate
- Activity logging enabled where appropriate
- Monitoring appropriate
- Temporary privileges have expired
- Emergency identities reviewed
- Excess privileges identified
11. Service Account Review
For service/application identities:
- Account has a documented purpose
- Application/service still exists
- Owner assigned
- Technical custodian assigned
- Permissions remain necessary
- Privileges are appropriate
- Credential storage is appropriate
- Rotation requirements addressed
- Last-use information reviewed where available
- Monitoring appropriate
- Dormant accounts identified
- Retired service accounts removed
Refer to the Service Account Register for detailed review.
12. Dormant Account Review
Identify accounts with little or no activity.
Possible reasons include:
- Employee departure
- Contractor engagement ended
- Project completed
- Application no longer used
- Temporary access not removed
- Account created for testing
- Legacy account
- Service no longer operating
For each dormant identity:
Identify → Investigate → Validate → Disable/Retain → Record
Do not automatically delete an account without understanding its purpose and dependencies.
13. Orphaned Identity Review
An orphaned identity is an account that has no valid owner or responsible person.
Check for:
- Unknown user
- Former employee
- Former contractor
- Old vendor
- Old service account
- Legacy application
- Unowned cloud identity
- Unowned SaaS administrator
Required Action
Identify → Investigate → Assign Owner or Disable → Verify → Update Register
14. Joiner Review
Sample recently created identities and verify:
- HR/engagement notification exists
- Identity request exists
- Business role documented
- Access approved
- Account created correctly
- MFA configured
- Access matches approved request
- Identity Register updated
- Evidence retained
15. Mover Review
For employees/contractors who changed roles:
- Role change identified
- Existing access reviewed
- Old access removed where no longer required
- New access approved
- New access provisioned
- Privileged access reassessed
- SoD conflicts considered
- Identity Register updated
- Evidence retained
Important
A role change should not simply result in adding new permissions.
The previous access should also be reassessed.
16. Leaver Review
Sample recently departed employees/contractors and verify:
- Exit notification received
- Identity identified
- Account disabled
- Sessions terminated where applicable
- MFA/authentication credentials addressed
- SaaS access removed
- Cloud access removed
- VPN removed
- Source-code access removed
- Privileged access revoked
- Tokens/API keys addressed
- Physical access removed
- Assets returned
- Identity records updated
- Revocation verified
17. Authentication Review
Verify appropriate authentication controls.
- MFA enabled where required
- SSO used where appropriate
- Strong authentication configured
- Shared credentials identified
- Password policy applied where relevant
- Authentication exceptions documented
- Recovery methods controlled
- Privileged accounts protected
- Dormant accounts disabled where appropriate
Do not record actual passwords, recovery codes, API keys, or other secrets in the review.
18. Identity Against Access Review
Identity review should connect to access review.
For sampled identities, verify:
Identity → Role → Access → Business Need → Approval → Actual Permissions
Example:
Employee is Engineering Lead → requires repository administration → approved by system owner → actual permissions match approved role.
If actual permissions exceed the approved requirement, record a finding and corrective action.
19. Identity and Information Classification
Review whether identity access is appropriate for information classification.
For example:
| Information | Classification | Access |
|---|---|---|
| Public Website | Public | Broad |
| Internal Procedures | Internal | Employees |
| Customer Data | Confidential | Authorized Teams |
| Production Credentials | Restricted | Highly Limited |
Check:
- Sensitive information access is justified
- Restricted information access is limited
- Privileged access is appropriate
- Contractor access is appropriate
- Third-party access is appropriate
20. Cloud Identity Review
For AWS/Azure/GCP environments:
- Cloud identities reconciled
- IAM users reviewed
- IAM roles reviewed
- Federated identities reviewed
- Privileged roles reviewed
- Service/workload identities reviewed
- Dormant identities identified
- Excessive permissions identified
- MFA reviewed where applicable
- Root/emergency identities reviewed
- Logging enabled where appropriate
- Unknown identities investigated
For AWS, relevant evidence may include IAM/Identity Center configuration, CloudTrail records, role assignments, and applicable security monitoring.
21. SaaS Identity Review
For important SaaS applications:
- User list obtained
- Admin users identified
- Former users removed
- Contractor users reviewed
- External users reviewed
- Dormant accounts reviewed
- Privileged roles reviewed
- MFA reviewed
- SSO reviewed
- Application owner confirmed
- Access aligned with business role
High-risk SaaS applications should receive review appropriate to their importance and risk.
22. Privileged Role Review
Review administrative groups and roles.
Examples:
- Global Administrator
- AWS Administrator
- Database Administrator
- Security Administrator
- Repository Administrator
- CI/CD Administrator
- Billing Administrator
- Backup Administrator
For each:
- Members identified
- Business justification exists
- Owner exists
- Access remains required
- MFA/security controls active
- Temporary access expired
- Excess privileges removed
23. Service Identity Review
Check:
- Service account exists for a valid reason
- Application still uses it
- Owner exists
- Permissions are necessary
- Credentials are protected
- Rotation is addressed
- Activity is monitored where appropriate
- Account is not obsolete
- Register is current
24. Shared Account Review
Identify shared accounts.
For each shared account:
- Technical reason documented
- Business justification documented
- Individual accountability controls considered
- Authorized users documented
- Credentials protected
- Monitoring enabled where appropriate
- Access reviewed
- Alternative individual identities considered
Where practical, shared accounts should be replaced with individual identities.
25. Access Expiry Review
Check temporary identities and temporary privileges.
- Expiry date exists
- Expired accounts disabled
- Temporary privileged access removed
- Contractor end dates reflected
- Project-based access removed after project completion
- Emergency access returned to controlled state
26. Identity Register Accuracy
Compare actual system records with the Identity Register.
Check:
- Identity name
- Identity type
- Owner
- Department
- Role
- System
- Environment
- Privilege
- Start date
- Expiry
- Status
- Last review
Record discrepancies rather than silently changing records without evidence.
27. Review Findings
Findings may be categorized according to the organization’s internal methodology.
| Finding Type | Example |
|---|---|
| Conforming | Identity is valid and appropriately controlled |
| Observation | Minor documentation/data-quality issue |
| Improvement Opportunity | Control can be strengthened |
| Nonconformity | Required control/process not effectively implemented |
The organization’s audit methodology should define the formal classification criteria.
28. Identity Review Finding Register
| Finding ID | Identity | System | Finding | Risk | Action | Owner | Due Date | Status |
|---|---|---|---|---|---|---|---|---|
| IR-001 | Open | |||||||
| IR-002 | Open |
29. Corrective Action
For each finding:
Identify → Assess → Assign Owner → Correct → Verify → Close
Example:
Finding
Former contractor account remains active.
Action
Disable account and verify access removal across connected applications.
Evidence
- Account disabled
- SSO session revoked
- SaaS access removed
- Cloud access removed
- Verification record
30. Remediation Verification
The reviewer should verify that corrective actions actually worked.
Do not close a finding merely because someone states:
“Access has been removed.”
Where appropriate, obtain evidence such as:
- IAM screenshot/export
- SSO record
- Account status
- Access-control report
- Revocation record
- Application user list
- Cloud role assignment
- Audit log
31. Identity Review Summary
At the end of the review, summarize:
| Metric | Result |
|---|---|
| Total Identities Reviewed | |
| Employee Identities | |
| Contractor Identities | |
| Third-Party Identities | |
| Privileged Identities | |
| Service Accounts | |
| Dormant Identities | |
| Orphaned Identities | |
| Excessive Access Findings | |
| Expired Accounts | |
| Accounts Revoked | |
| Open Findings | |
| Closed Findings |
32. Review Conclusion
The conclusion should state factual results, for example:
The identity population within the defined review scope was reviewed against available HR, contractor, cloud, SaaS, and identity-management records. Identified discrepancies were recorded and assigned for corrective action. Privileged, contractor, service, dormant, and terminated identities were specifically reviewed.
The conclusion should not simply state that the environment is secure without supporting evidence.
33. Review Approval
| Role | Name | Signature/Approval | Date |
|---|---|---|---|
| Reviewer | |||
| System Owner | |||
| Security/ISMS Owner | |||
| Management/Approver |
34. Evidence Repository
Record the location of evidence used during the review.
Examples:
- Identity export
- HR report
- Contractor register
- IAM report
- SSO report
- SaaS user export
- Privileged Access Register
- Service Account Register
- Access Review Report
- JML records
- Revocation records
- Corrective-action records
Do not store credentials or authentication secrets in the evidence repository.
35. AWS SaaS Startup Example
A 40-person SaaS company performs a quarterly identity review.
Population
- 32 employees
- 4 contractors
- 2 third-party users
- 8 privileged identities
- 12 service identities
The reviewer compares:
HR → Identity Provider → AWS → Git Repository → SaaS Applications → Identity Register
During the review:
- One former contractor account is found active.
- One developer retains an old privileged role after moving to another team.
- One service account has no documented owner.
Actions
Former Contractor
→ Disable account
→ Revoke sessions
→ Verify SaaS/cloud access
Former Privileged Role
→ Remove unnecessary role
→ Verify permissions
→ Update access records
Unowned Service Account
→ Identify application
→ Assign owner
→ Update Service Account Register
→ Review permissions
The review is then closed with evidence for each corrective action.
36. Startup-Friendly Identity Review
A startup can begin with a simple quarterly review:
Step 1
Export users from the main Identity Provider.
Step 2
Compare against:
- HR
- Contractor list
- Identity Register
Step 3
Review:
- Admin accounts
- Contractors
- Dormant accounts
- Service accounts
- External users
Step 4
Check:
- MFA
- Role
- Access
- Owner
- Business need
- Expiry
Step 5
Correct discrepancies.
Step 6
Verify corrections.
Step 7
Save the completed checklist and evidence.
This creates a practical audit trail without requiring a large identity-governance platform.
37. Common Mistakes
Avoid:
- Reviewing only the employee list.
- Ignoring contractors.
- Ignoring service accounts.
- Ignoring cloud identities.
- Ignoring SaaS administrators.
- Reviewing only the Identity Register without reconciling actual systems.
- Checking whether an account exists but not whether its access is appropriate.
- Failing to review privileged roles.
- Failing to check former employees.
- Failing to check role changes.
- Closing findings without evidence.
- Keeping passwords or secrets in the checklist.
- Treating one completed review as permanent authorization.
38. Relationship with Other ISMS Documents
The Identity Review Checklist connects with:
- Identity Management Policy
- Identity Register
- User Account Management Procedure
- Contractor Account Procedure
- Contractor Offboarding Checklist
- Joiner-Mover-Leaver Procedure
- Access Control Policy
- Access Control Matrix
- Privileged Identity Management Procedure
- Privileged Access Register
- Service Account Register
- Access Review Report
- Access Revocation Checklist
- Asset Return Checklist
- Information Classification Policy
- Risk Register
- Incident Management Procedure
- Internal Audit Procedure
Control Chain
Identity
→ Owner
→ Role
→ Access
→ Business Need
→ Approval
→ Review
→ Correction
→ Verification
→ Evidence
39. ISO 27001 Connection
The checklist supports applicable ISO/IEC 27001 requirements and controls relating to:
- Identity management
- Authentication
- Access rights
- Access restriction
- Privileged access
- Segregation of duties
- Supplier/third-party access
- Logging and monitoring
- Information classification
- Personnel lifecycle
- Return/revocation of access
The exact controls applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability (SoA).
40. Quick Identity Review Checklist
Identity Population
- All identity sources identified
- Identity population obtained
- Identity Register reconciled
- Unknown identities investigated
- Duplicate identities investigated
Employees
- Current employees verified
- Role verified
- Access verified
- Role changes checked
- Leavers checked
Contractors/Third Parties
- Engagement verified
- Sponsor verified
- Contract checked
- Expiry checked
- Access reviewed
Privileged Identities
- Admin identities identified
- Justification checked
- MFA checked
- Privileges reviewed
- Emergency accounts reviewed
Service Accounts
- Purpose verified
- Owner verified
- Permissions reviewed
- Credentials/rotation reviewed
- Dormant accounts checked
Authentication
- MFA reviewed
- SSO reviewed
- Shared accounts reviewed
- Authentication exceptions reviewed
Closure
- Findings recorded
- Corrective actions assigned
- Remediation verified
- Identity Register updated
- Evidence retained
- Review approved
41. Final Audit Trail
For every identity reviewed, the organization should be able to answer:
Who is this identity?
→ Who owns it?
→ Why does it exist?
→ What systems can it access?
→ What permissions does it have?
→ Is the access still required?
→ Is the access appropriate for the current role?
→ Is authentication appropriately protected?
→ Has privileged access been reviewed?
→ Has the identity been affected by a Joiner/Mover/Leaver event?
→ If access was unnecessary, was it removed?
→ Was the correction verified?
→ Is evidence available?
Final Principle
An identity should not be considered valid simply because the account exists. It should have a known owner, a legitimate purpose, appropriate access, suitable authentication, and evidence that it is periodically reviewed and corrected when circumstances change.