1. Purpose

The Identity Register is a centralized record of identities used to access the organization’s information, systems, applications, cloud environments, SaaS platforms, and services.

It helps the organization:

• Know what identities exist.
• Identify who or what each identity belongs to.
• Assign an accountable owner.
• Understand the purpose of each identity.
• Track identity status and lifecycle.
• Identify privileged and high-risk identities.
• Support access reviews.
• Support Joiner-Mover-Leaver activities.
• Identify dormant or unauthorized identities.
• Maintain audit evidence.

Core Principle

Every important identity should be known, owned, justified, appropriately protected, periodically reviewed, and removed when no longer required.

---

2. Scope

The register may include:

• Employee identities
• Contractor identities
• Consultant identities
• Intern identities
• Temporary identities
• Third-party identities
• Privileged identities
• Administrative identities
• Service accounts
• Application identities
• Cloud identities
• API identities
• Emergency/break-glass identities

It may cover identities associated with:

• Identity providers
• SSO
• Email
• SaaS applications
• AWS/Azure/GCP
• Servers
• Databases
• Source-code repositories
• CI/CD
• VPN
• Security tools
• Business applications
• Customer environments

Where service or machine identities are maintained in a separate register, this Identity Register should reference that register.

---

3. Identity Register – Master Template

Field	Description
Identity ID	Unique identifier
Identity Name	Name/username/account
Identity Type	Employee/Contractor/Third Party/Privileged/Service etc.
Person/Entity	Person or system associated with identity
Employee/Contractor ID	HR or engagement reference
Department	Department/business unit
Job Role	Current role
Manager/Sponsor	Responsible manager or sponsor
Identity Provider	IdP/SSO used
System/Application	System associated with identity
Environment	Production/Test/Development
Account Type	Standard/Privileged/Temporary/Emergency
Business Purpose	Reason identity exists
Access Level	User/Admin/Read/Write etc.
Privileged Access	Yes/No
Information Accessed	Information/data accessed
Classification	Public/Internal/Confidential/Restricted
MFA	Enabled/Not Enabled/N/A
SSO	Yes/No
Start Date	Identity activation date
Expiry Date	If applicable
Status	Active/Disabled/Expired/Removed
Last Activity	Last known activity
Last Access Review	Most recent review
Next Review	Next review date
Identity Owner	Accountable owner
System Owner	System/application owner
Related Risk ID	Risk reference
Related Access Request	Request reference
Related JML ID	JML reference
Evidence	Evidence location/reference
Remarks	Additional information

---

4. Example Identity Register

Identity ID	Identity	Type	System	Role	Privileged	MFA	Status
ID-001	user1@company.com	Employee	Microsoft 365	Developer	No	Yes	Active
ID-002	user2@company.com	Employee	AWS	DevOps	Yes	Yes	Active
ID-003	auditor@vendor.com	Third Party	Audit Repository	Auditor	No	Yes	Active
ID-004	svc-backup	Service	AWS	Backup Service	Yes	N/A	Active
ID-005	breakglass-admin	Emergency	AWS	Emergency Admin	Yes	Yes	Active

The examples above should be replaced with the organization’s actual identities.

---

5. Identity Types

Use a controlled list for consistent classification.

Identity Type	Description
Employee	Internal employee
Contractor	Contractor or consultant
Intern	Intern or trainee
Temporary	Temporary worker
Third Party	External supplier/customer/auditor
Privileged	Administrative identity
Service	Automated service account
Application	Application-to-system identity
API	API credential/identity
Machine	Workload/device identity
Emergency	Break-glass identity

---

6. Identity Status

Recommended status values:

• Pending
• Active
• Suspended
• Disabled
• Expired
• Removed
• Under Review

Status Lifecycle

Pending → Active → Suspended/Disabled → Removed

Temporary identities may follow:

Pending → Active → Expired → Removed

---

7. Identity Ownership

Each important identity should have an accountable owner.

The owner may be:

• IT Manager
• System Owner
• Application Owner
• Security Lead
• Cloud Owner
• Business Owner
• Internal Sponsor

For individual employee identities, the person may be the identity subject, while accountability for the identity-management process remains with the appropriate organizational function.

---

8. Business Purpose

Each non-standard or higher-risk identity should have a documented purpose.

Examples:

Employee

Software development and approved access to engineering systems.

Privileged Identity

Administration of AWS production infrastructure.

Third-Party Identity

External SOC 2 auditor requires read-only access to approved audit evidence.

Service Account

Automated database backup process.

Emergency Identity

Emergency recovery of the AWS identity-management environment.

Avoid vague descriptions such as:

“General access.”

---

9. Identity-to-System Mapping

An identity may have access to multiple systems.

Where appropriate, maintain a mapping.

Identity	System	Environment	Role	Access Level	Approval
User A	GitHub	Production	Developer	Write	Approved
User A	AWS	Development	Developer	Read/Write	Approved
User A	Jira	Production	User	Standard	Approved
User A	Salesforce	Production	None	None	N/A

This helps identify unnecessary access during reviews.

---

10. Identity Lifecycle

The register should be updated throughout the identity lifecycle.

Joiner

