Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Organisational Control

A.5.16 — Identity Management

Updated on 4 min Reviewed by: Cenedril Editorial
A.5.16 ISO 27001ISO 27002BSI ORP.4

An IT administrator leaves the company on Friday. On Monday, their Active Directory account is still active, their VPN token works and their service accounts continue to run batch jobs with elevated privileges. A.5.16 addresses this gap: every identity needs a managed lifecycle from creation to deactivation.

Identity management is the foundation of access control. Without a reliable way to identify who — or what — is accessing a system, access rules become unenforceable.

What does the standard require?

  • Assign unique identities. Every person and system accessing organisational assets must have a unique identifier. This enables individual accountability and traceability.
  • Manage the full lifecycle. Identities must be created, modified and deactivated through a defined process. When an employee leaves or a system is decommissioned, the associated identity and all its access rights must be promptly removed.
  • Restrict shared identities. Shared accounts undermine accountability. They are permitted only when operationally unavoidable, and they must be documented and approved.
  • Maintain an identity register. The organisation must know which identities exist, who or what they belong to and what state they are in (active, suspended, deactivated).
  • Integrate with HR and asset management. Identity lifecycle events — joiners, movers, leavers — must be triggered by authoritative source data, typically from HR systems and asset inventories.

In practice

Integrate identity provisioning with HR. When HR records a new hire, the identity management system automatically creates the account with a baseline set of attributes (name, department, start date). When HR records a departure, the system triggers deactivation. This eliminates reliance on manual requests that are easily forgotten.

Maintain a central identity directory. Use a single authoritative directory (Active Directory, Azure AD, LDAP) as the source of truth. Satellite systems synchronise from it. Avoid managing identities independently in every application.

Define lifecycle states. At minimum: active, suspended, deactivated. Suspended accounts cover parental leave or sabbaticals where the person will return. Deactivated accounts are permanently retired but retained for a defined period for audit purposes before deletion.

Audit service accounts and API keys. Service accounts are frequently created during a project and then forgotten. Assign an owner to every service account, document its purpose and set an expiry or review date. API keys follow the same discipline.

Reconcile regularly. At least quarterly, compare the identity directory against HR data and active project lists. Flag identities that have no matching active person or system. Investigate and resolve discrepancies within a defined timeframe.

Typical audit evidence

Auditors typically expect the following evidence for A.5.16:

  • Identity management policy or procedure — defining lifecycle states and processes
  • Identity register — complete list of active, suspended and recently deactivated identities
  • Joiners-movers-leavers process — documented workflow linking HR events to identity actions
  • Deactivation records — evidence of timely deactivation upon departure
  • Shared account register — list of approved shared identities with justification
  • Reconciliation reports — periodic comparison of identity directory with HR and asset data

KPI

% of identities with complete lifecycle management (creation to deactivation)

This KPI measures how many identities follow the defined lifecycle process end to end. An identity without a creation request, without an assigned owner or without a deactivation upon departure is incomplete. Target: 100%.

Supplementary KPIs:

  • Average time between employee departure and account deactivation
  • Number of orphaned service accounts discovered per quarterly reconciliation
  • Percentage of shared accounts with documented justification and approval

BSI IT-Grundschutz

A.5.16 maps primarily to BSI’s identity and access management requirements:

  • ORP.4 (Identity and access management) — defines the organisational framework for managing identities, including unique identification, lifecycle management and regular reviews.
  • OPS.1.1.2.A4 (Termination of system administrator accounts) — specifically addresses timely deactivation of privileged accounts when administrators leave or change roles.

A.5.16 provides the identity foundation for the access control cluster:

Sources

Frequently asked questions

Are shared accounts ever acceptable?

ISO 27002 allows shared identities only when there is a justified business or operational need and individual accountability cannot be achieved otherwise. Every shared account must be documented, approved and subject to compensating controls such as enhanced logging.

Does A.5.16 also cover service accounts and system identities?

Yes. The control applies to all entities that access the organisation's information assets -- human users, service accounts, API keys and machine identities. Each must have a unique identifier and a defined lifecycle.

How quickly must access be revoked when someone leaves?

The standard does not prescribe a fixed timeframe. Industry practice targets same-day deactivation. For high-privilege accounts, immediate revocation upon notification of departure is the expectation.