A.5.16 Identity management: requirements and evidence

What A.5.16 identity management requires in practice

If an auditor or a customer questionnaire asks how identities are created and removed, the answer is that A.5.16 requires the organization to manage the full life cycle of identities so that every person and system accessing information can be uniquely identified and given appropriate access rights. In practice that means every identity has a recorded owner, is created through an approved request, changes when the person's role changes, and is disabled and removed when the relationship ends. The control covers non-human identities such as service accounts, API clients and automation as well as employees, contractors and shared logins. Its 2013 predecessor, A.9.2.1 User registration and de-registration, is carried forward into the 2022 edition, so organizations that already had a joiner and leaver process mostly need to show that it reaches every system rather than only the main directory.

The risk the control addresses is accounts that outlive their purpose. Orphaned accounts belong to people who have left or moved on, shared accounts make it impossible to say who did what, and unowned accounts, often service accounts created for a project, keep working with no one responsible for them. What makes the control hard is scattering: identities live in the HR system, a directory, each SaaS application, cloud consoles, databases, CI pipelines and vendor portals, and a removal in one place does not remove the others. Before answering a questionnaire, confirm with the business owner of each system which identities it holds, who approves their creation and who checks that they still belong. A short illustrative exercise, comparing a leaver list from HR against the accounts in three or four key systems, usually shows where the gaps are.

Which identities and systems fall inside A.5.16 scope

A.5.16 applies to every identity that can reach information in scope, so the first decision is the boundary rather than the tooling. The cards below cover the categories that most often change effort, from workforce accounts to pipelines and shared credentials. Each one should be settled and written into the ISMS scope before the lifecycle process is designed.

Workforce identities

Employee accounts are the baseline for A.5.16 because every joiner, mover and leaver event must create, change or remove them with a unique identifier. Scope usually covers every person who can reach in-scope systems, including those who hold accounts only for email or collaboration tools that carry sensitive records. Check that HR records, the directory and each application agree on who is active. Mismatches here are the most common finding.

Contractors and supplier staff

Accounts held by contractors, consultants and staff of suppliers are identities the organization must manage even though it does not employ them. Their start and end dates often sit in a contract rather than an HR system, so the lifecycle process needs a trigger for them. Confirm which party issues each account, who approves it, and how access ends when the engagement closes.

Customer identities in scope

Customer accounts fall inside A.5.16 only when they can reach information within the ISMS scope, such as a shared document store or an administrative portal. Where customers only use a public product that holds no in-scope data, they can usually sit outside the lifecycle controls. Document this boundary explicitly, because auditors will ask how the organization decided.

Service and API accounts

Service accounts that run backups, integrations or batch jobs need an owner, a documented purpose and a review date, even though no person logs in with them. Each one should be registered in the inventory so it can be disabled when the system it serves is retired. Ask engineering for a complete list from the directory and from cloud IAM, not only the accounts they remember.

Shared accounts

Shared accounts break the principle of unique identification, so each one must either be eliminated or recorded as an exception with a named accountable owner and compensating controls such as session logging. Common examples include administrator logins on network devices and team mailboxes. Plan the effort to replace them with individual accounts, since migration often takes longer than the inventory itself.

Non-human identities in pipelines

CI pipelines, automation runners, bots and workload identities authenticate to production systems and carry credentials that outlive the people who created them. Include them in scope when they touch in-scope data or infrastructure, and record who owns each one. Confirm how their secrets are rotated and revoked when a pipeline is retired, because a leftover token is a live identity.

How an assessor tests identity management

This table sets out each step an assessor typically takes to test A.5.16, the evidence requested for each step, and the findings that most often appear. Read it as a pre-audit checklist: if you cannot produce the evidence in the right column for a sample of identities, expect a finding.

