ISO 27001 A.5.16: Manage the Identity Lifecycle

What A.5.16 requires in practice

Annex A control A.5.16 asks that the full life cycle of identities be managed. An identity is the representation of a person, device or service within the organisation’s systems, such as a user account. The life cycle runs from creation, through changes during its use, to disabling and removal.

The phrase full life cycle is the heart of the control. It is not enough to create accounts carefully if they are never revisited, or to remove leavers promptly while ignoring service accounts or contractors. Each identity should have a clear link to a real person or purpose, be unique enough that actions can be traced, and cease when no longer justified.

The control does not specify a directory product or a single method. The organisation decides how identities are issued, how shared or generic accounts are handled and how changes are triggered. What matters is that identities are known, accountable and kept in step with the people and systems they represent.

Establish a reliable starting point

Decide how a business need becomes a request for an identity. For an employee, an authorised employment record may trigger the process. For a contractor, a sponsor and defined engagement may be needed. For a service account, an accountable technical or business owner should explain the intended function and expected lifetime.

Verify the relevant entity before activating its identity. The strength and method of verification depend on the context and risk. A request arriving from a familiar display name is not automatically reliable. Record enough of the decision to make the creation traceable without collecting unnecessary personal information.

Within the appropriate context, avoid unexplained duplicate identities. Separate administrative and everyday accounts can serve a legitimate purpose, but their relationship should remain visible. Otherwise, removing the obvious account at departure may leave a second identity active and unowned.

Manage people and non-human identities differently where needed

People move between roles, clients and locations. Their identity records should reflect relevant changes so that downstream permissions can be reconsidered. Do not assume that the HR system knows about every contractor, temporary project member or customer-issued account.

Non-human identities need their own lifecycle triggers. An integration may outlive the employee who created it, and a retired application may leave an active service identity behind. Assign ownership that can survive personnel changes, define what retirement means and verify that disabling the identity will not unexpectedly interrupt a still-needed dependency.

Shared identities weaken direct attribution. Where an operational reason makes one necessary, approve and document the exception, restrict its use and establish suitable accountability. The guidance does not make every shared identity automatically forbidden, but convenience alone is a poor substitute for examining alternatives and risks.

Why identity management matters to the business

Most unauthorised access begins with an account that should not exist or should not have remained active. Orphaned accounts, shared logins and unmanaged service identities make it hard to know who did what and easy for misuse to go undetected.

Reliable identity management supports traceability, which matters in investigations, customer disputes and audits. It also reduces cost, because clear ownership and cleanup make access reviews faster and more accurate. Customers who trust a business with their data expect it to know who has accounts on its systems, and an organisation that cannot say invites doubt about its other controls.

How to implement A.5.16

Tie identity changes to events the business already recognises, such as joining, moving and leaving. Systems differ in how identities are created, so confirm the picture for each important system and not only the main directory. Keep a note of the reasons for each choice.

1. Identify all the kinds of identity in use, including staff, contractors, suppliers, administrators and system or service accounts.
2. Define how each kind is requested, approved, created and linked to a responsible person or owner.
3. Trigger changes from HR and contract events, so moves and departures update identities without relying on memory.
4. Decide when shared or generic accounts are permitted, and how individual actions remain traceable if they are.
5. Define how inactive accounts are detected and what happens to them.
6. Check periodically that every identity maps to a real person or purpose, and investigate any that does not.
7. Make sure removal of an identity also covers connected systems and external services.

Illustrative IT example: a service account without a service

Illustrative BPO example: a returning seasonal worker

A hypothetical BPO business re-engages a seasonal employee. A manager requests a new account because the previous identifier is difficult to find. The earlier account remains disabled in one system but active in a client-operated application.

The identity team reconciles the person’s previous relationship before establishing the new engagement. It confirms which identifiers should be reactivated, replaced or retired and notifies the client’s authorised administrator. The process prevents accidental duplication while preserving records needed for accountability. It does not assume that returning staff retain their former access entitlement.

Assess trust at external identity boundaries

A partner or external identity provider may verify users on your behalf. Establish what that identity represents, how changes and departures are communicated and whether the trust level suits the information involved. Federating a login does not transfer all responsibility for access decisions.

Test a lifecycle event across the boundary. If a partner removes a worker, determine when the identity can no longer reach your service and what happens to existing sessions or separately issued accounts. Connect this assessment with supplier relationship security where appropriate.

Evidence should connect identity events

Common nonconformities with A.5.16

Findings typically show gaps between what the business knows about its people and what systems contain. Assessors usually test identity management by comparing lists of people with lists of accounts.

• Accounts remain active for former employees or contractors after their departure.
• Shared or generic accounts are used for administration with no way to tell who acted.
• Service accounts have no identified owner, so nobody knows whether they are still needed.
• Identities are created from different routes with no common approval, and no one holds a complete picture.
• Accounts created in connected applications are not removed when the main account is closed.