Identity Management - ISO 27001 Annex A Control

ISO 27001 Annex A 5.16

Every action in a system should trace back to a known identity.

ISO 27001 Annex A 5.16 - Identity Management

Every system access starts with an identity. The control covers the lifecycle of those identities - how they are created, used, disabled and ultimately deleted. The principle is that each identity is uniquely associated with the entity it represents, whether that is an individual person, a service account or a device.

Shared identities create a problem. If three people use the same login, the audit trail cannot tell who did what. The control expects unique identities for individual humans wherever practical. Where shared accounts cannot be avoided - for example legacy systems that do not support per-user logins - they need to be documented as exceptions with compensating controls.

Non-human identities are increasingly important. Service accounts, API tokens, machine credentials and cloud service principals all need to be managed through the same lifecycle as user accounts. They get created with a defined purpose, assigned to a named owner, and removed when no longer needed.

The audit test for identity management is fairly mechanical. Pick a few identities at random from the directory and ask who they belong to, what they are for, and when they were last used. If the answers come back quickly the control is in place. If there are identities nobody can account for, that is the finding.

Practical Compliance Guidance

Identity management arrangements are described in the IMS1 manual at section 8.5 alongside the topic-specific Identity Management and Authentication Information Policy.

alphaZ document	How to use it
ISO 27001 Toolkit	The full alphaZ ISO 27001 toolkit covering manual, policies, procedures, registers and audit checklists.
PP-8-100 Information Security Policy Procedure	Contains the Identity Management and Authentication Information section, which sets out how identities are created, maintained and decommissioned.

Note - all the above files can be downloaded with an alphaZ subscription.

Frequently Asked Questions

Are shared accounts ever acceptable?

Where they cannot be avoided, yes - for example legacy applications that do not support per-user accounts, or generic accounts needed for system functions. Shared accounts should be documented as exceptions, restricted in their use, and have compensating controls such as session logging and dual oversight.

How should service and machine accounts be managed?

Like user accounts but with a named human owner. Each service account should have a defined purpose, an owner accountable for it, an associated review cycle, and a process for retirement when no longer needed. Credentials for service accounts need stronger protection because they are often more privileged than user accounts.

What is the difference between A.5.16 and A.5.17 Authentication information?

A.5.16 covers the identity itself - who or what it represents and the lifecycle of that identity. A.5.17 covers the authentication information used to verify the identity - passwords, tokens, keys and how they are managed. The two are tightly related but distinct.

Further Resources