Test step	What the assessor checks	Evidence usually requested
Review the registration and removal procedure	A documented process covers how identities are created, approved, changed and removed for people and systems, with named owners	Written identity lifecycle procedure, approval workflow records, owner for each system
Sample joiners	Selected new accounts trace back to an approved request and a valid HR or sponsor record, created on or after the start date	Joiner tickets, HR start records, directory creation logs for the sampled accounts
Sample leavers	Selected people who left the organization no longer have active accounts in the directory or in connected applications	HR termination records, directory account status, application account lists, deprovisioning timestamps
Check unique identifiers	Each person and system identity is distinct, and no two people share one login or one identifier is reused for someone else	Directory export showing unique IDs, rules for identifier reuse, duplicate account reports
Review shared and service accounts	Each shared or non-human account has a named owner, a documented purpose, and controls on who can use its credentials	Register of shared and service accounts, owner sign-off, credential rotation records, usage logs
Reconcile the identity inventory	The directory and application accounts match HR records and the asset inventory, with unexplained accounts investigated	Reconciliation reports, exception log, evidence of who reviewed differences and when
Confirm periodic review	Managers or owners confirm at planned intervals that accounts and roles remain needed	Review campaign records, sign-offs, removed-access evidence from each cycle

How to implement identity lifecycle management step by step

This sequence turns A.5.16 from a policy statement into a working process: every identity source is known, every identity has one owner and one unique identifier, and access is created, changed and removed through the same controlled path. Each step ends with an artifact an auditor can sample.

Inventory every identity source and store
Identify where identities are created and stored: HR system, directories such as LDAP or Active Directory, local application accounts, cloud tenants, CI/CD pipelines, service accounts and API clients. The IAM or platform team leads the work with application owners, who confirm which accounts they hold. The step is done when a register lists each source, its system owner, the populations it covers (employees, contractors, customers, systems) and whether it is the authoritative source for that population. Confirm this register with your auditor's sampling approach before relying on it.
Define the unique identifier rule
Set a written rule for how each person and system identity is named and kept unique, for example one identifier per person that persists across applications, and a rule that identifiers are not reused after removal. Security and HR agree the rule, and the identity platform enforces it at creation. The output is a short standard in the identity policy and a test showing that two requests for the same person resolve to one identity. Confirm the exact rule against your own naming conventions and your legal obligations for retained records.
Set the creation and approval workflow
Define who may request an identity, who approves it, and what each approval must check, such as employment start date, role and manager sign-off. Ticketing or HR-triggered workflows should record the requester, approver, timestamp and granted access. The output is a workflow diagram and a sample of approved requests with complete records. Identities created outside this workflow, including emergency accounts, should be flagged in the register for review.
Connect provisioning and deprovisioning to applications
Connect the authoritative source to target applications so that creation, change and removal propagate automatically rather than by manual copy. For example, an open-source identity provider such as authentik can push user and group changes to target applications over SCIM 2.0 and run periodic full syncs. Keycloak can provide single sign-on and brokered logins for applications that support OpenID Connect or SAML 2.0. The output is a test showing that a removed user loses access in each connected application, and a list of applications that still need manual handling, each with a documented owner.
Assign named owners to shared and non-human identities
Inventory shared accounts, service accounts, API keys, bots and workload identities, and assign each one a named accountable owner and a documented purpose. Where a shared account cannot be removed, record why, restrict its use, and link it to a control for authentication information under A.5.17. The output is a register in which every non-human identity has an owner, a purpose, the systems it touches and a review date. Any identity without an owner should be treated as an exception that management accepts in writing.
Run change and removal handling for movers and leavers
Define the triggers and deadlines for changes in role and for removal when people leave, including contractors whose contracts end and systems that are decommissioned. Removal should disable the identity in the authoritative source, which then propagates to connected applications, and should trigger return of assets under A.5.11. The output is a log of leaver and mover events with timestamps showing that access was changed or removed, plus a reconciliation of leavers against the directory.
Schedule identity life-cycle reviews
Set a recurring review in which owners confirm that each identity, including shared and non-human ones, is still needed and correctly scoped, and dormant accounts are disabled. The review feeds access rights reviews under A.5.18 and is itself recorded. The output is a signed review record per application or population, the list of accounts removed or changed as a result, and evidence that exceptions were approved by management. Confirm the review frequency with your own risk assessment and any contractual or regulatory requirement that applies to you.

