Auditing ISO 27001 Annex A 5.16 Identity Management involves rigorous verification of the full lifecycle of digital identities. This process validates the Primary Implementation Requirement of ensuring every user has a unique, verifiable identity from onboarding to de-provisioning. The Business Benefit significantly reduces the risk of unauthorized access and insider threats by enforcing accountability and the principle of least privilege.
Table of contents
- 1. Identity Management Policy and Procedure Formalisation Verified
- 2. Unique User Identifier Assignment Confirmed
- 3. Identity Verification Standards for Joiners Validated
- 4. Identity Modification Trail during Role Changes Verified
- 5. Identity Revocation Timeliness for Leavers Confirmed
- 6. Identification of External/Third-Party Identities Verified
- 7. Dormant and Inactive Identity Cleanup Execution Evidenced
- 8. Segregation of Duties in Identity Creation Validated
- 9. Privilege Attribute Assignment Integrity Confirmed
- 10. Identity Authentication Strength Alignment Verified
1. Identity Management Policy and Procedure Formalisation Verified
Verification Criteria: A documented policy exists that defines the rules for the full lifecycle of digital identities, including creation, modification, and deletion.
Required Evidence: Approved Identity Management Policy or integrated Access Control Policy with specific “Identity Lifecycle” sections.
Pass/Fail Test: If the organisation cannot produce a formal procedure defining how unique identities are assigned and verified, mark as Non-Compliant.
2. Unique User Identifier Assignment Confirmed
Verification Criteria: Every internal and external user is assigned a unique identifier (UID) that is never shared or reused by another individual.
Required Evidence: Export from the primary Identity Provider (e.g., Entra ID, Okta, LDAP) showing unique UIDs and lack of generic/shared naming conventions.
Pass/Fail Test: If active accounts are found with generic names (e.g., “sales_team”, “temp_staff”) used by multiple people, mark as Non-Compliant.
3. Identity Verification Standards for Joiners Validated
Verification Criteria: A formal process exists to verify the identity of an individual before an account is provisioned in the corporate environment.
Required Evidence: HR onboarding records or IT tickets showing that government-issued ID or equivalent background checks were confirmed prior to UID creation.
Pass/Fail Test: If accounts are provisioned based solely on a manager’s request without a validated HR link or ID verification step, mark as Non-Compliant.
4. Identity Modification Trail during Role Changes Verified
Verification Criteria: Changes to a user’s identity attributes (e.g., department, role, name) are recorded and triggered by a formal “Mover” process.
Required Evidence: Audit logs from the IAM system or ticketing system showing the transition of a user from one department/role to another.
Pass/Fail Test: If a user’s role has changed but their identity attributes in the IAM system still reflect an old department or job function, mark as Non-Compliant.
5. Identity Revocation Timeliness for Leavers Confirmed
Verification Criteria: Digital identities are disabled or deleted immediately upon termination of employment or contract.
Required Evidence: Cross-reference of the last 10 leavers’ HR termination dates against the account “Disabled” timestamp in the Identity Provider.
Pass/Fail Test: If any identity remains “Active” or “Enabled” more than 24 hours after the individual’s formal departure, mark as Non-Compliant.
6. Identification of External/Third-Party Identities Verified
Verification Criteria: Identities belonging to contractors, vendors, or partners are clearly distinguishable from internal employee identities.
Required Evidence: IAM system report showing specific tags, naming prefixes, or distinct Organisational Units (OUs) for external identities.
Pass/Fail Test: If external consultants are provisioned as “Standard Employees” with no metadata identifying them as third parties, mark as Non-Compliant.
7. Dormant and Inactive Identity Cleanup Execution Evidenced
Verification Criteria: Identities that have not been used for a predefined period (e.g., 90 days) are automatically or manually identified and disabled.
Required Evidence: List of disabled accounts with “Last Logon” timestamps exceeding the policy threshold or automated cleanup script logs.
Pass/Fail Test: If the IAM system contains enabled accounts that have not logged in for over 180 days without a documented business exception, mark as Non-Compliant.
8. Segregation of Duties in Identity Creation Validated
Verification Criteria: The process ensures that the person who requests an identity is not the same person who approves and creates it.
Required Evidence: Workflow audit logs showing a “Requestor” (e.g., Hiring Manager) and a “Creator” (e.g., IT Admin) as distinct individuals.
Pass/Fail Test: If a single administrator can create an identity and grant it permissions without a secondary approval or HR trigger, mark as Non-Compliant.
9. Privilege Attribute Assignment Integrity Confirmed
Verification Criteria: Identity attributes (e.g., Group Membership, Security Clearance) are assigned based on the principle of least privilege.
Required Evidence: Review of “Domain Admin” or “Global Admin” groups to ensure only authorised, unique identities are present.
Pass/Fail Test: If an identity possesses “Super User” attributes that are not required for their documented job function, mark as Non-Compliant.
10. Identity Authentication Strength Alignment Verified
Verification Criteria: The level of identity verification and authentication required is proportional to the risks associated with the identity’s access level.
Required Evidence: Conditional Access Policy screenshots showing higher authentication requirements (e.g., FIDO2 keys) for administrative identities.
Pass/Fail Test: If high-privileged identities (e.g., Cloud Admins) use the same single-factor authentication as standard users, mark as Non-Compliant.
| Control Requirement | The ‘Checkbox Compliance’ Trap | The Reality Check |
|---|---|---|
| Unique Identification | GRC tool checks if the “User” field is populated in an asset list. | The auditor must verify the Identity Provider to ensure UIDs are not shared across physical shifts or roles. |
| De-provisioning | Tool identifies that a “Leaver Process” document exists in a folder. | Verify the *delta* between HR leaver logs and Active Directory. GRC tools often miss accounts that HR forgot to flag. |
| Dormant Accounts | Platform reports a “High Score” because it sees an MFA policy. | Inspect the “Last Login” date for every account. MFA is useless on an enabled account that should have been deleted a year ago. |
| Contractor Management | Tool assumes all accounts in the system are employees. | Demand a list of current contractors; cross-check to see if they are clearly labelled and have expiry dates on their identities. |
| Identity Verification | Tool records that an account was created via an automated workflow. | Verify the *source* of the workflow. If it’s a manual ticket, check for the attached ID verification or HR reference. |
| Role Changes (Movers) | GRC platform ignores the “Mover” lifecycle entirely. | Check for “Permission Creep.” Verify if a user who moved from Finance to Sales still has Finance group attributes. |
| Privileged UIDs | Tool verifies that the “Admin” account is separate from the “User” account. | Check if the admin account is named genericly (e.g., “IT_Admin”). Every admin action must be tied to a *unique* identifiable person. |

