1. Purpose
The purpose of this Identity Management Policy is to establish requirements for creating, managing, authenticating, reviewing, modifying, and removing identities used to access organizational information, systems, applications, cloud environments, and services.
The policy ensures that:
- Every user has an appropriately managed identity.
- Identities are uniquely attributable to individuals or approved system functions.
- Access is granted based on business need and authorized roles.
- Authentication mechanisms are appropriately protected.
- Privileged identities receive additional controls.
- Identity changes are managed throughout the user lifecycle.
- Inactive, obsolete, or unauthorized identities are identified and removed.
- Identity-related activities can be evidenced for security and audit purposes.
Core principle:
One identity → Verified user → Appropriate authentication → Authorized access → Monitoring → Periodic review → Timely removal
2. Scope
This policy applies to:
- Employees
- Contractors
- Consultants
- Interns
- Temporary personnel
- Third-party users
- Administrators
- Privileged users
- Service accounts
- Application identities
- Machine identities
- API identities
- Cloud identities
- Emergency/break-glass accounts
It covers identities associated with:
- Corporate networks
- Identity providers and SSO
- Email and collaboration systems
- SaaS applications
- AWS, Azure, GCP and other cloud platforms
- Servers and databases
- Source-code repositories
- CI/CD platforms
- Security platforms
- VPN and remote-access systems
- Customer environments
- Business applications
- APIs and integrations
3. Identity Management Principles
Identity management shall follow these principles:
3.1 Unique Identity
Where technically and operationally feasible, each individual shall use a unique identity.
Shared personal accounts should not be used.
3.2 Business Need
An identity should exist only where there is a legitimate business or technical requirement.
3.3 Least Privilege
An identity should receive only the permissions required to perform its approved responsibilities.
3.4 Individual Accountability
Actions performed using an identity should be attributable to the responsible person or approved system.
3.5 Strong Authentication
Appropriate authentication controls, including MFA where required, shall be implemented based on risk and system requirements.
3.6 Lifecycle Management
Identities shall be managed from creation through modification, periodic review, suspension, and removal.
3.7 Privileged Identity Protection
Administrative and privileged identities shall receive additional security controls.
3.8 Traceability
Identity creation, changes, privileged activities, and removal should be supported by appropriate records and evidence.
4. Identity Types
The organization may maintain different types of identities.
| Identity Type | Example | Typical Use |
|---|---|---|
| Employee Identity | employee@company.com | Normal employee access |
| Contractor Identity | contractor@company.com | Temporary/contract work |
| Third-Party Identity | auditor@partner.com | External access |
| Privileged Identity | admin account | Administrative activity |
| Service Account | svc-backup | Automated service |
| Application Identity | application role | Application-to-system access |
| API Identity | API credential | System integration |
| Machine Identity | workload identity | Automated workload |
| Emergency Identity | break-glass account | Emergency recovery |
The organization should apply appropriate controls based on the risk associated with each identity type.
5. Identity Creation
Identity creation shall follow an authorized process.
Standard Process
Business Need → Identity Request → Verification → Approval → Creation → Authentication Setup → Access Provisioning → Verification → Record
Before creating an identity, the organization should establish:
- Identity owner
- User/person or system associated with the identity
- Business purpose
- Required systems
- Required access level
- Start date
- Expiry date where applicable
- Approver
- System owner
- Security requirements
Identity creation should be supported by an approved request or equivalent authorization record.
6. User Identity Verification
Before creating an employee, contractor, or third-party identity, appropriate verification should be performed according to organizational requirements.
Verification may include:
- HR records
- Contract/SOW
- Manager confirmation
- Supplier confirmation
- Identity verification
- Engagement start date
- Business role
- Internal sponsor
Higher-risk or privileged identities may require additional verification.
7. Joiner Identity Management
For new personnel:
- HR or the responsible function notifies IT/IAM.
- The person’s role and department are identified.
- Required systems are determined.
- Access requirements are approved.
- Identity is created.
- Authentication is configured.
- Required access is provisioned.
- MFA is enabled where required.
- Security responsibilities are communicated.
- Provisioning is verified and recorded.
Identity creation should not automatically provide broad access.
8. Mover Identity Management
When a person changes role, department, project, or responsibilities:
Role Change → Review Existing Identity/Access → Remove Unnecessary Access → Approve New Access → Provision → Verify
The organization should not simply add new permissions without reviewing the person’s existing access.
This helps prevent privilege accumulation.
Example:
A developer moves into a customer-support role. Their new CRM access is approved, but their previous production AWS administrative access must also be reviewed and removed if no longer required.
9. Leaver Identity Management
When employment or an engagement ends:
- Exit notification is received.
- Identity and access are identified.
- Accounts are disabled or removed according to the required timeline.
- Active sessions are terminated where applicable.
- MFA tokens and authentication methods are revoked.
- API keys, SSH keys, certificates, and tokens are reviewed.
- Privileged access is removed.
- SaaS and cloud access is revoked.
- Physical access is removed.
- Organizational assets are recovered.
- Business responsibilities are transferred.
- Completion is verified and recorded.
Disabling email alone is not sufficient.
Cloud, SaaS, VPN, source-code, database, API, and privileged access must also be considered.
10. Authentication
Authentication mechanisms shall be selected according to the sensitivity and risk of the system.
Controls may include:
- Passwords
- Multi-factor authentication
- Security keys
- Authenticator applications
- Single Sign-On
- Federation
- Certificates
- Managed device authentication
- Workload identities
- Short-lived credentials
Authentication information shall be protected from unauthorized disclosure.
11. Multi-Factor Authentication
MFA should be enabled for systems and identities where required by:
- Risk assessment
- Security requirements
- Customer requirements
- Contractual obligations
- Regulatory requirements
- Organizational policy
MFA should receive particular attention for:
- Privileged accounts
- Cloud administration
- Identity-provider administration
- Remote access
- Production systems
- Security platforms
- Sensitive SaaS applications
12. Single Sign-On
Where appropriate, the organization may use an Identity Provider (IdP) and SSO to centralize authentication.
Examples include:
- Microsoft Entra ID
- Okta
- Google Workspace
- Other approved identity providers
SSO can provide centralized:
- Authentication
- MFA
- Account lifecycle management
- Access control
- Logging
- Session management
- Offboarding
However, applications that are not integrated with SSO must still have appropriate identity lifecycle controls.
13. Role-Based Identity Management
Where practical, access should be associated with defined organizational roles.
Example:
| Role | Typical Access |
|---|---|
| Developer | Development environment, source code |
| Support | Customer support platform |
| Finance | Finance applications |
| HR | HR applications |
| Security | Security monitoring tools |
| DevOps | Cloud infrastructure |
| CTO | Approved administrative functions |
Role definitions should not automatically grant excessive permissions.
The actual access assigned should reflect business need and risk.
14. Privileged Identities
Privileged identities include accounts with elevated permissions such as:
- Cloud administrators
- Database administrators
- Security administrators
- Identity administrators
- Network administrators
- Source-code administrators
- SaaS administrators
Privileged identities should be:
- Individually attributable
- Business justified
- Specifically approved
- Protected with appropriate authentication
- Limited to required permissions
- Monitored where appropriate
- Periodically reviewed
- Removed when no longer required
Where practical, administrative activities should use a separate privileged identity rather than using an administrator-level identity for routine activities.
15. Service and Application Identities
Service accounts and application identities shall have:
- Defined purpose
- Identified owner
- Defined permissions
- Appropriate credential protection
- Appropriate credential rotation
- Restricted access
- Monitoring where appropriate
- Documented dependencies
- Periodic review
Service accounts should not be used as substitutes for individual user identities.
Interactive login should be disabled where it is not required.
16. API Keys, Tokens and Certificates
API credentials, tokens, SSH keys, certificates, and similar machine credentials shall be treated as identity credentials.
Where applicable:
- Store secrets in approved secret-management systems.
- Do not store credentials in source code.
- Restrict permissions.
- Use expiration dates where supported.
- Rotate credentials according to risk and system requirements.
- Revoke compromised credentials promptly.
- Track ownership.
- Review unused credentials.
Examples include:
- AWS access keys
- API tokens
- OAuth credentials
- SSH keys
- TLS certificates
- CI/CD secrets
17. Cloud Identity Management
Cloud identities shall be managed using the organization’s approved cloud identity model.
AWS Example
A startup may use:
Identity Provider → SSO → AWS IAM Identity Center → Assigned Role → AWS Account/Resource
Controls may include:
- Individual identities
- SSO
- MFA
- IAM roles
- Least privilege
- Temporary credentials
- Separate production/development access
- CloudTrail logging
- Periodic access reviews
- Privileged access controls
Long-lived AWS access keys should be avoided where an alternative such as role-based or federated access is practical.
18. Application Identity Management
Applications should have defined ownership and appropriate identity controls.
The organization should consider:
- User authentication
- Administrative accounts
- Role-based access
- MFA
- Session management
- Account lockout or protective controls
- Dormant accounts
- Service accounts
- API identities
- Logging
- Access review
Application owners are responsible for ensuring that identity requirements are appropriately implemented.
19. Third-Party Identities
Third-party identities shall be managed through the Third-Party Access Procedure.
Before granting access, consider:
- Business need
- Third-party identity
- Internal sponsor
- Contract/SOW
- NDA/confidentiality
- Data accessed
- System criticality
- Privilege level
- Start date
- Expiry date
- MFA
- Monitoring
- Review requirements
Third-party identities should normally have a defined expiry or review point.
20. Temporary Identities and Access
Temporary identities or access should have:
- Defined business purpose
- Named user
- Approver
- Start date
- Expiry date
- Appropriate permissions
- Monitoring where required
- Revocation process
Temporary access should not become permanent through lack of review.
21. Emergency / Break-Glass Identities
Emergency identities may be maintained for critical recovery or operational situations.
They should have:
- Defined purpose
- Restricted access
- Strong authentication
- Secure credential storage
- Limited use
- Appropriate monitoring
- Emergency-use logging
- Periodic testing
- Periodic review
- Immediate review after use
Use of a break-glass identity should trigger an appropriate review.
22. Dormant and Inactive Identities
The organization should identify inactive identities periodically.
Potential actions include:
- Disable
- Remove
- Confirm business need
- Transfer ownership
- Reset authentication
- Investigate unexpected activity
The appropriate inactivity threshold should be defined based on system risk and business requirements rather than copied as a universal value.
23. Identity and Access Review
Identity information and associated access shall be periodically reviewed.
The review should consider:
- Active users
- Former users
- Role changes
- Privileged identities
- Third-party identities
- Temporary identities
- Service accounts
- Dormant accounts
- MFA status
- Access appropriateness
- SoD conflicts
Results should be documented in an Access Review Report.
24. Identity Ownership
Each important identity type or identity system should have an accountable owner.
| Identity Area | Typical Owner |
|---|---|
| Corporate IdP | IT / Security |
| Employee Identity | HR + IT |
| Application Identity | Application Owner |
| AWS Identity | Cloud/IT Owner |
| Privileged Identity | System Owner / Security |
| Service Account | Application Owner |
| Third-Party Identity | Internal Sponsor |
| API Credential | Application/System Owner |
Ownership should be clearly documented.
25. Identity Security Monitoring
Where appropriate, identity-related events should be logged and monitored.
Examples include:
- Successful authentication
- Failed authentication
- MFA failures
- Privileged login
- New identity creation
- Privilege changes
- Password changes
- MFA changes
- Account disablement
- Unusual login activity
- API credential use
- Administrative actions
Monitoring requirements should be based on system risk and organizational requirements.
26. Identity-Related Incidents
Potential identity incidents include:
- Compromised credentials
- Stolen authentication tokens
- Unauthorized account creation
- Privilege escalation
- MFA bypass
- Suspicious login
- Shared credentials
- Lost authentication device
- Exposed API key
- Compromised service account
Such events shall be handled through the organization’s Incident Response and Security Incident Management processes.
27. Identity Changes
Identity changes should be controlled through an approved process.
Examples:
- Name changes
- Department changes
- Role changes
- Employment status changes
- Contractor status changes
- Privilege changes
- Account ownership changes
- Service-account ownership changes
Changes should be reflected in relevant identity and access records.
28. Shared Accounts
Shared accounts should generally be avoided because they reduce individual accountability.
Where a shared identity is technically necessary:
- Business justification should be documented.
- Appropriate approval should be obtained.
- Access should be restricted.
- Credentials should be protected.
- Use should be logged where technically possible.
- Ownership should be assigned.
- The account should be periodically reviewed.
29. Identity Data Protection
Identity information such as usernames, authentication records, employee identifiers, contact information, and authentication metadata should be protected according to its classification and applicable privacy requirements.
Authentication secrets must receive stronger protection than ordinary identity information.
30. Identity Records
The organization should maintain appropriate records such as:
- Identity register
- User Access Request
- Access Control Matrix
- Privileged Access Register
- JML records
- Third-Party Access Register
- Service Account Register
- Access Review Report
- Access Revocation records
- Authentication configuration
- Identity-related audit logs
Records should be retained according to applicable organizational and legal requirements.
31. Exceptions
Any exception to this policy should:
- Be documented.
- Have a business justification.
- Identify associated risk.
- Define compensating controls where appropriate.
- Have an accountable owner.
- Have an appropriate approval.
- Include an expiry or review date where appropriate.
Exceptions should not become permanent without periodic review.
32. Roles and Responsibilities
Management
- Provide appropriate resources.
- Support identity governance.
- Review significant identity risks.
IT / IAM
- Create and manage identities.
- Configure authentication.
- Manage identity systems.
- Implement approved access.
- Disable or remove identities.
Security / ISMS
- Define security requirements.
- Monitor identity-related risks.
- Review privileged access.
- Support access reviews.
- Investigate identity-related incidents.
HR / People
- Provide accurate joiner, mover, and leaver information.
- Notify relevant teams of personnel changes.
System Owners
- Define appropriate access.
- Approve access where responsible.
- Review system identities.
- Support periodic access reviews.
Managers
- Confirm business need.
- Request and approve appropriate access.
- Notify IT of role changes and departures.
Users
- Protect authentication information.
- Never share credentials.
- Report suspected compromise.
- Use only assigned identities.
33. AWS SaaS Startup Example
Consider a 40-person SaaS company operating its platform on AWS.
Identity Model
Employee → Microsoft Entra ID → SSO/MFA → Application/AWS Role → Authorized Resource
Examples:
| User | Identity | Access |
|---|---|---|
| Developer | Corporate SSO | Development AWS account |
| DevOps Engineer | Corporate SSO | Approved production role |
| Support Agent | Corporate SSO | Customer support application |
| Security Lead | Corporate SSO | Security tooling |
| External VAPT Consultant | Named third-party identity | Temporary approved testing access |
The company maintains:
- Central identity provider
- MFA
- AWS roles
- Privileged Access Register
- JML Procedure
- Third-Party Access Procedure
- Periodic Access Review
- Access Revocation process
- CloudTrail logging
When a developer becomes a manager, their old developer permissions are reviewed rather than simply adding manager permissions.
When an employee leaves, the organization disables the corporate identity and separately verifies AWS, GitHub, SaaS, VPN, production, API, and other access.
34. Identity Management Evidence
An auditor may request evidence such as:
- Identity register
- User list
- HR-to-identity reconciliation
- Access requests
- Approval records
- SSO configuration
- MFA configuration
- Privileged Access Register
- Service account register
- Third-party access records
- JML records
- Access review reports
- Access revocation records
- AWS IAM/Identity Center configuration
- CloudTrail logs
- Application access logs
- Break-glass account review
- Exception records
- Identity-related incident records
The organization should retain evidence appropriate to its risk and requirements.
35. Common Implementation Mistakes
Mistake 1: Creating accounts without approval
Better: Business need → Approval → Creation.
Mistake 2: Giving access based only on job title
Two employees with the same title may have different business requirements.
Mistake 3: Adding new access without removing old access
This creates privilege accumulation.
Mistake 4: Treating email disablement as complete offboarding
Cloud, SaaS, source-code, VPN, database, API and privileged access must also be reviewed.
Mistake 5: Using shared administrator accounts
This reduces accountability.
Mistake 6: Ignoring service accounts
Machine identities can have significant privileges and require ownership and review.
Mistake 7: Forgetting API keys and tokens
Digital identities are not limited to usernames and passwords.
Mistake 8: Granting permanent third-party access
External access should be controlled throughout its lifecycle.
Mistake 9: Keeping dormant accounts indefinitely
Inactive identities can become an unnecessary attack path.
Mistake 10: Failing to retain evidence
An organization may have good identity controls but still struggle to demonstrate their operation without records.
36. Startup-Friendly Identity Management Model
A startup does not necessarily need a large IAM platform to establish effective identity governance.
A practical minimum model can include:
1. Central Identity Provider
Use an appropriate IdP/SSO platform.
2. MFA
Protect important systems, especially privileged access.
3. JML Process
Control Joiner → Mover → Leaver activities.
4. Access Control Matrix
Define who should access what.
5. Privileged Access Register
Track administrative identities.
6. Third-Party Access Register
Track external identities.
7. Periodic Access Review
Compare actual access with approved requirements.
8. Access Revocation
Remove access promptly when business need ends.
9. Evidence
Maintain approval, provisioning, review, and revocation records.
This provides a practical foundation without turning identity management into an unnecessary documentation exercise.
37. Quick Identity Management Checklist
- Every important identity has an owner
- Unique user identities are used where practical
- Identity creation requires authorization
- Business purpose is documented
- Appropriate authentication is implemented
- MFA is enabled where required
- Privileged identities are separately controlled
- Service accounts have owners
- API keys and tokens are controlled
- Third-party identities are tracked
- Temporary access has expiry/review
- Joiners are provisioned appropriately
- Movers have old access reviewed
- Leavers have access revoked
- Dormant identities are reviewed
- Access is periodically reviewed
- Identity-related events are monitored where appropriate
- Exceptions are documented
- Evidence is retained
38. Relationship with Other ISMS Documents
Identity Management works together with:
Identity Management Policy
↓
Access Control Policy
↓
Access Control Matrix
↓
User Access Request
↓
JML Procedure
↓
Privileged Access Register
↓
Third-Party Access Procedure
↓
Access Review Report
↓
Access Revocation Checklist
↓
Incident Management
Supporting records include:
- Information & Asset Inventory
- Cloud Asset Inventory
- SaaS Application Register
- Information Classification Policy
- Segregation of Duties Policy
- Employee Offboarding Checklist
- Contractor Offboarding Checklist
- Risk Register
39. ISO 27001 Connection
Identity management supports applicable ISO/IEC 27001 requirements relating to:
- Identity management
- Authentication information
- Access rights
- Access restriction
- Privileged access
- Segregation of duties
- Access review
- Supplier and third-party access
- Logging and monitoring where applicable
The organization should determine the exact controls applicable to its ISMS through its risk assessment and Statement of Applicability (SoA).
40. Audit Trail
An auditor should be able to trace:
Person/System → Identity → Business Need → Approval → Authentication → Access → Review → Change → Revocation → Evidence
For example:
Employee joins
→ HR notification
→ Identity created
→ Manager approves required access
→ SSO + MFA configured
→ Application/AWS access provisioned
→ Evidence retained
→ Periodic access review
Employee changes role
→ HR notification
→ Existing access reviewed
→ Unnecessary access removed
→ New access approved
→ New access provisioned
→ Review evidence retained
Employee leaves
→ Exit notification
→ Identity identified
→ Access revoked
→ Sessions/tokens reviewed
→ Assets recovered
→ Responsibilities transferred
→ Revocation verified
→ Evidence retained
Final Principle
Identity management is not simply creating user accounts. It is ensuring that every identity is known, justified, appropriately authenticated, properly authorized, periodically reviewed, and removed when it is no longer required.