Which evidence satisfies A.5.16 at audit

An assessor testing A.5.16 looks for proof that identities are created, changed and removed through a controlled process, and that each record traces back to an accountable owner. The cards below cover the artifacts that carry that proof, and each one needs a refresh rhythm so it still matches the directory when the auditor arrives.

Identity registration and removal procedure

This is the documented process for creating, changing and removing identities for people, contractors and systems. Auditors check that it names who approves a new identity, how the identifier is made unique, and which trigger starts a removal. Confirm the procedure matches what the directory actually does, and review it at least once a year and after any change to HR or directory tooling.

Identity inventory with owners

The inventory lists every identity that can reach information, with its type, status, owning department and accountable person. For A.5.16 it must show each identity uniquely, so an auditor can pick a name and trace it to a real person or a named system. Reconcile the inventory against the directory export each quarter, and record who signed off on the differences.

Provisioning and deprovisioning logs

Logs from the identity provider and target applications show when accounts were created, altered, disabled or deleted, and by which process or administrator. Auditors use them to test whether changes followed the approved request. Confirm that logs are retained long enough to cover the audit period and that they cannot be edited by the administrators whose actions they record.

Joiner and leaver tickets matched to directory changes

For each sampled joiner, mover or leaver, an assessor expects a ticket that authorizes the change and a directory event that carries it out, with timestamps that agree. Mismatches, such as an account still active weeks after a leaver ticket closed, are the findings this evidence is meant to expose. Sample a set of tickets yourself before the audit and resolve any gaps.

Shared and service account register

Shared accounts and non-human identities, such as service accounts, API clients and automation, need their own register with an owner, purpose, credential location and review date. A.5.16 explicitly covers these identities, so an assessor will ask who answers for each one. Keep the register current by tying each new service to a change record and by checking it during every access review.

Directory sync records

When an identity provider pushes accounts to connected applications, the sync records prove that a removal in the source reached every target. For example, an authentik SCIM provider runs a full sync every hour and deprovisions users from targets when they lose access, so its sync history is the evidence to keep. Confirm the sync interval and failure alerts in your own deployment, and review failed sync jobs weekly so that stale accounts do not survive between audits.

How a central identity provider shrinks the identity life cycle

A central identity provider reduces the number of places a leaver has to be removed from. When every application keeps its own user store, a departure means touching each of them, and the ones that were forgotten keep working. When applications instead authenticate users against one authoritative source, the identity is disabled once and access ends wherever that source is the only route in. For A.5.16 Identity management, the decision to make is which system is the authoritative record for people and for service accounts, and which applications are allowed to hold local copies at all. Keycloak (Apache-2.0) is one option for this role: it provides single sign-on over OpenID Connect, OAuth 2.0 and SAML 2.0, so applications trust Keycloak rather than each user store. Zitadel (AGPL-3.0-only) plays a similar role as a central identity broker. Before relying on either, confirm in your own environment which applications can really be configured to use single sign-on and which still hold local passwords, because those gaps are where leavers remain active.

Brokering external identity providers keeps each application from trusting each provider separately. Many organizations already have identities in a corporate directory, Google, Microsoft Entra ID or Okta. Without a broker, each application has to be configured to trust each of those providers, and each trust relationship is another place where a change or removal can be missed. Keycloak can broker logins to existing OpenID Connect or SAML 2.0 identity providers, and Zitadel documents identity brokering through OpenID Connect, SAML 2.0 or LDAP, so the applications only need one trust relationship with the broker. Ask the vendor or test in a lab exactly which attributes and group memberships pass through the brokered login, and whether disabling a user at the upstream provider ends existing sessions at the broker. Those answers determine how fast a leaver loses access.

