ISO 27001:2022 Annex A 5.16 Identity management

In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.16 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways: ISO 27001 Annex A 5.16 Identity Management

ISO 27001 Annex A 5.16 requires organizations to manage the full lifecycle of digital identities. While the previous standard focused largely on user accounts, the 2022 update expands this to include all entities, meaning human users, systems, services, and devices. Identity management is the foundation of secure access; it ensures that every person or machine interacting with your data is uniquely identified and verified throughout their entire tenure with the organization.

• Digital identities can be both human and system based
• More that one entity can access an identity
• Identities should be managed for their entire life cycle.

Core requirements for compliance include:

• Full Lifecycle Management: You must have a documented process for the Registration, Verification, Provisioning, Maintenance, and De-registration of all identities.
• Unique Identification: The core principle is “One Entity, One ID.” Shared accounts should be strictly avoided unless there is a clear, documented business justification and compensatory controls (like enhanced logging) are in place.
• Verification of Identity: Before an identity is created or modified, you must verify the entity. For humans, this links to Screening (A.6.1); for systems, it involves verifying the service or device’s legitimacy.
• Segregation of Duties: The person who requests a new identity or an access change should not be the same person who approves and implements it. This prevents unauthorized account creation.
• Administrative Account Oversight: You must pay special attention to “privileged” or administrative identities, ensuring they are only active when needed and are subject to stricter monitoring.
• Logging and Monitoring: Significant events, such as account creation, failed logins, or deletion, must be logged and periodically reviewed to detect suspicious activity.

Audit Focus: Auditors will look for “The Lifecycle Audit Trail”:

1. Orphaned Accounts: “Show me the list of users in your Active Directory. Now show me your HR leaver list for the last 6 months. Why do these 4 people who left still have active digital identities?”
2. Admin Group Review: “Show me the members of your ‘Domain Admins’ or ‘Global Admins’ group. Can you justify why every person or service account in this list requires this level of access?”
3. Approval Evidence: “Pick a random new hire. Show me the documented business justification and the manager’s approval for their identity creation.”

Identity Lifecycle Stages (Audit Prep):

Stage	Critical Action Required	Primary Responsibility	ISO 27001:2022 Control
1. Registration	Create a unique ID (e.g., jsmith).	HR / IT Service Desk.	Annex A 5.16
2. Verification	Validate credentials/ID (Ref A.6.1).	HR / Hiring Manager.	Annex A 5.16 / 6.1
3. Provisioning	Activate account & set permissions.	IT Systems Admin.	Annex A 5.16 / 5.18
4. Maintenance	Update details (role change, name).	HR / IT Operations.	Annex A 5.16
5. De-registration	Disable & Archive (Termination).	IT Security / HR.	Annex A 5.16

What is Identity Management?

Identity management is an evolution of user access management that covers the entire lifecycle of digital identities for all entities.

Identities are used to access data and resources.

It is a framework of policies, process and technologies to ensure that the right entities have the right access to the right resources.

What is ISO 27001 Annex A 5.16?

Identities are the things that identify users, systems, services and are their virtual representation allowing access to data and resources. They can be managed, allocated and used to control, monitor and report on what people and systems do and are doing.

ISO 27001 Annex A 5.16 Identity Management is  an ISO 27001 control that requires an organisation to mange the full life cycle of identities.

ISO 27001 Annex A 5.16 Purpose

The purpose of ISO 27001 Annex A 5.16 Identity Management is a preventive control that ensures the unique identification of individuals and systems accessing the organisations information and other associated assets and to enable appropriate assignment of access rights.

ISO 27001 Annex A 5.16 Definition

The ISO 27001 standard defines ISO 27001 Identity Management as:

The full lifecycle of identities should be managed.

ISO 27001:2022 Annex A 5.16 Identity Management

ISO 27001:2022 Annex A 5.16 Changes

ISO 27001 Annex A 5.16 Identity Management is pretty much the same. It now looks at all identities rather than just user accounts to factor in the fact we can have system and service accounts.

I like that we have always worked to one user – one ID. I also like that the statement is absolutely valid and should be adopted but is redundant from the standards perspective as the standard now basically says, unless you can’t or don’t want to. If you need many people to use one account based on business or operational needs then the standard says its fine. It is nuanced but headline grabbing, sweeping statement wise, a nice pointless thing to mention in a standard as it adds no value.

