ISO 27001 Control 5.16: Identity Management Requirements, Implementation, and Audit Guide

When an incident hits and your team can’t trace an action back to a specific person or system, the investigation stalls. Audit trails break. Accountability disappears. ISO 27001 control 5.16 exists to prevent exactly this — it’s the control that ensures every identity in your environment is created, verified, managed, and eventually removed with a clear chain of ownership.

What 5.16 Requires

ISO 27001 Annex A 5.16 requires organizations to manage the full lifecycle of every identity — human and non-human — that interacts with information systems. This means establishing processes for creating identities, verifying them, maintaining them through changes, and deprovisioning them when they’re no longer needed.

The core objective is unique identification. Every action on every system must trace back to a single, accountable identity. Shared accounts undermine this principle, so the control demands that organizations assign unique identifiers and maintain records that link each identity to its owner.

In practice, 5.16 covers several operational areas: registration processes that capture and verify identity information before granting access, approval workflows that separate the request from the authorization, periodic reviews that confirm identities still need their access, and timely deactivation when someone leaves or a service is retired.

The “so what” is straightforward. Without unique attribution, you cannot investigate incidents because you don’t know who did what. You cannot prove compliance because auditors need evidence that access decisions are traceable. And you cannot enforce least privilege because you have no reliable way to tie permissions back to an accountable owner.

Why 5.16 Matters

In a common pattern, a contractor finishes a six-month engagement and moves on. Their account stays active — no one triggers the offboarding process because the project manager assumed IT handled it, and IT assumed HR handled it. Three months later, an attacker compromises the dormant credentials through a credential-stuffing campaign using passwords from an unrelated breach. Because the account has legitimate access and no one is monitoring it, the attacker moves laterally for weeks before detection. When the security team investigates, they find activity tied to a contractor who hasn’t worked there in months and no way to determine whether the real contractor or the attacker performed specific actions.

This scenario isn’t hypothetical — it’s the most common identity-related failure pattern in organizations without mature lifecycle controls. The risks fall into three categories: unauthorized access through unmanaged identities, accountability failure when actions can’t be attributed to a specific person, and audit nonconformity when auditors find gaps in your identity lifecycle processes.

According to the SANS Institute, identity-based attacks accounted for 60% of cyber incidents in 2024 — a figure that reflects how frequently attackers target exactly these kinds of gaps. The dormant account, the shared credential, the service account with a password that hasn’t been rotated in three years — these are the footholds that make initial access trivial.

The severity compounds over time. A single orphaned account is a vulnerability. Dozens of unmanaged identities across departments represent a pattern. Hundreds across an organization represent a systemic control failure that undermines incident response, regulatory compliance, and cyber insurance coverage. Insurers increasingly scrutinize identity governance during underwriting, and a material gap here can affect both premiums and claim outcomes.

What Attackers Exploit

The specific failure modes that attackers target under weak identity management include:

• Orphaned accounts from leavers or completed projects — these provide access without active monitoring
• Shared credentials that eliminate accountability and make it impossible to attribute actions to individuals
• Service accounts with static passwords and no assigned ownership — often overlooked during access reviews
• Missing approval workflows that let unauthorized identities proliferate without oversight
• Privilege creep from role changes without corresponding access reviews — employees accumulate permissions they no longer need
• Unmonitored non-human identities such as API keys, automation accounts, and machine credentials that operate outside standard lifecycle processes

Each of these failure modes creates a gap between what your security controls assume (every action is attributable) and what actually happens in production. Attackers don’t need sophisticated exploits when identity management hands them legitimate credentials attached to accounts no one is watching.

How to Implement 5.16

For Your Organization (First-Party)

Start with an identity lifecycle policy that defines how identities are created, modified, reviewed, and deprovisioned. This document is your foundation — it should specify account types (employee, contractor, service account, API key), naming conventions, approval requirements, and review cadences. The policy should be owned by a named role, not a department, to avoid the diffusion of responsibility that causes most deprovisioning failures.

Establish approval workflows where the request, authorization, and provisioning steps involve different people. This segregation of duties prevents a single person from creating and approving their own access, which is a common audit finding. The workflow should be documented in a ticketing system that captures who requested, who approved, and when the identity was provisioned — this produces audit evidence automatically.

Set a review cadence: quarterly for privileged accounts, semi-annually for standard user accounts. These reviews should compare active identities against HR records, project rosters, and vendor contracts to identify accounts that should have been removed. The review isn’t complete until excess access has actually been revoked — sign-off without action is one of the most cited audit findings for this control.

Maintain an identity register that covers both human and non-human identities. For each entry, record the owner, the business justification, the approval date, and the last review date. This register is your primary audit artifact and your operational tool for detecting orphaned accounts. Non-human identities are frequently the gap — organizations that track employee accounts but ignore service accounts and API keys will fail this control.