Brokering does not remove the need for provisioning. Single sign-on controls the login, but an application that stores its own account record can still hold a user after the login path is closed. For that case, the provisioning connector matters. authentik's SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users when they lose access. Treat the hourly full sync as a vendor fact to verify in your deployment, and test one leaver end to end, checking the upstream directory, the broker, and each target application's account list. Record that test as evidence for the leaver step of your joiner, mover and leaver process.

What meeting A.5.16 costs in money and effort

This table lists each cost component of running identity management for A.5.16, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since most of the effort sits in integration and upkeep rather than licenses. The main takeaway is that open-source directories remove license spend but not administration, integration or evidence work.

Cost component	One-time or recurring	What drives it up or down	What to request in a quote
Directory and identity platform licenses	Recurring if commercial; none for the open-source platforms named on this page	Open-source licenses carry no license fee, so cost shifts to hosting and administration. Confirm each project's license terms with its maintainers before relying on them.	Written confirmation of the license terms for every component in scope, and any paid support tier the team may need
Infrastructure to host the directory and identity services	Recurring	Number of users, redundancy requirements and whether the platform runs in separate sites or air-gapped networks	Hosting design, sizing assumptions, backup and recovery arrangements, and who operates each environment
Engineering time to integrate target applications	One-time per application, with upkeep when apps change	Number of applications, protocol support (OpenID Connect, SAML 2.0, SCIM 2.0, LDAP), and whether applications support automated provisioning at all	Application-by-application integration plan, the protocols used for each, and a list of applications that will need manual provisioning
Provisioning and deprovisioning workflows	One-time build, then recurring review	Number of joiner, mover and leaver paths, and how many systems need automated removal of accounts when access ends	Documented joiner, mover and leaver workflows, test evidence of removal, and the systems included in each workflow
Non-human and shared identity management	Recurring	Number of service accounts, API clients, shared accounts and automated jobs, each needing an owner and a review	Inventory approach for non-human identities, ownership rules, and how credentials for them are rotated and retired
Evidence upkeep	Recurring	Frequency of access reviews, the number of systems in scope, and how often roles or applications change	Evidence list per control, collection schedule, and the tool or export format used to produce each record
External testing or independent review	Recurring, usually once per cycle or after major change	Size of the attack surface, whether identity services are exposed to the internet, and the depth of testing requested	Defined test scope, deliverables, and whether retesting is included in the agreed scope
Auditor sampling effort	Recurring at each audit	Number of identities and changes the auditor samples, and how easily the organization can show dated records for each	Clarity from the certification body on sample sizes and the records it will request before the audit starts

Which open-source identity tools produce A.5.16 evidence

Provisioning tools copy identity changes into the applications that need them, so that a joiner, mover or leaver event in one place reaches every connected system. The authentik SCIM provider is an example. It pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access to the application. For A.5.16, the useful evidence is the sync history and the deprovisioning record, which show that a removed identity actually disappeared from the target.

Creation and change records: Sync logs and events show when accounts and group memberships were created or altered, which supports the unique assignment and change parts of the control.
Hourly full sync: A recurring full sync gives a bounded window for drift, and the schedule itself is configuration an assessor can inspect.
Deprovisioning on loss of access: Evidence that a user removed from an application was removed from the target is a direct test of the removal requirement.
Target application support: Provisioning only works for applications that accept SCIM or another supported interface, so legacy systems may need manual or scripted steps with their own records.
Licence: authentik is released under the MIT licence, which affects how you may modify and redistribute it.

Before relying on this tab, confirm which applications in your inventory accept SCIM and what your evidence looks like for those that do not.

Where identity management audits usually fail

Assessors testing A.5.16 rarely fail a team for having no identity system at all. They find gaps between the joiner, mover and leaver process on paper and the accounts that actually exist in applications. The five gaps below are where that drift usually shows up, and each one has a practical check the organization can run before the auditor does.