Watch the ISO 27001 Annex A 5.16 Tutorial

In the video ISO 27001 Identity Management Explained – ISO27001:2022 Annex A 5.16 show you how to implement it and how to pass the audit.

ISO 27001 Annex A 5.16 Podcast

In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.16 Identity Management. The podcast explores what it is, why it is important and the path to compliance.

ISO 27001 Annex A 5.16 Implementation Guidance

Human and non human identities

Human and non human identities are no longer distinct from each other. For practicable terms they are treated the same.

Implement an approval process for creating or revoking identities

You will want a process that covers the approval for the creating, revoking and deletion of identities. Think in terms of user accounts and system accounts. We cannot go around creating these willy nilly, allowing them to do what ever they like and then forgetting about them. Your process can be simple but the driving principle is the person making the request cannot be the person that approves it. This is part of segregation of duty and clearly, hopefully, is common sense. What ever the process is in terms of the technology that implements it, you should maintain and audit trail of the approvals. An example would be keeping copies of the email exchange, or the tickets that were raised in a ticketing system.

Consider perhaps that your processes may vary slightly or be tightened up a little in certain circumstances. Examples of this would be where third parties require accounts or identities to be created. Also an example would be super user and administrative identities.

Confirm the business requirement for creating an identity

For the creation of all identity types a business case and / or justification is documented and included in the approval process.

It is important to understand why you are creating an account or an identity. It will allow the person approving it to understand what and why they are approving as well as allow you to maintain some level of control in the technological Wild West that you no doubt have in place.

Particular attention should be given to admin accounts or accounts that have special powers. Not like superman. But like the kind that can cause significant harm or access everything.

Verify the identity of an entity before creating the virtual representation

In a world of zero trust, when an entity is created, modified or deleted both the requestor and the entity where relevant are appropriately verified and checked.

The standard doesn’t give much guidance on this and clearly it is going to be hard if not impossible to do for non human identities. It is a hang over from when they only worried about user accounts so they kept it. It does make sense for users and people so as part of the approval process, or for the human that requires the identity, verifying who they are and that they are who they say they are makes senses. There is a lot of phishing attempts made to get people to do things they would not normally do, including creating accounts, that bad guys then use to do you harm. I am not saying check passports and photo id but I am saying be sensible and do some level of check to satisfy yourself the person is who they say they are. Use common sense. If you get a request and it doesn’t feel right no one minds if you pick up the phone to check or ask their boss / others for extra verification.

Create the identity

This really should be done by someone that knows what they are doing. The identity is going to be used to access ‘stuff’ so it is probably a good idea at this stage to create the record of the identity and who it was assigned to. The identity is created and access granted. Default permissions are removed and modified to reflect the role based access or creation request. The user is informed via secure methods and default credentials are forced to be changed at the first opportunity.

Configure the identity and activate it

Again, this should be done by someone that knows what they are doing. It is easy to create accounts and identities but you really should have experience to understand what you have created and how to configure in a way that meets the approved request and the needs of the business rather than what ever the default system identity. Defaults are defaults and not designed to meet your specific needs.

It goes without saying – DO NOT USE DEFAULT IDENTITY PASSWORDS.

Did that really need saying? You would be surprised.

It is easy to Google what the default identities and passwords are for systems. Way too easy.

One person one id

Where an identity is assigned to a human then it should be unique to that human so we know what that human did if things go wrong and we can control what the human has access to and can do. Through training and awareness based on having policies in place that tell people not to share login information and including the consequences of doing so.

Many persons one ID

The standard and common sense wants one human to one ID but it does allow for many people using one ID where they are required for business, operational needs and have appropriate documentation. Ensuring that approval processes account for shared identities and the sparing use of such identities in exceptional circumstances that are clearly documented.

Non Human IDs

As in the implementation guide above you will want an approval process for system and non human identities. You will also want some level of oversight of them. There is no guidance in the standard on what this means so I recommend having a periodic ( monthly ) review of all service accounts to make sure they are needed still and perhaps alternating with a check on the configuration of the ID and what it can do.

Remove old IDs

Processes such as the leaver process and off boarding as well as automated processes that create identities remove and or disable identities that are no longer required.

