What is ISO 27001 Annex A 5.16 – Identity Management?
ISO 27001 Annex A 5.16 – Identity Management is about managing the complete lifecycle of identities used to access an organization’s information and systems.
In simple terms:
The organization should know who each digital identity belongs to, what that identity is used for, where it is used, and when it should be created, changed, disabled, or removed.
Identity management goes beyond simply creating usernames and passwords.
It covers the lifecycle of:
- Employees
- Contractors
- Consultants
- Temporary workers
- Vendors
- Administrators
- Service accounts
- Application accounts
- Other system or machine identities
Identity management typically includes:
Create → Assign → Use → Change → Review → Disable → Remove
Simple Explanation
A.5.16 ensures that every important digital identity is properly created, managed, monitored, and removed throughout its lifecycle.
Why is A.5.16 Important?
Access control determines what a user can access.
Identity management helps determine who that user actually is.
If an organization does not properly manage identities, several problems can occur.
For example:
- An employee leaves but their account remains active.
- Two employees share the same account.
- A contractor receives a permanent account.
- An employee changes departments but keeps old permissions.
- A service account has no identifiable owner.
- A dormant account is forgotten.
- An administrator creates multiple unmanaged accounts.
- A user has several identities across different systems that are not properly controlled.
These situations make it difficult to answer:
“Who actually performed this action?”
They can also increase the risk of unauthorized access and reduce accountability.
Simple Principle
Every important identity should have an owner, a purpose, appropriate access, and a defined lifecycle.
What Does A.5.16 Require?
The organization should manage identities throughout their lifecycle.
This includes processes for:
- Identity creation
- Identity registration
- Identity modification
- Identity maintenance
- Identity review
- Identity suspension
- Identity removal
The organization should also consider different types of identities.
Human identities
Examples:
- Employees
- Contractors
- Consultants
- Interns
- Temporary workers
Non-human identities
Examples:
- Service accounts
- Application accounts
- API identities
- Automation accounts
- Machine identities
Non-human identities are particularly important in modern cloud and SaaS environments.
Identity vs. Access
These concepts should not be confused.
Identity
Answers:
Who or what is this?
Example:
rahul.sharma@company.com
Access
Answers:
What is this identity allowed to do?
Example:
Rahul has:
- GitHub Developer access
- Jira access
- AWS Development access
- No production administrator access
Therefore:
Identity = Who you are
Access = What you are allowed to do
A.5.16 focuses primarily on managing the identity.
A.5.15 and A.5.18 address access-control and access-rights aspects.
Types of Identities
1. Employee Identities
Every employee should normally have an individually identifiable account.
Example:
rahul.sharma@company.com
rather than:
developer@company.com
being shared by multiple people.
2. Contractor Identities
Contractors should have individually identifiable accounts wherever practical.
Their identities should have:
- An owner
- Business justification
- Start date
- Expected end date
- Appropriate access
- Review requirements
3. Vendor Identities
External vendors may need access to company systems.
For example:
- Managed IT provider
- Security consultant
- Cloud consultant
- External auditor
Their accounts should be controlled and removed when the relationship or business need ends.
4. Privileged Identities
Administrative identities require stronger controls.
Examples:
- Cloud administrator
- Database administrator
- Domain administrator
- Security administrator
Where appropriate, administrative privileges should be separated from normal user accounts.
For example:
rahul.sharma@company.com
Normal account
and
rahul.admin@company.com
Privileged administrative account.
5. Service Accounts
A service account is used by an application, service, automation process, or system rather than a human.
Examples:
- Application connecting to a database
- Backup service
- Monitoring service
- CI/CD pipeline
- Automated integration
A service account should have:
- Defined purpose
- Identifiable owner
- Appropriate permissions
- Credential protection
- Lifecycle management
- Periodic review
6. API and Machine Identities
Modern SaaS environments may use:
- API keys
- OAuth applications
- Service principals
- Cloud roles
- Machine certificates
- Workload identities
These should also have ownership and lifecycle controls.
Identity Lifecycle
A practical identity lifecycle is:
1. Request
A new identity is requested.
↓
2. Verify
The person or system is verified.
↓
3. Approve
Appropriate authorization is obtained.
↓
4. Create
The identity is created.
↓
5. Assign
Appropriate access and attributes are assigned.
↓
6. Review
The identity is periodically reviewed.
↓
7. Modify
Changes are made when responsibilities change.
↓
8. Disable
The identity is disabled when temporarily unnecessary.
↓
9. Remove
The identity is permanently removed when no longer required.
Activities Required to Implement A.5.16
Step 1: Identify All Identity Types
Start by identifying where identities exist.
Examples:
- Microsoft Entra ID
- Google Workspace
- AWS IAM
- GitHub
- GitLab
- Jira
- CRM
- ERP
- HR system
- VPN
- Databases
- Security tools
- SaaS applications
Do not limit the exercise to employee accounts.
Step 2: Create an Identity Inventory
Maintain a register of important identities.
Example:
| Identity | Type | Owner | System | Status |
|---|---|---|---|---|
| Rahul Sharma | Employee | HR/Manager | Entra ID | Active |
| Priya Singh | Employee | HR/Manager | Google Workspace | Active |
| Security Consultant | Contractor | CISO | VPN | Active |
| Backup Service | Service Account | IT | AWS | Active |
| CI/CD Pipeline | Machine Identity | Engineering | GitHub/AWS | Active |
Step 3: Define Identity Creation Rules
Define who can create identities and under what conditions.
For example:
Employee
HR creates employee record.
↓
IT/IAM creates corporate identity.
↓
Manager confirms role.
↓
Access is assigned according to approved requirements.
Contractor
Business owner requests account.
↓
Manager approves.
↓
System owner approves access.
↓
Account is created with an expiry date.
Step 4: Use Unique Identities
Users should generally have individually identifiable identities.
Avoid unnecessary shared accounts.
Instead of:
developer@company.com
use individual accounts such as:
rahul@company.com
priya@company.com
This improves:
- Accountability
- Auditability
- Access reviews
- Incident investigation
- Offboarding
Step 5: Define Identity Attributes
Depending on the organization’s environment, identities may contain:
- Name
- Employee ID
- Department
- Job title
- Manager
- Employment status
- Location
- User type
- Start date
- End date
- Privileged status
These attributes can support automated access management.
Step 6: Connect Identity Management With HR
For employees, HR is often the authoritative source for:
- Joining
- Department changes
- Promotions
- Transfers
- Termination
A practical workflow can be:
HR → Identity System → Access Management
This reduces the risk of IT not being informed about employee changes.
Step 7: Manage Joiners, Movers, and Leavers
Joiner
New employee joins.
→ Create identity.
→ Assign appropriate access.
Mover
Employee changes role.
→ Update identity attributes.
→ Review existing access.
→ Remove unnecessary permissions.
→ Grant new permissions.
Leaver
Employee leaves.
→ Disable identity.
→ Revoke sessions/tokens where appropriate.
→ Remove access.
→ Retain required records.
Step 8: Manage Service Accounts
Every important service account should have:
- Owner
- Purpose
- System
- Permissions
- Creation date
- Review date
- Credential-management method
- Status
Example:
| Service Account | Owner | Purpose | Privilege | Review |
|---|---|---|---|---|
backup-prod | IT | Production backup | Limited | Quarterly |
app-db-prod | Engineering | Application database connection | Limited | Quarterly |
cicd-deploy | DevOps | Deployment automation | Controlled | Quarterly |
Step 9: Manage Dormant Accounts
Organizations should identify accounts that are:
- Unused
- Dormant
- Forgotten
- No longer required
- Associated with former employees
- Associated with completed projects
Appropriate action may include:
- Disable
- Investigate
- Reassign ownership
- Remove
Step 10: Periodically Review Identities
Identity reviews should confirm:
- Does this identity still need to exist?
- Does the owner still exist?
- Is the identity still being used?
- Is the identity type correct?
- Is the purpose still valid?
- Should the identity be disabled or removed?
Startup Example
Consider a SaaS startup with 60 employees.
The company uses:
- Google Workspace
- GitHub
- AWS
- Jira
- Slack
- CRM
The company has employees, contractors, and service accounts.
New Employee
HR creates the employee record.
↓
IT creates:
rahul.sharma@company.com
↓
Manager confirms role.
↓
Appropriate applications are provisioned.
↓
MFA is enabled.
Employee Changes Role
Rahul moves from Developer to Engineering Manager.
↓
HR updates role.
↓
Manager requests role change.
↓
Old access is reviewed.
↓
Unnecessary development access is removed.
↓
New management access is granted.
Employee Leaves
HR records termination.
↓
Identity is disabled.
↓
Sessions/tokens are revoked where appropriate.
↓
Application access is removed.
↓
Privileged access is removed.
↓
Identity record is updated.
This demonstrates the identity lifecycle.
Identity Management for a Small Startup
A startup does not necessarily need an expensive Identity Governance and Administration platform on day one.
A practical approach could use:
- Google Workspace or Microsoft Entra ID
- HR system
- Access request form
- Access matrix
- Identity register
- MFA
- Periodic access review
As the company grows, automation can be introduced.
Example Identity Register
| Identity | Type | Owner | Start Date | End Date | Status | Last Review |
|---|---|---|---|---|---|---|
| Rahul Sharma | Employee | Engineering | 01-Jan-2026 | N/A | Active | 01-Sep-2026 |
| Priya Singh | Employee | Finance | 15-Feb-2026 | N/A | Active | 01-Sep-2026 |
| ABC Security Consultant | Contractor | CISO | 01-Aug-2026 | 30-Sep-2026 | Active | 01-Sep-2026 |
| CI/CD Pipeline | Machine | DevOps | 01-Mar-2026 | N/A | Active | 01-Sep-2026 |
| Old Vendor Account | Vendor | IT | 01-Jan-2025 | 31-Dec-2025 | Disabled | 01-Jan-2026 |
Example Identity Request
New Identity Request
Name: Rahul Sharma
Identity Type: Employee
Department: Engineering
Manager: Engineering Manager
Start Date: 01 October 2026
Required Systems: GitHub, Jira, Google Workspace
Privileged Access: No
Identity Owner: IT/IAM
Approval: Engineering Manager
Status: Approved
This provides an auditable record of identity creation.
Startup-Focused Quick Summary
A startup can implement A.5.16 with seven basic rules:
1. Give people unique identities
Avoid unnecessary shared accounts.
2. Know who owns each identity
Every important account should have an accountable owner.
3. Define why the identity exists
This is especially important for service and contractor accounts.
4. Connect identity management with HR
Employee lifecycle changes should trigger identity changes.
5. Set expiry dates for temporary identities
Especially for contractors and temporary access.
6. Review dormant and unnecessary identities
Disable or remove accounts that are no longer required.
7. Remove identities when the relationship ends
Leavers should not retain active organizational identities.
Simple Startup Rule
Every identity should have a person or owner, a purpose, an appropriate lifecycle, and a defined status.
Audit Evidence for A.5.16
An auditor may ask:
“How do you manage user identities throughout their lifecycle?”
Useful evidence includes:
Policies
- Identity Management Policy
- Access Control Policy
- User Account Management Policy
Procedures
- User Account Creation Procedure
- Joiner-Mover-Leaver Procedure
- Contractor Account Procedure
- Service Account Procedure
Registers
- User Account Register
- Identity Inventory
- Service Account Register
- Privileged Account Register
- Contractor Register
Technical Evidence
- Microsoft Entra ID / Active Directory
- Google Workspace
- IAM configuration
- SSO configuration
- Identity lifecycle workflows
- MFA configuration
- Account status reports
Operational Evidence
- Account creation requests
- Approval records
- Account modification records
- Account disablement records
- Termination records
- Periodic identity reviews
A.5.16 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Is there an identity management policy? | Policy |
| Are unique user identities provided? | IAM records |
| Are shared accounts restricted or controlled? | Account register |
| Is there a defined identity lifecycle? | Procedure |
| Are new identities formally requested and approved? | Access requests |
| Are identity attributes maintained? | IAM/HR records |
| Are employee role changes reflected in identities? | Mover records |
| Are contractor identities controlled? | Contractor register |
| Are temporary identities assigned expiry dates? | IAM records |
| Are service accounts identified and owned? | Service account register |
| Are dormant accounts identified? | Account review |
| Are former employee accounts disabled? | Offboarding evidence |
| Are identities periodically reviewed? | Review records |
| Are privileged identities separately controlled? | Privileged account register |
| Can identity activity be traced to an identifiable user or system? | Logs |
Common Mistakes in A.5.16
1. Shared User Accounts
Several employees use one account.
This reduces individual accountability and makes investigations more difficult.
2. No Identity Owner
A service account exists but nobody knows who is responsible for it.
Every important non-human identity should have an accountable owner.
3. Contractor Accounts Never Expire
A contractor finishes a project but their identity remains active indefinitely.
Temporary identities should have appropriate lifecycle controls.
4. HR and IT Are Not Connected
HR knows an employee has left.
IT does not.
This can result in active accounts remaining after termination.
5. Role Changes Are Ignored
An employee changes from developer to finance manager but retains unnecessary development and production access.
Identity changes should trigger access reviews.
6. Too Many Service Accounts
Organizations sometimes create service accounts whenever convenient and never clean them up.
This creates an unmanaged identity population.
7. No Unique Administrative Identity
Employees use their normal account for daily activities and administrative tasks.
Where appropriate, administrative activity should be separated and strongly controlled.
8. No Periodic Review
An organization may have thousands of identities but no process for determining whether they are still required.
9. Identity Register Does Not Match Reality
The spreadsheet says an account is disabled, but the actual system shows it as active.
Auditors may test the actual system configuration.
10. Treating Identity Management as Only Password Management
Identity management is much broader.
It covers the complete identity lifecycle, not just passwords.
Practical Startup Implementation Model
A simple startup implementation is:
Identify → Create → Assign → Use → Review → Modify → Disable → Remove
Identify
Determine who or what requires an identity.
↓
Create
Create a unique identity.
↓
Assign
Assign owner, role, attributes, and appropriate access.
↓
Use
Use the identity for authorized activities.
↓
Review
Periodically review whether it is still required.
↓
Modify
Update it when roles or responsibilities change.
↓
Disable
Disable it when temporarily or permanently no longer required.
↓
Remove
Delete or retire it when appropriate.
Policy vs. Process vs. Evidence
| Component | Example |
|---|---|
| Policy | Defines identity-management principles |
| Identity Standard | Defines unique identities, ownership, lifecycle |
| Procedure | Explains how identities are created and managed |
| Identity Register | Records important identities |
| Service Account Register | Records non-human identities |
| JML Process | Joiner, Mover, Leaver lifecycle |
| Technical Controls | IAM, SSO, MFA, automated provisioning |
| Review | Periodic identity review |
| Evidence | Creation, modification, disablement, and removal records |
Relationship with Other ISO 27001 Controls
A.5.15 – Access Control
Establishes the overall rules for controlling access.
A.5.16 – Identity Management
Manages identities throughout their lifecycle.
A.5.17 – Authentication Information
Protects information used to authenticate identities.
A.5.18 – Access Rights
Controls the provisioning, review, modification, and removal of access rights.
A.6.5 – Responsibilities After Termination or Change of Employment
Addresses security responsibilities when employment changes or ends.
A.8.2 – Privileged Access Rights
Provides additional controls for privileged identities.
A.8.5 – Secure Authentication
Supports secure authentication mechanisms for identities.
Useful Resources
Recommended Documents
- [Insert Draft Document Link – Identity Management Policy]
- [Insert Draft Document Link – User Account Management Procedure]
- [Insert Draft Document Link – Joiner-Mover-Leaver Procedure]
- [Insert Draft Document Link – Identity Register]
- [Insert Draft Document Link – Service Account Register]
- [Insert Draft Document Link – Contractor Account Procedure]
- [Insert Draft Document Link – Privileged Identity Management Procedure]
- [Insert Draft Document Link – Identity Review Checklist]
Final Takeaway
ISO 27001 Annex A 5.16 is about ensuring that organizational identities are properly created, maintained, reviewed, changed, disabled, and removed throughout their lifecycle.
A useful way to remember the control is:
A.5.15 – Who should have access?
A.5.16 – Who or what is the identity?
A.5.17 – How is the identity authenticated?
A.5.18 – What access rights does the identity have?
For a startup, the core requirements are straightforward:
- Give users unique identities.
- Know who owns each identity.
- Define why each identity exists.
- Control employee and contractor lifecycle changes.
- Manage service and machine identities.
- Review dormant identities.
- Remove identities when no longer required.
The practical lifecycle is:
Create → Assign → Use → Review → Modify → Disable → Remove
The key audit question is:
“Can you demonstrate that every important identity is known, owned, appropriately managed, and removed or disabled when it is no longer required?”
If the answer can be demonstrated with both documented processes and actual system evidence, the organization has a practical foundation for A.5.16.