A.5.16
Identity management
Organizational controlsCheckpoints 6Evidence 6Cases 5
Control objective
This control governs the full life cycle of identities assigned to internal personnel, external parties, and non-human entities such as systems, services, and devices. Each subject must be uniquely identifiable so that actions can be traced back to an accountable owner and so that granted access rights map precisely to the real user of an identity. Weak identity management leads to orphaned accounts, privilege misuse, and an inability to attribute incidents, which this control aims to prevent across creation, change, deactivation, and deletion.
Key checkpoints
- Are identities assigned to personnel and non-human entities (service accounts, system accounts, devices) uniquely identifiable and linked to a real subject?
- Are procedures for creating, granting, changing, deactivating, and deleting identities documented, with approvals and request rationale recorded?
- Are shared identities limited to unavoidable business cases, subject to explicit approval, an assigned responsible owner, and usage logging?
- When status changes occur (leavers, transfers, contract termination), are the related identities deactivated or revoked in a timely manner?
- Are active identities periodically reconciled against actual employment/contract status and the access rights they hold?
- Are significant identity events (creation, privilege change, deactivation) recorded and traceable?
Implementation guidance
- Identify each person and non-human subject uniquely and link accounts to that subject. Where a person has separate everyday and administrative accounts, keep both attributable to the same accountable individual.
- Define roles, responsibilities, and approvers for each life-cycle stage (request, approval, issuance, change, suspension, removal) and standardize them as a workflow.
- Assign owners to service, system, and device identities and link their identifiers and credential references to the inventory. Keep raw API secrets and certificate private keys in an approved secrets store, outside the inventory.
- Prohibit shared identities by default; where unavoidable, document the rationale, approval, scope, and owner, and apply compensating controls to attribute individual actions.
- Integrate with the HR or contract-management system so that joiner, leaver, and role-change events are automatically reflected in identity status.
- Detect dormancy using activity appropriate to the identity type, confirm ownership and service dependencies, then deactivate unused accounts. Do not judge service accounts solely by interactive logins, and check audit-record retention before deletion.
- Periodically reconcile the active identity inventory against actual status and record the resolution of any discrepancies.
Evidence
- Identity/account management policy and procedures (including life-cycle stages and defined approvers)
- Identity inventory (a consolidated list of personnel accounts and non-human identities such as services, systems, and devices)
- Records of identity creation, change, deactivation, and deletion requests and approvals
- Approval forms and usage history for shared identities, plus owner-designation documents
- HR integration processing records (joiner/leaver/role change) and evidence of leaver account revocation
- Results of periodic reconciliation of active identities and records of cleaned-up unused accounts
Nonconformity examples
- Identities of leavers or terminated contractors are left active for long periods without deactivation.
- Multiple people share a single common identity without approval or logging, making individual actions untraceable.
- Service accounts and system accounts have no designated owner, creating management blind spots.
- No approval or request rationale is recorded when identities are created or changed.
- No reconciliation is performed between the active identity list and actual employment status, leaving numerous orphaned accounts.