ISO 27001 A.5.16: Identity Management

ISO 27001 A.5.16 requires an organization to manage the full life cycle of identities, for both people and non-human accounts, from creation through use to retirement, with each identity uniquely attributable to a single actor. It is an Organizational control (A.5), and the action teams get flagged on most is attribution: shared logins and service accounts that nobody can tie to a named person or a documented owner when an auditor asks.

What is ISO 27001 A.5.16?

ISO 27001 A.5.16 Identity management governs the full life cycle of the identities used to access information and systems. As described in ISO/IEC 27001:2022, Annex A, the control covers how identities for people and for non-human entities are created, managed, and removed, so that access can be tied to a known and unique identity throughout its life.

A.5.16 covers the identity itself rather than the credential it authenticates with or the permissions it holds. An identity is the record that represents an actor: a named employee, a contractor, a service account, or a workload. The control asks the organization to give each actor a unique identity, keep it tied to an authoritative source such as HR or the identity provider, and manage it through the joiner-mover-leaver stages so that no identity outlives the person or service it stands for.

How do you implement A.5.16?

Implement A.5.16 by treating every identity as a record with an owner and a life cycle, created from an authoritative source and retired the moment the actor behind it leaves or changes. The sequence a team runs:

1. Issue one unique identity per person, never shared. Each individual gets a single identity that resolves to them alone. Shared logins are a common way attribution breaks, because no record can say which person acted on a given system at a given time.
2. Tie every identity to an authoritative source. The identity provider or HR system is the system of record for people. An identity exists because a person exists in that source, and it is created, changed, and disabled in step with the source rather than by hand on each system.
3. Govern the joiner-mover-leaver life cycle. A joiner triggers provisioning against the person's role. A mover triggers a change so entitlements follow the new role and stale ones are removed. A leaver triggers prompt deprovisioning so the identity is disabled the day access should end.
4. Manage non-human and service identities as first-class records. Service accounts, workload identities, API clients, and machine identities each get a named human owner, a documented purpose, and a place in the same life cycle. An orphaned service account with no owner is the machine equivalent of a shared login.
5. Deprovision promptly on termination or role change. Disable identities on the effective date rather than on a monthly catch-up. The gap between a leaver's last day and the identity being disabled is the window an auditor and an attacker both look for.
6. Reconcile identities against the source periodically. On a defined cadence, compare the active identities in each system against the authoritative source. Every identity should map to a current person or an owned service; anything that does not is investigated and removed.

In cloud environments

Cloud environments run A.5.16 through the identity provider as the source of truth, with provisioning automated end to end:

• IdP as the system of record. Okta, Entra ID, or Google Workspace holds the authoritative identity, and downstream applications trust it through SSO, so one identity governs access everywhere.
• SCIM provisioning and deprovisioning. SCIM pushes create, update, and disable events from the IdP to connected applications, so a joiner is provisioned and a leaver is deprovisioned across every app from a single action. Automating that deprovisioning evidence trail is an example of GRC engineering.
• HR-driven lifecycle triggers. The HR system feeds the IdP, so a termination or role change recorded by HR flows automatically into provisioning changes rather than waiting on a manual request.
• Service accounts and workload identities. Cloud workloads use managed identities, IAM roles, or federated workload identity instead of long-lived static keys, and each service identity carries a tagged owner and purpose for reconciliation.

On-prem / self-hosted

On-prem environments run A.5.16 through directory lifecycle management, with the same authoritative-source discipline applied to Active Directory. The SOC 2 access control on-prem guide covers the full implementation; the shape is:

• Active Directory as the identity lifecycle hub. AD accounts are created, moved between organizational units, and disabled as the person's status changes, and group membership carries the role.
• HR-triggered provisioning and deprovisioning. A documented joiner-mover-leaver process ties AD account actions to HR events, so provisioning and disabling happen against a recorded trigger rather than ad hoc.
• A maintained service account inventory. On-prem service accounts often sprawl across scheduled tasks, application pools, and integrations, so a named inventory records each account's owner, purpose, and review date.
• Prompt disable over delete. Leaver accounts are disabled immediately on the effective date and retained for a defined period for forensics before deletion, keeping the audit trail intact.

Cloud vs on-prem at a glance

What evidence demonstrates A.5.16?

Evidence for A.5.16 is the record that identities are unique, sourced from an authority, and moved through the life cycle on time, including the non-human ones.

How does A.5.16 map to SOC 2?

A.5.16 is a Full overlap with SOC 2 CC6.2, the criterion covering how new internal and external identities are registered, authorized, and provisioned before access is granted, and deprovisioned when no longer required.

Organizations running both frameworks can reuse identity lifecycle evidence across A.5.16 and CC6.2 with little adaptation. The SOC 2 to ISO 27001 control mapping covers the full crosswalk, and the SOC 2 to ISO 27001 reuse guide covers how much of an existing SOC 2 program transfers.

Related controls

A.5.16 manages the identities that the rest of the access controls act on. A.5.15 Access control sets the policy those identities are governed by, and A.5.18 Access rights governs the entitlements each identity holds and the provisioning, review, and removal of those rights. A.5.17 Authentication information covers the credentials an identity authenticates with, and A.8.5 Secure authentication covers the technical authentication mechanism itself. A.5.16 is the identity; A.5.17 and A.8.5 are how it proves itself, and A.5.18 is what it can reach. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001:2022 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you want a second set of eyes on how identity management is designed and evidenced as part of an effective security program, Truvo runs scoping calls.

Frequently Asked Questions

What is ISO 27001 A.5.16?

ISO 27001 A.5.16 is the Annex A control titled Identity management, in the Organizational theme of ISO/IEC 27001:2022. It requires an organization to manage the full life cycle of identities for people and non-human entities, from creation through use to retirement, so that each identity is unique and attributable to a single actor and stays tied to an authoritative source such as HR or the identity provider.

What evidence satisfies A.5.16?

A.5.16 evidence includes an identity inventory or user list showing each identity's status and owner, provisioning and deprovisioning records tied to authorized triggers, termination-to-deprovision timing records showing leaver identities are disabled on time, and a service account inventory naming an owner and purpose for each non-human identity.

What is the joiner-mover-leaver lifecycle?

Joiner-mover-leaver is the identity life cycle A.5.16 governs. A joiner is a new person or service that triggers provisioning of a unique identity against a role. A mover is a role or status change that triggers updating entitlements and removing stale ones. A leaver is a termination or retirement that triggers prompt deprovisioning so the identity is disabled the day access should end.

What is the difference between A.5.16 and A.5.18?

A.5.16 manages the identity itself: creating one unique identity per actor, tying it to an authoritative source, and moving it through the joiner-mover-leaver life cycle. A.5.18 Access rights manages the entitlements that identity holds: provisioning, reviewing, and revoking what it can reach. A.5.16 answers who the actor is; A.5.18 answers what that actor is allowed to do.

How does A.5.16 handle service and non-human identities?

A.5.16 treats service accounts, workload identities, API clients, and machine identities as first-class records with the same life cycle as people. Each gets a named human owner, a documented purpose, and a review date. Cloud environments typically use managed identities and workload federation over static keys; on-prem environments maintain a service account inventory. Both reconcile the active list periodically to find orphaned accounts.

How does A.5.16 map to SOC 2?

A.5.16 has Full overlap with SOC 2 CC6.2, the criterion covering how identities are registered, authorized, and provisioned before access is granted and deprovisioned when no longer required. Identity lifecycle evidence, including the identity inventory, provisioning and deprovisioning records, and service account inventory, is reusable across both frameworks with little adaptation.