Use an identity provider — such as a centralized directory service — as the single source of truth for identity status. When HR processes a termination or a contract ends, the identity provider should trigger automatic deprovisioning across connected systems. The gap between employment end and account deactivation is one of the most common audit findings, and automation closes it. With the global average cost of a data breach reaching $4.88 million in 2024 according to IBM, the operational investment in automated deprovisioning pays for itself.

For every lifecycle event, produce evidence: approval tickets for new accounts, sign-off records for access reviews, and timestamped logs for deprovisioning actions. Auditors will ask for these, and retroactively creating documentation is both difficult and unconvincing.

Common mistakes to avoid:

• Treating identity management as an IT-only concern instead of involving HR and department managers in the lifecycle
• Ignoring non-human identities — service accounts, API keys, and automation credentials need the same lifecycle governance
• Running access reviews as checkbox exercises without actually revoking excess access
• Allowing shared accounts without documented justification and compensating controls
• Deprovisioning delays — waiting for weekly batch processes instead of real-time revocation when an employee departs

For Your Vendors (Third-Party Assessment)

When assessing vendors against 5.16, start with direct questions in your security questionnaire: Do you maintain a documented identity lifecycle policy? How do you handle deprovisioning when employees leave or change roles? Do you assign unique identifiers to all service accounts? What is your maximum deprovisioning SLA — the time between an employee’s last day and full account deactivation across all systems?

Request supporting evidence beyond the questionnaire responses: a copy of the identity management policy, a sample access review report (redacted as needed), and documentation of their deprovisioning SLA with evidence of adherence. Ask specifically about non-human identity governance — how they manage service accounts, API keys, and automation credentials.

Red flags during vendor assessment:

• The vendor says “we use shared admin accounts” for system management
• No documented deprovisioning process exists, or the process is informal
• Access reviews haven’t been conducted in the past 12 months
• Non-human identities (service accounts, API keys) have no governance framework
• The vendor cannot provide a specific deprovisioning SLA or evidence of meeting it

To verify beyond self-attestation, request the vendor’s SOC 2 Type II report and check whether access control testing — specifically account provisioning and deprovisioning — is in scope. Ask for evidence from their most recent access review cycle — not just the policy, but the actual review output showing actions taken. Confirm that their ISO 27001 certification scope, if they hold one, includes identity management processes rather than excluding them.

Audit Evidence for 5.16

Auditors assessing 5.16 will look for specific artifacts that demonstrate your identity lifecycle is not just documented but actively operational. A policy without corresponding evidence of execution will result in a nonconformity. The following table maps evidence types to example artifacts you should be prepared to produce:

Cross-Framework Mapping

If your organization operates under multiple compliance frameworks, the good news is that 5.16 evidence often satisfies requirements across standards. The NIST 800-53 mappings below are from the official OLIR crosswalk. SOC 2, CIS, and NIST CSF mappings reflect functional equivalence rather than formal crosswalks:

Related ISO 27001 Controls

Control 5.16 doesn’t operate in isolation. It sits within a cluster of related controls that together form a complete identity and access management framework. Understanding these relationships helps during implementation — work on 5.16 directly supports compliance with several adjacent controls:

Frequently Asked Questions

What is ISO 27001 5.16?

ISO 27001 Annex A 5.16 is the identity management control within the ISO 27001:2022 information security standard. It requires organizations to manage the full lifecycle of all identities — both human users and non-human entities like service accounts and API keys — from initial registration and verification through periodic review to deprovisioning. The control’s core purpose is ensuring every action on an information system can be attributed to a uniquely identified entity.

What happens if 5.16 is not implemented?

Without 5.16 controls in place, organizations lose the ability to attribute system actions to specific identities, which cripples incident response and forensic investigations. Orphaned accounts accumulate, creating entry points that attackers exploit for lateral movement. During certification audits, the absence of documented identity lifecycle processes will result in a nonconformity finding that must be remediated before certification can be granted or maintained.

How do you audit 5.16?

Auditors verify 5.16 by examining documented identity lifecycle processes and the evidence they produce. They typically compare the active identity register against HR records to check for orphaned accounts, review approval records for recent identity creation requests, and examine access review logs to confirm reviews are happening at the required cadence. They will also check for non-human identity governance and deprovisioning timeliness.

How UpGuard Helps

UpGuard’s User Risk product gives security teams continuous visibility into identity-related risks across your organization and third-party ecosystem. Monitor for exposed credentials, track identity hygiene across your vendor portfolio, and identify the gaps in identity governance that controls like 5.16 are designed to close — before auditors or attackers find them first.

Explore User Risk