Leavers kept in secondary applications

Access is often removed from the directory or single sign-on, but local accounts remain in finance tools, source control, ticketing or admin consoles that never joined the central process. An auditor who samples a leaver and checks each system finds the gap quickly. Build a list of every application that holds user records, mark which ones are federated or provisioned automatically, and test a removal end to end for each one. Where automated deprovisioning is not possible, the manual removal step needs a named owner and a record.

Shared accounts without owners

Shared logins for network devices, break-glass access or a team mailbox are hard to tie to a person when something goes wrong. Auditors look for an accountable owner for each shared account, a documented reason it exists, and a record of who holds the credential at any time. Check whether each shared account can be replaced by individual identities with delegated rights, and if not, confirm the owner, the password or key custodian, and the review date are written down.

Service accounts created outside the process

Scripts, pipelines and integrations often get accounts created directly by an engineer, with broad rights and no expiry. These non-human identities fall outside joiner and leaver handling, so nobody notices when the system they served is retired. Require every service identity to have a named business owner, a purpose, a scope and a retirement trigger. Search directories and cloud accounts for identities with no owner attribute, and treat the results as a finding to resolve rather than a backlog to ignore.

No periodic life-cycle review

Joiner and leaver steps may work well for new hires but never get checked against the full population of identities. A.5.16 expects the organization to keep identities in line with current need, and assessors ask for evidence that someone looked at the whole list at planned intervals. Schedule a review of all active identities, including groups and dormant accounts, with a named reviewer, a recorded decision for each identity, and a follow-up for anything removed. Keep the output as a dated record.

Inventory drifting from reality

The identity register, HR feed and actual directory entries diverge over time, especially after reorganizations, contractor churn or application changes. An auditor sampling the register against the live directory will find accounts that exist but are not recorded, or recorded accounts that no longer exist. Reconcile the three sources on a schedule, and confirm which one is the authoritative source for each identity type. Ask your implementation partner or internal team to show the reconciliation output, not just the policy that requires it.

Questions buyers ask about A.5.16 cost, effort and help

How long does it take to implement A.5.16 identity management?

The duration depends on how many identity sources, applications and user populations you have, and on how far your joiner, mover and leaver process is already documented. No single timeline fits every environment, so ask any partner for a written scope and plan before accepting a date. The main drivers are the number of directories you must consolidate (for example, an existing Active Directory forest alongside cloud tenants), how many applications need automated provisioning, whether non-human and shared accounts must be inventoried first, and how many approvals your HR and IT teams need to agree on. Certification timing is a separate question: the audit cycle set by the certification body affects when evidence must exist, so confirm that schedule with your chosen body before planning backwards from a deadline.

Can a small team run identity management under ISO 27001 by itself?

Often yes, if the team has someone who understands directories, single sign-on and access reviews, and if the scope is limited to the systems that really hold information in scope of the ISMS. A small team usually needs to own three things: a documented account lifecycle procedure, a single source of truth for who is employed or engaged, and a recurring review that proves accounts are removed on time. Automation reduces the ongoing load, because a SCIM provider or a central identity broker can carry out creations and removals without manual tickets. The risk for small teams is the person who runs the system also approving their own access, so plan for a second reviewer even when headcount is limited. Confirm with your certification body how it expects segregation to be shown in a small organization.

What does the work need from our own staff?

Your staff must own the decisions that an implementation partner cannot make for you. These include who is authorized to request accounts, which roles map to which applications, how long contractors may keep access, who approves exceptions, and what counts as a shared or non-human identity that needs an owner. Your HR function must supply reliable joiner, mover and leaver events, and your application owners must confirm how each system stores and removes accounts. Expect time from your IT, HR and security leads during discovery, design sign-off and the first access review. Ask any partner to list these responsibilities in writing so that the division of work is clear before the engagement starts.