Reviews and audits are put in place to check that identities no longer required are handled appropriately in a timely manner and not left in systems.

You can only call something by one name

Identities are never duplicated, they are never copied to create new identities and the rule of one user, one entity to one ID is upheld where ever possible.

The standard doesn’t want you calling entities by different names with different names mapped. If your entity / server / laptop or what ever is called Brian then it is called Brian. It isn’t called Brian by IT but Anna by HR.

Logging, Monitoring and Reporting

The standard wants records of significant events on the use and management of identities and for that to be kept. This is actually a powerful statement and was a clause in its own right but logging and monitoring of identities and administrative actions is a must. It is just up to you to decide what ‘significant’ means.

I would not get carried away logging everything as you will never look at it but consult the norm for the systems you are using and think about things like

• failed log on attempts
• account creating
• account deletion

Events are determined as appropriate, considering creation, modification and deletion and those events once determined are recorded and those records are kept.

Identity Management Process

The identity management process is usually made up of the following process steps:

Request for the identity / access: the identity is requested by someone. This step usually includes a justification for the creation of the identity and access required.

Approval: the request is formally approved. This step is usually conducted by someone senior in the organisation in conjunction with the system and / or data owner.

Implementation: the identity is created and access granted. Default permissions are removed and modified to reflect the role based access or creation request. The user is informed via secure methods and default credentials are forced to be changed at the first opportunity.

Modification: following the structured approval process the identity is modified based on business need.

Destruction: when no longer required the identity is disabled and ultimately deleted.

Identity Management Principle

The principles on identity management are One User to One ID.

How to implement ISO 27001 Annex A 5.16

Lifecycle Stages

Stage	Action	Responsibility
1. Registration	Create unique ID (e.g., jsmith).	HR / IT Service Desk.
2. Verification	Check ID / Background (Ref A.6.1).	HR / Hiring Manager.
3. Provisioning	Activate account (enable login).	IT Systems Admin.
4. Maintenance	Update details (name change, dept).	HR / IT.
5. De-registration	Disable & Archive (Leaver).	IT Security / HR.

ISO 27001 Access Control Policy Template

The ISO 27001 Access Control Policy template is pre written and ready to go. It is one of the required ISO 27001 policies that sets out the organisations approach to access control.

How to pass the ISO 27001 Annex A 5.16 audit

To comply with ISO 27001 Annex A 5.16 Identity Management you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to

• Implement a process for creating, updating and removing IDs
• Implement an approval process
• Include business case / justification in the approval process
• Have a HR leaver process that removes user IDS
• Regularly review accounts and identities
• Log and monitor activity

What the auditor will check

The audit is going to check a number of areas. Lets go through the most common

1. That you have not done something stupid

The auditor is going to check the rules, procedures and access control methodology and make sure you followed them. As with everything having documented evidence of anything you can is going to be your friend. So practical things like asset registers, access control procedures that you can evidence are in operation, reviews of access. Work through recent hires for example and ensure the processes were followed and look for the gotchas. Is there an approval audit trail. When you log into the system that was approved does the users access match what was requested.

The easiest win for an auditor is get you to show them the admin accounts on what ever system you are using and then explain the accounts that are in the admin group. 9 out of 10 times there are admin accounts in here you forgot about, are for people that left or you are unsure yourself what the account is. Instant problem. Check now.

2. That you have rules, processes and you have followed them and have trained people

This is obvious but they are going to look that you have documented what you say you do, that you follow it and that you have trained people. The biggest gotcha here is having people with accounts that have left. In other words you didn’t have or follow a leaver process and so people’s access remain even though their contract has ended.

3. Documentation

They are going to look at audit trails and all your documentation and see that is classified and labelled. All the documents that you show them, as a minimum if they are confidential should be labelled as such. Is the document up to date. Has it been reviewed in the last 12 months. Does the version control match. Doing anything else would be a massive own goal.

Top 3 ISO 27001 Annex A 5.16 Mistakes People Make and How to Avoid Them

The top 3 Mistakes People Make For ISO 27001 Identity Management are

1. People have left but they still have an account

Make sure that access to systems is up to date and that people or third parties that have left no longer have access or accounts.

2. Third parties have open access and account they do not need

