ISO 27001 Annex A 5.16 Identity Management is a security control that mandates managing the full lifecycle of digital identities for all entities. It requires that humans and systems are uniquely identified and verified, delivering the business benefit of secure accountability and reduced risk of unauthorised access throughout the network.
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”:
- 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?”
- 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?”
- 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 |
Table of contents
- What is Identity Management?
- What is ISO 27001 Annex A 5.16?
- Watch the ISO 27001 Annex A 5.16 Tutorial
- ISO 27001 Annex A 5.16 Podcast
- ISO 27001 Annex A 5.16 Implementation Guidance
- How to implement ISO 27001 Annex A 5.16
- Lifecycle Stages
- ISO 27001 Access Control Policy Template
- How to audit ISO 27001 Annex A 5.16
- How to pass the ISO 27001 Annex A 5.16 audit
- What the auditor will check
- Top 3 ISO 27001 Annex A 5.16 Mistakes People Make and How to Avoid Them
- Applicability of ISO 27001 Annex A 5.16 across different business models.
- Fast Track ISO 27001 Annex A 5.16 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 5.16 Applicable Laws and Related Standards
- ISO 27001 Annex A 5.16 FAQ
- Further Reading and Related ISO 27001 Controls
- Matrix of controls and attribute values
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
Implementing ISO 27001 Annex A 5.16 is about establishing a definitive digital identity for every person or service that interacts with your systems. As a Lead Auditor, I want to see a seamless lifecycle where identities are verified at the start and revoked immediately at the end. Without a structured Identity Management process, your access controls are built on sand. Follow these ten steps to ensure your identity framework is audit-ready and technically robust.
1. Formalise the Identity Management Policy
Establish a documented policy that defines how identities are created, managed, and retired. This serves as your primary governance document for the entire identity lifecycle.
- Define clear roles and responsibilities for identity administrators and approvers.
- State the requirement for unique identifiers for every user and service entity.
- Prohibit the use of shared or generic accounts to maintain individual accountability.
2. Map Identities to the Asset Register
Treat digital identities as critical assets by including them in your Information Asset Register. This ensures that every identity has a clear owner and a defined business purpose.
- Categorise identities into types such as employees, contractors, and service accounts.
- Link identities to specific hardware or software assets they are permitted to access.
- Ensure the Register of Experts (ROE) documents who has the authority to manage these identities.
3. Implement a Rigorous Registration Process
Create a formal workflow for the registration of new identities. This prevents the “ad-hoc” creation of accounts that often leads to security vulnerabilities.
- Require a formal request from a department head or asset owner for every new identity.
- Integrate the identity request into your standard Joiner, Mover, Leaver (JML) process.
- Document the business justification for each identity created within your IAM system.
4. Verify Entity Identity Before Provisioning
Establish a standard for verifying the identity of a human or service before any digital credentials are issued. You must be certain that the entity is who they claim to be.
- Utilise government issued identification or validated HR records for human users.
- Implement technical verification for service identities or API keys.
- Maintain a record of the verification method used for audit evidence.
5. Provision Unique Identifiers
Assign a unique, non-reusable identifier to every entity. This is the foundation of accountability within your system logs and forensic capabilities.
- Ensure that usernames or IDs are unique across the entire organisational ecosystem.
- Implement a policy that prevents the immediate reuse of identifiers after an identity is retired.
- Sync identifiers across disparate systems using a Centralised Identity Provider (IdP).
6. Manage Authentication Information Securely
Establish secure protocols for the initial issuance and subsequent management of authentication secrets. The handover of initial credentials is a high-risk touchpoint.
- Use secure, out of band channels to deliver initial passwords or tokens.
- Force a password change upon the very first login attempt.
- Implement Multi-Factor Authentication (MFA) as a mandatory requirement for identity activation.
7. Automate the De-registration Process
Develop a process to revoke identities immediately when an individual leaves the organisation or a service is no longer required. Orphaned identities are a primary target for external threats.
- Connect your IAM system to HR triggers to ensure de-provisioning happens in real time.
- Set a hard limit, such as 24 hours, for the removal of all access after an employee departs.
- Ensure that de-registration also triggers the recovery of physical access tokens or keys.
8. Monitor Identity Lifecycle Changes
Implement logging and monitoring for every change made to an identity. This provides visibility into who modified an identity and why, which is crucial for compliance.
- Log all events related to identity creation, modification, and deletion.
- Protect identity logs from unauthorised modification or deletion to maintain audit integrity.
- Set up alerts for unauthorised attempts to create or modify privileged identities.
9. Perform Regular Identity Re-verification
Schedule periodic reviews to ensure that existing identities are still valid and that the verification status remains current. Identities should not exist indefinitely without re-validation.
- Conduct an annual review of all active identities against current HR and contractor lists.
- Verify that the “owner” of each service account still requires that identity to be active.
- Deactivate identities that have been inactive for a defined period, such as 90 days.
10. Audit the Identity Management System
Conduct regular internal audits of the identity management framework to ensure it operates as intended. This “Check” phase ensures your technical controls haven’t drifted from your policy.
- Sample new registrations to ensure the authorisation trail is complete.
- Test the leaver process to verify that accounts are truly disabled within the required window.
- Provide documented audit results as evidence for your ISO 27001 Stage 2 certification.
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 audit ISO 27001 Annex A 5.16
Auditing ISO 27001 Annex A 5.16 Identity Management is a critical exercise in verifying that your organisation knows exactly who is on the network and why they are there. As a Lead Auditor, I look for a robust identity lifecycle that prevents unauthorised access and ensures individual accountability. This 10 step audit process focuses on the technical and procedural evidence required to prove that identities are managed from cradle to grave without security gaps. Use this sequence to validate your identity controls before your certification body arrives.
1. Review the Identity Management Policy
Inspect the formal Identity Management Policy to ensure it is management approved and covers the full lifecycle of digital identities. Without a defined rulebook, the technical implementation will lack the consistency required for compliance.
- Verify the policy defines the roles and responsibilities for identity creation and management.
- Ensure the policy explicitly prohibits the use of shared or generic identities.
- Check that the policy is aligned with the latest ISO 27001:2022 requirements.
2. Inspect the Identity Registration Workflow
Examine the process for creating new identities to ensure it is structured and authorised. You must prove that every identity in the system is mapped to a verified human or service entity.
- Audit a sample of new user registrations to confirm that identity verification took place.
- Check for a formal authorisation trail from the relevant department head or asset owner.
- Confirm that identity creation is tied to the official Joiner, Mover, Leaver (JML) process.
3. Audit Unique User Identifiers
Verify that every user is assigned a unique identifier that is never shared. Individual accountability is the cornerstone of ISO 27001, and shared accounts represent a significant audit failure.
- Inspect the Active Directory or Identity Management (IdM) system for generic accounts like “admin” or “guest”.
- Confirm that unique identifiers are not reused for a defined period after an employee leaves.
- Cross-reference identifiers against the Asset Register to ensure ownership is clear.
4. Evaluate Identity Verification Standards
Validate the methods used to prove a person’s identity before their digital persona is created. In a high-security environment, simple verbal confirmation is insufficient.
- Review the evidence of identity checks, such as government issued IDs or HR documentation.
- Ensure the verification process is consistent for both internal staff and third party contractors.
- Confirm that verification occurs before any authentication information is issued.
5. Review Authentication Information Handover
Inspect the secure delivery of initial passwords or authentication tokens. If initial credentials are sent in plain text or handled poorly, the identity is compromised from day one.
- Verify that initial authentication info is delivered through a secure, out of band channel.
- Check that users are forced to change their initial password upon first login.
- Audit the helpdesk procedures for identity verification during password resets.
6. Verify the De-registration and Removal Process
Examine the “Leaver” process to ensure that identities are revoked immediately upon termination of employment. Stale identities are one of the most common findings in a Stage 2 audit.
- Compare a list of recent leavers from HR against the active user list in your IAM system.
- Confirm that identities were disabled or deleted within the timeframe specified in your policy.
- Check that de-registration also triggers the removal of physical access tokens.
7. Assess Identity Inventory and Asset Register Alignment
Reconcile your list of active identities against your Information Asset Register. An auditor needs to see that identities are treated as assets that require tracking and management.
- Ensure every identity is linked to a designated “Identity Owner” or responsible manager.
- Verify that the inventory of identities is reviewed periodically for accuracy.
- Identify and justify any “service accounts” used for automated system processes.
8. Inspect Segregation of Duties in Identity Operations
Check for Segregation of Duties (SoD) to ensure that no single individual has total control over the identity lifecycle. This prevents internal fraud and unauthorised account creation.
- Confirm that the person who authorises an identity is not the same person who technically creates it.
- Review the Register of Experts (ROE) to see how identity management duties are split.
- Audit the logs for identity administrators to ensure their actions are monitored.
9. Audit the Identity Lifecycle Audit Trail
Examine the system logs for all changes made to digital identities. A lack of logging for identity modifications makes forensic investigation and audit verification impossible.
- Verify that logs capture the creation, modification, and deletion of all identities.
- Ensure logs include the timestamp, the identity of the administrator, and the nature of the change.
- Confirm that identity management logs are protected from unauthorised modification.
10. Validate Identity Management Governance
Review the overall governance of the identity management system to ensure it is functioning as intended. Continuous improvement and management oversight are essential for maintaining the ISMS.
- Inspect the results of recent internal audits or management reviews related to identity.
- Check for evidence of corrective actions taken when identity gaps were identified.
- Confirm that the Identity Management system is part of the regular risk assessment cycle.
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 |
| 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., |
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 Applicable Laws and Related Standards
| Industry Standard / Law | Relevant Section(s) | How it Aligns with ISO 27001 A.5.15 |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-1, AC-2, AC-3, AC-5, AC-6 | Requires formal Access Control policies and account management mirroring the “business requirement” focus of A.5.15. |
| SOC 2 (TSCC) | CC6.1, CC6.2, CC6.3 | Focuses on logical and physical access; A.5.15 serves as primary evidence for Security and Confidentiality criteria. |
| NIS2 Directive (EU) | Article 21(2)(g) | Mandates security in network and information systems, necessitating the strict logical access controls defined in A.5.15. |
| DORA (EU) | Articles 9 & 10 | Financial entities must manage ICT access rights and implement segregation of duties to ensure operational resilience. |
| UK Data (Use and Access) Act 2025 | Part 1 & Part 5 | Maintains high security thresholds; A.5.15 fulfills the requirement for “secure interface” and “protected access” to smart data. |
| Cyber Security and Resilience Bill (UK) | MSP Scope Expansion | Extends NIS2-style reporting to MSPs; A.5.15 is critical for proving privileged access management over client systems. |
| GDPR / UK GDPR | Article 32(1) | Requires appropriate technical measures; access control is the primary barrier to prevent unauthorized data processing. |
| CCPA / CPRA (California) | Civil Code §1798.150 | Mandates reasonable security procedures; A.5.15 is the recognized benchmark for “reasonable” protection of personal info. |
| HIPAA (Security Rule) | 45 CFR §164.312(a)(1) | Explicitly requires Access Control to allow only authorized persons to access electronic protected health information (ePHI). |
| CIRCIA (USA) | Section 2242 | Mandatory 72-hour reporting; A.5.15 provides the logging framework to describe security measures bypassed during an incident. |
| EU AI Act / ISO 42001 | Article 15 / Control 8.8 | High-risk AI systems must implement access controls to protect training datasets and model weights from manipulation. |
| EU Product Liability Directive (PLD) Update | Articles 6 & 7 | Extends strict liability to software; lack of A.5.15 controls can be cited as a “design defect” in cybersecurity-flawed products. |
| ECCF (European Cybersecurity Certification Framework) | EUCC / CSA | Harmonised security labels; A.5.15 maps to Identification & Authentication (FIA) and User Data Protection (FDP) classes. |
Managing Machine and Service Identities
One of the biggest mistakes I see during audits is an over-reliance on managing human users while completely ignoring the “non-human” entities. In the ISO 27001:2022 update, the standard made it clear: an identity is an identity, whether it has a pulse or a processor. If a system, service, or bot is accessing your data, it needs a managed identity lifecycle just like any employee.
What are Non-Human Identities (NHI)?
In simple English, these are the digital personas used by software. Think about your backup scripts, your CRM talking to your email platform, or an AI model pulling data from a database. These services don’t “log in” with a username and password in the traditional sense, but they use API keys, service principals, or secrets to prove who they are.
The Stuart Barker Rules for Service Accounts
If you want to pass your audit and actually secure your network, you need to apply these three rules to every system account you create:
- Every Account Needs a Human Sponsor: You cannot have “ghost” accounts. Every service identity must be linked to a person in your asset register who is responsible for its existence. If that person leaves, the sponsorship must be transferred.
- The Principle of Least Privilege: Just because a service account isn’t a human doesn’t mean it should have “Domain Admin” rights. If a bot only needs to read one folder, give it access to that folder and nothing else.
- Unique IDs for Every Service: Never share one service account across multiple applications. If your “Backup-Bot” and your “Finance-App” use the same identity, you have zero accountability. If one gets compromised, both are wide open.
The NHI Lifecycle (For Audits)
When an auditor asks how you manage system identities, don’t panic. Show them this process:
- Registration: The developer or system admin requests a service account with a documented business justification.
- Provisioning: The account is created with a unique name (e.g.,
svc-cloud-backup) and limited to specific IP addresses or resources. - Secret Management: Instead of hard-coding passwords in scripts, you use a “Secrets Vault.” This ensures the “password” for the identity is rotated automatically and never seen by human eyes.
- Review: Every 6 to 12 months, you perform an “Identity Reconciliation.” You look at the list of service accounts and ask, “Is this bot still doing its job?” If the project is dead, the identity is killed.
- De-registration: When a service is decommissioned, the identity is disabled immediately. This prevents “Orphaned Secrets” that hackers love to exploit.
Auditor’s Pro-Tip: During an audit, I will often ask to see your “Secrets Manager” or a list of “Service Principals.” If I see a service account that hasn’t been used in two years but is still active, that is a non-conformity. Keep your environment clean.
The Emergency Break Glass Protocol
If you rely 100 percent on a Centralised Identity Provider like Okta, Azure AD, or Google Workspace, you have a massive single point of failure. If that provider goes down, or you accidentally lock yourself out of the global admin console, your entire business stops. From an ISO 27001 perspective, this is an availability and a security nightmare. This is why you need “Break Glass” accounts.
What is a Break Glass Account?
A Break Glass account is an emergency identity that is not connected to your standard Single Sign On (SSO) or Multi Factor Authentication (MFA) provider. It is a highly privileged, “in case of emergency only” account used to regain control when the primary systems fail. Because these accounts have God-like powers, they are a high-value target for hackers, which means the auditor is going to look at them with a magnifying glass.
How to Manage Emergency Identities Securely
You cannot just create an account called admin-backup with a simple password and leave it in a spreadsheet. To pass your audit, you must prove that this identity is managed with extreme rigour:
- Exclusion from SSO: The identity must be cloud-native or local to the system so it works even if your network or identity provider is offline.
- Non-Human Assignment: These accounts should not be assigned to a specific person’s name. They are functional identities for emergency use only.
- Physical and Digital Protection: The credentials should be split. For example, half the password is held by the CEO in a physical safe, and the other half is held by the CTO. Or, use a high-security digital vault that requires dual approval to “check out” the password.
- Immediate Alerting: This is the most important part for compliance. You must have a monitoring rule that says: “If anyone logs into the Break Glass account, send a high-priority alert to the entire security team and management immediately.”
Audit Evidence for Break Glass Accounts
When I am auditing Annex A 5.16, I will specifically ask about your disaster recovery for identities. You should be able to show me:
- The Policy: Where you have documented who is authorised to use the account and under what specific conditions (e.g., total SSO failure).
- The Log History: I want to see a log that shows the account has never been used, or if it was, that there is a corresponding incident report explaining why.
- The Testing Record: Proof that you test the account at least once or twice a year to ensure the password still works and the alerts actually fire.
Lead Auditor Note: If I see your Break Glass account being used for routine maintenance or because someone forgot their own password, I will flag it. These identities are for catastrophes, not convenience. Use them only when the building is metaphorically on fire.
The Identity vs. Access Rights Matrix
One of the most common ways to fail an ISO 27001 audit is to confuse Identity Management (A.5.16) with Access Rights (A.5.18). I see it all the time. People think that because they have created a user account, they have fulfilled the requirement. They haven’t. If you want to satisfy a Lead Auditor, you have to demonstrate that you understand the difference between who someone is and what they are allowed to do.
Think of it like a high-security building. Identity is the photo ID badge that proves you are Stuart Barker. Access Rights are the permissions programmed into that badge that let you into the server room but keep you out of the CEO’s office. If you don’t manage both separately and correctly, your security framework is built on a deck of cards.
Identity vs. Access Rights: The Key Differences
Use the following matrix to ensure your documentation and technical controls are aligned with the correct ISO 27001 requirements.
| Feature | Identity Management (A.5.16) | Access Rights (A.5.18) |
|---|---|---|
| Core Focus | The “Who”: Unique identification and verification of an entity. | The “What”: Granting, reviewing, and removing permissions. |
| Primary Goal | Accountability. Ensuring every action can be traced to a verified entity. | Confidentiality. Ensuring entities only see what they need to see. |
| Typical Action | Creating a username (e.g., sbarker) and verifying a passport. |
Adding sbarker to the “Finance-Read-Only” group. |
| Lifecycle Stage | Onboarding: Is this person who they say they are? | Operational: Does this person need this specific folder? |
| The Auditor’s Question | “Show me how you verified this person before giving them an ID.” | “Show me the business justification for this user having admin rights.” |
Why This Matters for Compliance
If you tell me that you manage identities by “giving everyone the same permissions,” you have failed. Identity management requires a unique digital representation for every single entity. Once that identity is established and verified, you then apply the controls of Access Rights to restrict them based on the Principle of Least Privilege.
If you don’t have a unique identity, your access rights are meaningless because you have no accountability. If you have a unique identity but no controlled access rights, you have no security. You must implement both to be compliant.
Lead Auditor Secret: When I look at your logs, I look for a unique ID. If I see a generic ID like
administratororuser1, I cannot prove who performed the action. That is an immediate red flag for A.5.16. Always tie a human or a specific service to every ID in the system.
Third-Party and Federated Identities
In a modern business, your perimeter does not stop at your front door. You likely have contractors, auditors, and partners who need access to your systems. Under Annex A 5.16, you are still responsible for their digital identity, even if you do not “own” their HR record. This is where many organisations trip up during an audit.
Managing External Entities
If you allow people to log in using their own company credentials (Federated Identity) or via social logins, you are still required to verify them. You cannot just “trust” that their company has done the work. You need a process to map their external identity to your internal security requirements.
- The Guest Lifecycle: Treat every external partner as a “Temporary Identity.” Their account should have a mandatory expiry date from day one. If the contract is for six months, the identity should automatically disable in 180 days unless a human sponsor extends it.
- Contractual Verification: Your contracts with third parties should explicitly state that they must notify you within 24 hours if a staff member who has access to your systems leaves their company. This is a critical link between Identity Management and Supplier Relationships (A.5.19).
The “Mover” Trap: Preventing Privilege Creep
Most people focus on Joiners and Leavers because they are easy to see. The “Mover” is the silent killer of security. When an employee moves from Finance to Marketing, they often keep their Finance identity attributes while gaining Marketing ones. Over time, you end up with “Super Users” who have access to everything because their identity was never cleaned up.
The Stuart Barker Mover Protocol
To pass your audit, you should demonstrate a “Zero Base” approach to role changes. When a user moves roles, their existing identity permissions should be revoked entirely and rebuilt from scratch based on the new business requirement. This ensures that no “toxic combinations” of access remain.
Interaction Modelling and Identity Mapping
For the highly technical or AI-driven companies, you should be looking at “Interaction Modelling.” This sounds like jargon, but it is actually quite simple. It involves mapping exactly how an identity (human or machine) interacts with your resources.
An auditor might ask: “How do you know that this specific API key is only being used for backups?” If you cannot show a map or a configuration file that binds that identity to that specific task, you have a gap. Effective identity management means you can prove that an identity is only doing what it was born to do.
Final Lead Auditor’s Evidence Checklist
Before you call in the certification body, make sure you have these five items of evidence physically ready to show. If you have to go looking for them during the audit, you have already lost the auditor’s confidence.
| Evidence Item | What I Am Looking For |
|---|---|
| Identity Register | A list of all active IDs, including service accounts and bots, with a named “Owner” for each. |
| Verification Records | Proof that you checked a passport, a certificate, or a digital signature before the ID was created. |
| The Leaver Log | A report showing people who left in the last 3 months and the exact timestamp their accounts were disabled. |
| Privileged Account Review | Minutes from a meeting where you reviewed your “Admins” and justified why they still have that power. |
| MFA Enforcement Report | A system export proving that 100 percent of your identities are protected by Multi Factor Authentication. |
The Final Word: Identity is the foundation of your entire ISMS. If you get this right, the rest of the technical controls fall into place. If you get it wrong, you are just waiting for a breach. Build your identity framework on rock, not sand.
ISO 27001 Annex A 5.16 FAQ
What is ISO 27001 Annex A 5.16?
ISO 27001 Annex A 5.16 is an organisational control that requires the full lifecycle of digital identities (users, devices, and services) to be managed to ensure secure identification and authentication.
- Establishes the “who” behind an access request.
- Covers the creation, maintenance, and deletion of unique identifiers.
- Ensures accountability by linking actions to a specific, verified identity.
- Distinguishes the identity itself from the permissions assigned to it.
What is the difference between Identity Management (5.16) and Access Rights (5.18)?
The primary difference is that Identity Management (5.16) focuses on “who” a user is, while Access Rights (5.18) focuses on “what” that verified user is allowed to do.
- Identity (5.16): Creating a unique username and verifying the person’s real-world identity.
- Access (5.18): Assigning roles, permissions, and “read/write” privileges to that identity.
- Relationship: You cannot securely manage access without first having a trusted identity management system.
Are shared accounts allowed under ISO 27001?
Generally, No. ISO 27001 requires individual accountability, meaning every user must have a unique identifier that is not shared with others.
- Shared accounts break the “Accountability” requirement of the standard.
- If a shared account is technically unavoidable, strict compensatory controls (like a vaulting system with individual check-outs) must be documented.
- Auditors will typically flag shared “admin” or “root” accounts as a non-conformity.
What is the Identity Lifecycle in ISO 27001?
The identity lifecycle refers to the formalised process of managing a digital identity from the moment of onboarding to the final revocation of access.
- Joiners: Verifying identity and provisioning unique IDs during onboarding.
- Movers: Updating identity attributes and verifying users during internal role changes.
- Leavers: Disabling or deleting identities immediately upon termination of employment.
- Review: Periodically confirming that the identity is still valid and necessary.
What is a Unique Identifier in the context of Annex A 5.16?
A unique identifier is a specific string of characters (like a username or employee ID) assigned to only one person or entity to ensure their actions can be traced back to them.
- It must never be reassigned to another person in the future.
- It should be used across all systems to provide a “Single Source of Truth.”
- It allows for granular logging and monitoring of user activity (Annex A 8.15).
What evidence do auditors expect for Identity Management?
Auditors expect to see a documented Topic-Specific Policy on Identity Management and a verifiable “audit trail” of the identity lifecycle.
- A User Register: A list of all active identities and their owners.
- Onboarding Logs: Evidence that identities were verified before IDs were issued.
- Termination Logs: Proof that identities were disabled promptly for leavers.
- Review Records: Evidence of periodic “re-certification” of identities.
Further Reading and Related ISO 27001 Controls
| Related ISO 27001 Control | Topic Relationship |
|---|---|
| Related ISO 27001 Control: 5.16 Implementation Guide | This is the technical sequence for securing your digital ecosystem. It provides the 10 step checklist to automate the identity lifecycle from registration to de-registration. Compliance depends on technically binding user accounts to HR records to eliminate unauthorized access gaps. |
| Related ISO 27001 Control: 5.16 Audit Checklist | Use this tool to verify your identity controls before the auditor arrives. It focuses on the lifecycle audit trail and evidence of identity verification. It is designed to confirm that your unique identifiers are verifiable and that leaver processes are triggered correctly. |
| Related ISO 27001 Control: Identity Management Glossary | This glossary entry defines the core concepts of identity management as a foundational technical process. It explains why identity is the digital persona of a user and how it acts as the master record for accountability logs within your Information Security Management System. |
| Related ISO 27001 Control: Annex A 5.15 Access Control | Identity management is the process of knowing who a user is. Access control is the process of deciding what they can do. You cannot manage access effectively without first having a trusted identity management system in place to prove the person is who they say they are. |
| Related ISO 27001 Control: Annex A 5.17 Authentication Info | This control governs the secrets used to verify the identities created in 5.16. Whether you use passwords, biometrics, or tokens, 5.17 ensures those secrets remain confidential. If you fail to manage authentication info, the identity itself becomes compromised and useless for audit. |
| Related ISO 27001 Control: Access Rights Guide | Access rights are the granular permissions linked to a unique identity. This page explains how to map permissions to the roles defined in your identity registry. It ensures that once an identity is verified, it only has the minimum level of access required to perform its function. |
| Related ISO 27001 Control: Annex A 8.5 Secure Authentication | This is the technical enforcement of identity verification at the point of access. It advocates for a risk based approach where identity is proven through Multi Factor Authentication. It is the technical shield that protects the identity lifecycle managed under 5.16. |
| Related ISO 27001 Control: RBAC Glossary | Managing individual identities is an audit nightmare. This guide shows you how to use role based logic to manage groups of identities. By assigning permissions to roles rather than people, you reduce the risk of privilege creep and simplify the identity maintenance process. |
| Related ISO 27001 Control: A 5.16 for AI Companies | AI organizations face unique risks with non-human identities. This guide explains how to manage the identities of automated services, bots, and systems that interact with sensitive training data. It is a specialized application of the 5.16 control for modern tech stacks. |
| Related ISO 27001 Control: Annex A Reference List | This is the master list of all 93 controls in the 2022 standard. It places identity management within the broader context of organizational and technical security. It is the starting point for building your Statement of Applicability and selecting your core security safeguards. |
ISO 27001 Annex A 5.18 Access Rights
ISO 27001 Clause 6.1.3 Information Security Risk Treatment
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 |
About the author