Should we hire an implementation partner for A.5.16?

A partner is worth considering when your directories, applications and provisioning paths are too many to change safely in-house, or when you lack staff who have built this before. Under the typical model, the organization owns its controls and the partner prepares systems and evidence, such as configured provisioning, documented procedures and sample access reviews. DeployOpen plans, implements and documents self-hosted open-source identity platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. A partner does not issue audit reports or certificates. Only an independent auditor or certification body does that, so keep the implementer and the assessor separate.

What drives the cost of identity management for ISO 27001?

Cost has several components, and each is paid to a different party. You pay for internal staff time, for any implementation partner against a written scope, for software or hosting, and for the independent certification audit, which the certification body prices on its own basis. Costs rise with the number of identity sources, the number of applications that need automated provisioning, the amount of legacy integration, and the number of user populations such as employees, contractors and customers. Recurring costs include platform upgrades, access review effort, support and the cost of keeping evidence current across the three-year certification cycle. When requesting a quote, ask for the scope list, the deliverables, the assumptions about existing systems, what is one-time and what recurs, and who performs each step.

Do open-source identity tools remove license spend for A.5.16?

Open-source licenses remove per-user software fees for the platform itself, but they do not remove the cost of the work. Projects such as authentik (MIT), FreeIPA (GPL-3.0-or-later), Keycloak (Apache-2.0) and Zitadel (AGPL-3.0-only) carry different license obligations, and your legal team should confirm how each applies to your use, especially if you modify or distribute the software. You still pay for hosting in your own infrastructure, for design, integration, hardening, backups, upgrades and the operational support that keeps the platform running. Ask whether any vendor support contract you are considering is optional or required. Treat the license as zero-cost only once you have priced the people, infrastructure and support that the platform needs.

What evidence will an auditor ask for on identity lifecycle controls?

Auditors test A.5.16 by sampling real identities and tracing each one back to a documented request, approval and removal. They typically ask for the account lifecycle procedure, a list of current accounts with their owners, records of joiner and leaver events, deprovisioning logs showing removal within the timeframe your procedure sets, and records of periodic reviews of shared and non-human accounts. Your procedure should match what the systems actually do, so check the configuration before the audit rather than after. Confirm with your certification body which sample sizes and record formats it expects, because these vary between assessors.

How DeployOpen prepares identity evidence for A.5.16

DeployOpen scopes the identity sources and target systems in writing before any work starts. For A.5.16 that means agreeing which directories, HR feeds and user stores create identities, which applications and infrastructure accept them, and which non-human accounts such as service accounts, API clients and CI runners fall inside the life cycle. The organization owns this control, including the decisions about who may request, approve and remove an identity. DeployOpen's role is to prepare the systems, procedures and records that show those decisions are carried out. Only an independent auditor or certification body issues reports or certificates, so the written scope should also name the evidence the assessor will sample.

DeployOpen implements the self-hosted identity platforms inside the client's own cloud accounts, data centers or air-gapped networks. Depending on the agreed design, that can include authentik with its SCIM provider to push user and group creations, changes and deletions to target applications, FreeIPA with 389 Directory Server as the central directory for users, groups and hosts, and Keycloak or Zitadel as the single sign-on layer that brokers logins to external identity providers. Each platform leaves different evidence: provisioning logs, directory change records, and deprovisioning results on the target side. The client should confirm which of these features its chosen version provides and how long logs are retained before relying on them.

Alongside the configuration, DeployOpen prepares the procedures and records an assessor will look for: joiner, mover and leaver steps, the approval trail for each new or changed identity, the rule for assigning unique identifiers and retiring shared accounts, and a schedule for reviewing identities against the HR and contractor records. The client should decide who owns each review and how exceptions for shared or non-human identities are approved and expired. The more of this that is written down and run from the platform, the less of it depends on memory when the auditor asks for a sample from last quarter.

A.5.16 Identity management