Third parties should follow process and the process should be to grant access to them when the access required and remove it when it is not. It should not be open and continual access. Consider the example where you need a third party to fix something. You would grant access to allow the fix and then remove it. You would not have open ended access granted.

3. Your document and version control is wrong

Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.

Applicability of ISO 27001 Annex A 5.16 across different business models.

Business Type	Applicability & Interpretation	Examples of Control
Small Businesses	Identity Verification. You don’t need expensive ID verification software, but you must prove that the person logging in is who they say they are. This links closely to HR screening.	• The “Passport Check”: A simple HR process where a passport or driving license is visually verified before an email address (Identity) is created. • Unique IDs: Banning “Shared” accounts like sales@company.com for login. Instead, creating jane.doe@company.com and using “Shared Mailboxes” for collaboration.
Tech Startups	Centralized Identity (IdP). Managing identities across 50 SaaS tools is impossible manually. Startups should use a “Single Source of Truth” (like Google Workspace or Okta) to create and verify identities.	• Single Sign-On (SSO): Configuring Google Workspace as the primary Identity Provider (IdP). If a user isn’t verified in Google, they don’t exist in Slack, Jira, or AWS. • Developer Identity: Enforcing strict separation between “Personal” GitHub accounts and “Corporate” identities to ensure IP ownership.
AI Companies	Non-Human Identities. AI models and training pipelines often run as “Service Accounts” or “Bots.” These are digital identities that must be registered, owned, and managed just like humans.	• Service Principals: Creating specific identities (e.g., etl-pipeline-bot) for data ingestion scripts, rather than running scripts under a developer’s personal user ID. • External Collaborators: Strict KYC (Know Your Customer) checks on data labelling contractors before issuing them a digital identity to access sensitive training pools.

Fast Track ISO 27001 Annex A 5.16 Compliance with the ISO 27001 Toolkit

For ISO 27001 Annex A 5.16 (Identity management), the requirement is to manage the full lifecycle of digital identities, for both humans (employees/contractors) and non-humans (systems/services). This ensures that every entity accessing your data is uniquely identified and held accountable.

Compliance Factor	SaaS Compliance Platforms	High Table ISO 27001 Toolkit	Audit Evidence Example
Policy Ownership	Rents access to your identity rules; if you cancel the subscription, your documented registration and revocation standards vanish.	Permanent Assets: Fully editable Word/Excel Identity Lifecycle Policies and templates that you own forever.	A localized “Access Control Policy” defining the specific verification steps required for new digital identities.
Operational Utility	Attempts to “automate” syncing via dashboards that cannot justify why a service account exists or verify a person’s identity.	Governance-First: Formalizes your existing IDP (Active Directory, Okta) workflows into an auditor-ready framework.	An “Identity Lifecycle Matrix” proving that every account—human or non-human—has a defined creation and expiry process.
Cost Efficiency	Charges an “Identity Seat Tax” based on user count, creating perpetual overhead that scales aggressively as your headcount grows.	One-Off Fee: A single payment covers your identity governance for 10 identities or 10,000.	Allocating budget to advanced IDP licensing or MFA hardware rather than monthly “compliance seat” fees.
Strategic Freedom	Mandates rigid reporting formats that may not align with hybrid cloud setups or unique service-account naming conventions.	100% Agnostic: Procedures adapt to any environment—high-end automation or manual risk-managed approvals.	The ability to evolve your identity strategy (e.g., moving to passwordless) without reconfiguring a rigid SaaS module.

Summary: For Annex A 5.16, the auditor wants to see that you have a formal process for managing the identity lifecycle and proof that it is followed (e.g., approval trails and timely de-registration). The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.

ISO 27001 Annex A 5.16 FAQ

Related ISO 27001 Controls

ISO 27001 Annex A 5.17 Authentication Information

ISO 27001 Annex A 5.18 Access Rights

ISO 27001 Clause 6.1.3 Information Security Risk Treatment

Further Reading

The complete guide to ISO/IEC 27002:2022

ISO 27001 Access Control Policy Beginner’s Guide

Matrix of controls and attribute values

Control type	Information security properties	Cybersecurity concepts	Operational capabilities	Security domains
Preventive	Confidentiality	Protect	Identity and access management	Protection
	Integrity
	Availability