Request → Approval → Create Identity → Record → Provision → Verify

Mover

Role Change → Review Identity → Modify Access → Update Register → Verify

Leaver

Exit → Disable/Revoke → Update Register → Verify → Remove

The register should not be treated as a one-time inventory.

---

11. Identity Creation

When a new identity is created, record:

• Identity ID
• Identity name
• Person/system
• Type
• Role
• Business purpose
• System
• Access level
• Owner
• Approver
• Start date
• Expiry date where applicable
• Authentication controls
• Related request
• Status

---

12. Identity Modification

When an identity or its associated access changes, update the register.

Examples:

• Job role change
• Department change
• System change
• Privilege change
• Manager change
• Third-party engagement extension
• Access level change
• Authentication method change
• Ownership change

The old access should be reviewed rather than simply adding new access.

---

13. Identity Termination

When an identity is no longer required:

1. Disable/revoke access.
2. Terminate active sessions where appropriate.
3. Revoke credentials/tokens where required.
4. Review privileged access.
5. Review cloud access.
6. Review SaaS access.
7. Review API/SSH credentials.
8. Update the Identity Register.
9. Record evidence.
10. Mark the identity as Disabled, Expired, or Removed.

---

14. Privileged Identity Register Linkage

Privileged identities should also be recorded in the Privileged Access Register.

The two registers serve different purposes:

Identity Register	Privileged Access Register
Records identities	Focuses on elevated access
Identity lifecycle	Privileged-access justification
Identity status	Privilege level
Identity owner	Privileged approval
Authentication	Privileged monitoring/review
JML linkage	Privilege review

The Identity Register should reference the corresponding Privileged Access Register record where applicable.

---

15. Third-Party Identity Management

For external identities, record:

• Third party
• Individual
• Internal sponsor
• Contract/SOW
• Business purpose
• Systems accessed
• Information accessed
• Access level
• Start date
• Expiry date
• MFA
• Owner
• Approval
• Review date

Third-party identities should normally have a defined expiry or review point.

---

16. Temporary Identity Management

Temporary identities should include:

• Start date
• Expiry date
• Business purpose
• Approver
• Owner
• Access scope
• Review date

Example:

External VAPT consultant receives temporary access to a testing environment for the approved assessment period.

At expiry:

Review → Extend if justified → Otherwise Disable/Remove

---

17. Dormant Identity Review

The organization should periodically identify identities that have not been used or have no current business justification.

Review:

• Last activity
• User status
• Employment status
• Business purpose
• System
• Privilege level
• Owner

Possible outcomes:

• Retain
• Disable
• Remove
• Investigate
• Confirm business justification

The inactivity threshold should be defined according to organizational risk rather than assumed to be a universal ISO requirement.

---

18. Service and Application Identities

Service and application identities should have:

• Unique identifier
• Purpose
• Owner
• System
• Application
• Permissions
• Credential storage method
• Credential rotation requirements
• Interactive login status
• Dependencies
• Review date
• Status

Example:

Identity	Purpose	Owner	System	Privilege
svc-backup	Database backup	IT	AWS	Backup access
svc-deploy	CI/CD deployment	DevOps	AWS	Deployment role

---

19. AWS Identity Register Example

For an AWS SaaS organization, identity records may include:

• IAM Identity Center users
• Federated users
• IAM roles
• Break-glass identities
• Service identities
• Workload identities

Example:

Identity	AWS Account	Role	Environment	Owner	MFA	Status
Developer A	Dev Account	Developer	Dev	Engineering	Yes	Active
DevOps A	Prod Account	DevOps Admin	Prod	CTO	Yes	Active
Security A	Security Account	Security Admin	Prod	Security	Yes	Active
Breakglass	Prod Account	Emergency Admin	Prod	CTO	Yes	Active

Where AWS IAM Identity Center or another federation model is used, the organization should avoid maintaining unnecessary standalone IAM users.

---

20. Identity Authentication Information

The Identity Register should not store actual passwords, API secrets, private keys, recovery codes, or other authentication secrets.

Instead, record metadata such as:

• MFA enabled
• Authentication method
• Credential owner
• Credential location
• Credential status
• Rotation requirement

Example:

API credential stored in approved secrets-management platform.

Never enter the actual secret into the Identity Register.

---

21. Access Review

The Identity Register should support periodic access reviews.

The reviewer should compare:

Identity Register → HR/Contractor Records → Actual System Accounts → Access Control Matrix → Privileged Access Register

Review for:

• Unknown identities
• Former employees
• Role changes
• Excessive access
• Dormant accounts
• Privileged identities
• Third-party accounts
• Temporary accounts
• Missing owners
• Missing approvals
• MFA exceptions

The results should be documented in the Access Review Report.

---

22. Reconciliation Process

A practical reconciliation process is:

Identity Register

↓

Identity Provider / SSO

↓

Application Accounts

↓

Cloud Accounts

↓

HR / Contractor Records

↓

Third-Party Records

↓

Identify Differences

↓

Investigate

↓

Correct

↓

Update Register

↓

Retain Evidence

---

23. Unknown Identity Management

If an identity is found that is not present in the register:

1. Identify the owner.
2. Identify the business purpose.
3. Verify authorization.
4. Determine access level.
5. Assess risk.
6. Add it to the register if legitimate.
7. Remove/disable it if unauthorized or unnecessary.
8. Investigate as a potential security issue where appropriate.
9. Record the action.

Unknown identities should not simply be added without validation.

---

24. Identity Review Record

Identity ID	Review Date	Reviewer	Business Need	Access Appropriate	MFA	Status	Action
ID-001			Yes	Yes	Yes	Active	None
ID-002			Yes	No	Yes	Active	Reduce Access
ID-003			No	No	Yes	Active	Disable

---

25. Identity Changes Log

Maintain a history of important identity changes.

Change ID	Identity	Change	Reason	Approved By	Date	Evidence
IC-001	ID-001	Role changed	Promotion	Manager
IC-002	ID-002	Privilege reduced	Access review	System Owner
IC-003	ID-003	Account disabled	Engagement ended	Sponsor

---

26. Identity Exceptions

Document exceptions such as:

• Shared account
• Missing MFA
• Temporary privilege
• Extended third-party access
• Legacy account
• Technical limitation
• Emergency account

Exception ID	Identity	Issue	Reason	Risk	Compensating Control	Owner	Expiry

---

27. Identity Register Review Frequency

The register should be maintained continuously as identities change.

Formal reviews should be performed at a frequency appropriate to:

• System criticality
• Information sensitivity
• Privilege level
• User population
• Third-party risk
• Regulatory/contractual requirements
• Organizational risk

Examples:

• Privileged identities: more frequent review
• Production access: risk-based enhanced review
• Third-party identities: periodic or engagement-based review
• Standard identities: periodic review
• Temporary identities: review at or before expiry

These are practical examples, not universal ISO 27001 frequencies.

---

28. Data Quality Checks

Before an identity register review is closed, verify:

• Identity ID exists
• Identity owner exists
• Identity type is defined
• Business purpose is documented
• System is identified
• Role/access is documented
• Status is current
• Start date is recorded
• Expiry exists where applicable
• Privileged status is accurate
• MFA status is accurate
• Last review is recorded
• Evidence reference exists

---

29. Audit Evidence

Evidence supporting the Identity Register may include:

• Identity-provider export
• SSO user list
• Application user list
• AWS IAM/Identity Center records
• HR employee list
• Contractor list
• Third-party access records
• User Access Requests
• Access approvals
• JML records
• Privileged Access Register
• Access Review Reports
• Access Revocation Checklists
• Identity change records
• MFA configuration
• Relevant audit logs
• Exception records

The actual register should not contain authentication secrets.

---

30. Common Mistakes

Mistake 1: Treating the register as a simple employee list

An employee can have multiple identities and privileged accounts.

Mistake 2: Ignoring service accounts

Machine identities can have significant access.

Mistake 3: Not recording third-party identities

External users also need lifecycle management.

Mistake 4: No owner

Every important identity should have accountability.

Mistake 5: Storing passwords or secrets

Never store authentication secrets in the register.

Mistake 6: Not updating after role changes

Mover events can create privilege accumulation.

Mistake 7: Forgetting cloud identities

Cloud access may exist independently from corporate applications.

Mistake 8: Not reconciling with actual systems

The register should reflect reality, not just planned access.

---

31. Startup-Friendly Implementation

A startup does not need a complicated IAM database to establish identity visibility.

A practical model is:

Step 1 – Central Identity

Maintain a primary identity provider.

Step 2 – Master Identity Register

Record people, identities, systems, owners and status.

Step 3 – Privileged Register

Track administrative identities separately.

Step 4 – JML

Connect HR events to identity lifecycle.

Step 5 – Access Review

Periodically reconcile the register with actual systems.

Step 6 – Revocation

Remove identities when business need ends.

Step 7 – Evidence

Keep approval, review and revocation evidence.

---

32. Relationship with Other ISMS Documents

The Identity Register connects several identity and access controls:

Identity Management Policy

↓

Identity Register

↓

User Account Management Procedure

↓

User Access Request

↓

Access Control Matrix

↓

JML Procedure

↓

Privileged Access Register

↓

Third-Party Access Procedure

↓

Access Review Report

↓

Access Revocation Checklist

↓

Incident Management

This creates a traceable identity lifecycle.

---

33. ISO 27001 Connection

The Identity Register supports applicable ISO/IEC 27001 requirements relating to:

• Identity management
• Authentication information
• Access rights
• Access restriction
• Privileged access
• Segregation of duties
• Access review
• Supplier/third-party access
• Logging and monitoring where applicable

The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).

---

34. Final Audit Trail

An auditor should be able to select an identity and trace:

Identity

→ Who or what does it belong to?

→ Why does it exist?

→ Who owns it?

→ Which system does it access?

→ What permissions does it have?

→ Who approved it?

→ Is authentication appropriately protected?

→ Was it reviewed?

→ Was it modified when the role changed?

→ Was it revoked when no longer required?

→ Is evidence available?

Final Principle

Know every important identity, know who or what it belongs to, understand why it exists, control what it can access, review it periodically, and remove it when it is no longer required.