User Account Management Procedure

1. Purpose

The purpose of this User Account Management Procedure is to define the operational process for requesting, creating, modifying, reviewing, disabling, and removing user accounts.

The procedure ensures that user accounts are:

Created only for authorized users.
Linked to a legitimate business need.
Uniquely attributable to an individual where practical.
Assigned appropriate access.
Protected using appropriate authentication controls.
Modified when user responsibilities change.
Periodically reviewed.
Disabled or removed when no longer required.
Supported by appropriate evidence.

Core Lifecycle

Request → Verify → Approve → Create → Configure → Provision Access → Verify → Review → Modify → Disable/Remove → Record

2. Scope

This procedure applies to:

Employees
Contractors
Consultants
Interns
Temporary personnel
Third-party users
Administrators
Privileged users

It covers user accounts for:

Identity providers / SSO
Email and collaboration
SaaS applications
AWS, Azure, GCP and other cloud environments
Servers
Databases
VPN and remote access
Source-code repositories
CI/CD platforms
Security platforms
Business applications
Customer environments
Other systems containing organizational information

Service accounts, application identities, API credentials, and machine identities should be managed under appropriate separate controls, although they may be referenced by this procedure where relevant.

3. Objectives

The procedure is intended to ensure:

Every user account has an identifiable owner.
Account creation is authorized.
Access is based on business need.
Users receive only appropriate permissions.
Authentication is appropriately protected.
Role changes trigger access review.
Former users lose access.
Privileged accounts receive additional controls.
Dormant accounts are identified.
Account activities can be traced to appropriate users.
Account management activities can be demonstrated through evidence.

4. Roles and Responsibilities

Role	Responsibility
HR / People Team	Notify IT of joiners, movers and leavers
Manager	Define and approve business access requirements
System Owner	Approve system-specific access
IT / IAM	Create, modify, disable and remove accounts
Security / ISMS	Define security requirements and support reviews
Data Owner	Approve access to sensitive information where required
Application Owner	Manage application-level account requirements
Cloud Owner	Manage cloud identities and permissions
User	Protect credentials and use the assigned account appropriately
Internal Audit	Independently assess account-management controls

For small organizations, one person may perform multiple responsibilities, but appropriate approval and review separation should be maintained where practical.

5. Account Types

Account Type	Example	Management Approach
Standard User	Employee account	Normal user access
Privileged User	Cloud administrator	Enhanced controls
Contractor	External developer	Time-limited access
Third-Party User	Auditor	Restricted, approved access
Temporary User	Project resource	Expiry required
Service Account	Backup service	Separate service-account controls
Emergency Account	Break-glass	Restricted and monitored

6. User Account Lifecycle

The standard account lifecycle is:

1. Request

Business need is identified.

2. Verify

User identity, employment/engagement and role are verified.

3. Approve

Manager/system owner approves the requested account and access.

4. Create

IT/IAM creates the account.

5. Configure

Authentication and required security controls are configured.

6. Provision Access

Approved permissions are assigned.

7. Verify

User access is checked against the approved request.

8. Review

Account and access are periodically reviewed.

9. Modify

Account/access is changed when responsibilities change.

10. Disable or Remove

Account is disabled or removed when no longer required.

11. Record

Evidence of the lifecycle activity is retained.

7. User Account Request

A user account should be created only after an appropriate request has been submitted.

The request should include, as applicable:

Request ID
User name
Employee/contractor ID
Department
Job role
Manager
System/application
Environment
Required access
Business purpose
Data/information accessed
Access level
Start date
Expiry date, where applicable
Approver
System owner
Security approval, where required

Example

A new software developer requires access to GitHub and the AWS development environment.

The request should specify:

Required repositories
AWS account
Required role
Business justification
Start date
Approver

The user should not automatically receive AWS production administrator access simply because they are a developer.

8. User Verification

Before account creation, the responsible team should verify that:

The person is an employee or authorized external user.
The engagement is active.
The manager/sponsor is valid.
The requested role is accurate.
The system access is required.
The requested access is appropriate.

For third parties, verify the applicable contract, SOW, NDA, sponsor and engagement period.

9. Account Approval

Approval should be obtained before account creation.

Depending on the system, approval may involve:

Manager → System Owner → Data Owner/Security → IT/IAM

Not every request requires every approval.

Higher-risk access may require additional approval.

Examples:

Production access
Privileged access
Customer database access
Security administration
Financial systems
Restricted information
Administrative cloud roles

10. Account Creation

IT/IAM or the authorized administrator shall create the account using the approved identity-management process.

The account should:

Use the user’s approved identity.
Have a unique username where practical.
Use approved naming conventions.
Be associated with the correct department/role.
Be linked to the appropriate identity provider where possible.
Have only approved access.
Have required authentication controls.
Be recorded in the appropriate system or register.

11. Authentication Configuration

Authentication should be configured according to organizational requirements.

Controls may include:

Password
MFA
SSO
Security key
Authenticator application
Conditional access
Device authentication
Federation

For higher-risk systems, stronger authentication should be applied according to the organization’s risk assessment.

12. MFA Configuration

MFA should be enabled for systems where required by:

Organizational policy
Risk assessment
Customer requirements
Contractual requirements
Regulatory requirements
System security requirements

Particular attention should be given to:

Privileged accounts
Cloud administration
Identity-provider administration
Production systems
Remote access
Security platforms
Sensitive SaaS applications

13. Access Provisioning

After account creation, only approved access should be provisioned.

Provisioning Flow

Approved Request → Identify Required Role → Assign Appropriate Permission → Configure MFA → Verify → Record

Access should follow:

Least privilege
Need-to-know
Role requirements
Information classification
System risk
Segregation of duties

14. Privileged Account Provisioning

Privileged access requires additional controls.

Before granting privileged access:

Business need must be established.
Appropriate approval must be obtained.
The privilege should be limited to the required scope.
MFA should be enabled where required.
Named accounts should be used where practical.
Privileged access should be recorded.
Monitoring/logging should be enabled where appropriate.

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

15. Production Access

Production access should be separately evaluated from development or test access.

For example:

User	Development	Production
Developer	Approved	Restricted/role-based
DevOps	Approved	Approved based on role
Support	Usually no	Limited application access
Auditor	No	Evidence access only

Production access should be granted only where there is a documented business requirement.

16. User Account Verification

After provisioning, IT/IAM or the relevant system owner should verify:

Correct account created
Correct user assigned
Correct system assigned
Correct role assigned
Correct permissions
MFA configured where required
No unnecessary privileged access
Start/expiry dates correctly configured
Account recorded appropriately

The user or system owner may confirm that required access works.

17. Account Modification

User accounts should be modified when there is a change in:

Job role
Department
Responsibilities
Project
Employment status
Security requirements
System requirements
Privilege level

Mover Process

Role Change → Review Existing Access → Remove Unnecessary Access → Approve New Access → Provision → Verify → Record

The organization should avoid simply adding new permissions without reviewing existing permissions.

18. Joiner Process

For a new employee or authorized user:

HR/People or sponsor sends notification.
User identity is verified.
Role is confirmed.
Required systems are identified.
Access request is submitted.
Appropriate approvals are obtained.
User account is created.
MFA/authentication is configured.
Approved access is provisioned.
Security responsibilities are communicated.
Access is verified.
Evidence is retained.

19. Mover Process

When a user changes role:

Role change is received.
Existing accounts are identified.
Existing access is reviewed.
Unnecessary permissions are removed.
New access requirements are identified.
New access is approved.
New permissions are provisioned.
Privileged access is reassessed.
SoD implications are considered.
Access is verified.
Records are updated.

Example

A developer becomes an Engineering Manager.

Their new access may include:

Jira management
Engineering dashboards
Approved management tools

Their previous access to certain production resources may no longer be required and should therefore be reviewed and potentially removed.

20. Leaver Process

When a user leaves:

HR/manager provides exit notification.
All known accounts are identified.
Account status is reviewed.
Corporate identity is disabled.
Sessions are terminated where applicable.
MFA credentials are revoked.
SaaS access is removed.
Cloud access is removed.
VPN access is removed.
Source-code access is removed.
Database access is removed.
API tokens/SSH keys/certificates are reviewed.
Privileged access is revoked.
Physical access is removed.
Assets are recovered.
Business responsibilities are transferred.
Completion is verified.
Evidence is retained.

Important: Disabling the email account alone does not complete account termination.

21. Emergency Account Revocation

Immediate account action may be required when:

Credentials are suspected to be compromised.
A security incident occurs.
A device containing authentication information is lost.
Unauthorized access is detected.
A privileged account is suspected of compromise.
Emergency termination is required.

Actions may include:

Disable account
Revoke sessions
Reset credentials
Revoke MFA methods
Revoke API tokens
Revoke SSH keys
Remove cloud roles
Disable VPN
Block application access

The event should be handled under the organization’s incident-management process where applicable.

22. Temporary Accounts

Temporary accounts should have:

Defined purpose
Named user
Approver
Start date
Expiry date
Limited permissions
Appropriate authentication
Review requirement

Example:

An external auditor requires access to an audit evidence repository for 14 days.

The account should automatically expire where technically possible or be explicitly reviewed and disabled at the end of the engagement.

23. Third-Party Accounts

Third-party user accounts shall be managed according to the Third-Party Access Procedure.

Before creating the account, verify:

Organization
Individual
Internal sponsor
Contract/SOW
NDA/confidentiality
Business purpose
Systems required
Information accessed
Access level
Start date
Expiry date

Third-party accounts should not be created using shared employee credentials.

24. Dormant Account Management

The organization should periodically identify inactive accounts.

Review:

Last login
Last activity
Account owner
Business purpose
Employment/engagement status
System criticality
Privilege level

Possible actions:

Disable
Remove
Confirm business need
Transfer ownership
Investigate activity

The inactivity threshold should be determined according to system risk and organizational requirements.

25. Account Lockout and Protective Controls

Where supported and appropriate, systems should implement controls such as:

Failed-login protection
Account lockout or throttling
Risk-based authentication
Session timeout
Reauthentication
Suspicious-login detection
Conditional access

The exact configuration should reflect system risk and usability requirements.

26. Shared Accounts

Shared user accounts should generally be avoided because they reduce accountability.

Where a shared account is technically necessary:

Document the business justification.
Obtain approval.
Restrict access.
Protect credentials.
Maintain appropriate accountability.
Monitor use where technically possible.
Review the account periodically.

Privileged shared accounts should receive particular scrutiny.

27. Service Accounts

Service accounts should be managed using appropriate service-account controls.

Each service account should have:

Owner
Purpose
System/application
Permissions
Credential location
Rotation requirements
Review date
Dependencies
Status

Where possible:

Disable interactive login.
Use workload identities.
Use short-lived credentials.
Avoid embedding secrets in source code.

28. Cloud Account Management

AWS Example

For an AWS-based SaaS company:

Employee → Corporate IdP → SSO/MFA → AWS IAM Identity Center → Approved Role → AWS Account

Administrators should avoid unnecessary long-lived credentials.

Where practical, use:

IAM roles
Federation/SSO
MFA
Temporary credentials
Least privilege
Separate production/development access
CloudTrail
Periodic access reviews

29. Account Review

User accounts should be periodically reviewed according to organizational requirements and risk.

The review should compare:

Actual Account → Current User → Current Role → Approved Access → Required Access

The review should identify:

Unauthorized accounts
Excessive permissions
Former employees
Role-change issues
Dormant accounts
Privileged accounts
Third-party accounts
Temporary accounts
MFA exceptions
Shared accounts

Results should be documented in an Access Review Report.

30. Account Revocation

Account revocation should include more than disabling the primary account.

Depending on the user/system, review:

SSO
Email
SaaS
VPN
AWS/Azure/GCP
Source code
CI/CD
Databases
Customer systems
Security platforms
API tokens
SSH keys
Certificates
Active sessions
MFA devices
Physical access

The revocation should be verified.

31. Access Revocation Verification

After revocation, verify:

Account disabled/removed
Sessions terminated where applicable
Privileged roles removed
Cloud access removed
SaaS access removed
Source-code access removed
Tokens/keys reviewed
Physical access removed
Registers updated

Verification Record

Item	Result	Verified By	Date	Evidence
Corporate Account
AWS
GitHub
SaaS
VPN
Physical Access

32. Account Management Records

The organization should maintain appropriate records such as:

User Account Request
Account Creation Record
Access Approval
Account Modification Record
JML records
Privileged Access Register
Third-Party Access Register
Account Review Report
Access Revocation Checklist
Exception records
Relevant system logs

33. User Account Management Register

Where a centralized register is appropriate, consider maintaining:

Field	Description
Account ID	Unique identifier
User	Account owner
Employee/Contractor ID	Reference
Department	User department
Role	Business role
Account Type	Standard/Privileged/Temporary
System	Application/system
Environment	Production/Test/Development
Access Level	Permission level
Business Purpose	Reason for access
Approver	Approval authority
Created Date	Account creation
Expiry Date	Where applicable
MFA	Enabled/Not Enabled
Status	Active/Disabled/Removed
Last Review	Review date
Next Review	Next review
Owner	Account/system owner
Evidence	Supporting record

34. Exceptions

Any deviation from this procedure should be documented.

The exception should include:

Exception ID
Requirement
Reason
Affected account/system
Risk
Compensating controls
Owner
Approver
Expiry/review date
Status

35. Procedure for Lost or Compromised Credentials

If a user believes credentials have been compromised:

User

Stop using the credential → Report immediately

IT/Security

Assess → Disable/Reset → Revoke Sessions/Tokens → Investigate → Restore Access → Monitor

Where required, the incident should be recorded through the Security Incident Management Procedure.

Examples include:

Password entered into phishing site
AWS access key exposed
API token committed to GitHub
MFA device lost
SSH key compromised
Session token stolen

36. Audit Evidence

An auditor may request:

User account list
Access requests
Approval records
Account creation records
JML records
Access review reports
Privileged Access Register
Third-party access records
Account revocation records
MFA evidence
SSO configuration
AWS IAM/Identity Center evidence
Application access listings
Dormant account review
Service account records
Exception records
Relevant audit logs

Evidence should demonstrate not only that accounts exist, but that the account lifecycle is controlled.

37. AWS SaaS Startup Example

A 30-person SaaS startup operates its platform on AWS.

New Developer

HR Notification

→ Manager confirms role
→ User Access Request
→ Approval
→ Corporate SSO account created
→ MFA enabled
→ GitHub access provisioned
→ AWS development role assigned
→ Access verified
→ Evidence retained

Developer Becomes Engineering Manager

Role Change

→ Existing access reviewed
→ Unnecessary developer permissions removed
→ Manager access approved
→ New access provisioned
→ Production privileges reassessed
→ Verification completed

Developer Leaves

Exit Notification

→ SSO disabled
→ GitHub access removed
→ AWS roles removed
→ VPN disabled
→ SaaS access removed
→ API/SSH credentials reviewed
→ Sessions revoked
→ Laptop returned
→ Access revocation verified
→ Evidence retained

38. Startup-Friendly Minimum Control Set

A startup can establish a strong account-management process without a complex IAM program.

Minimum model

1. Central Identity

Use an approved identity provider where practical.

2. MFA

Protect important and privileged systems.

3. Access Request

Require approval before creating access.

4. JML

Connect HR/contractor changes to account management.

5. Privileged Access Register

Track administrative accounts.

6. Periodic Access Review

Compare actual accounts and permissions with approved requirements.

7. Revocation

Remove access when the business need ends.

8. Evidence

Keep approval, provisioning, review and revocation evidence.

39. Common Mistakes

1. Creating accounts through informal requests

Use a controlled request and approval process.

2. Giving access based only on job title

Validate actual business requirements.

3. Adding permissions after role changes

Review and remove old permissions first.

4. Disabling only email

Review all systems and credentials.

5. Forgetting API credentials

Tokens, SSH keys and certificates may continue to provide access.

6. Ignoring dormant accounts

Review inactive identities periodically.

7. Using shared administrator accounts

Prefer individually attributable identities.

8. Forgetting third-party users

External identities need the same lifecycle discipline.

9. No expiry for temporary access

Temporary access should have a defined end point.

10. No evidence

An account-management process should leave an auditable trail.

40. Quick Procedure Checklist

Account Creation

Business need identified
User verified
Role confirmed
Access requested
Approval obtained
Account created
MFA configured where required
Access provisioned
Access verified
Evidence retained

Account Modification

Role change identified
Existing access reviewed
Unnecessary access removed
New access approved
New access provisioned
Privileged access reassessed
SoD considered
Verification completed

Account Termination

Exit notification received
Accounts identified
SSO/email disabled
SaaS access removed
Cloud access removed
Source-code access removed
VPN removed
Tokens/keys reviewed
Sessions revoked
Physical access removed
Assets recovered
Revocation verified
Evidence retained

41. Relationship with Other ISMS Documents

This procedure works together with:

Identity Management Policy
Access Control Policy
Access Control Matrix
User Access Request
User Access Review Checklist
Access Review Report
JML Procedure
Privileged Access Register
Third-Party Access Procedure
Access Revocation Checklist
Employee Offboarding Checklist
Contractor Offboarding Checklist
Segregation of Duties Policy
Information Classification Policy
Cloud Asset Inventory
SaaS Application Register
Incident Response Plan

Complete Lifecycle

Identity Management Policy

↓

User Account Request

↓

Approval

↓

Account Creation

↓

Access Provisioning

↓

User Account Management

↓

Periodic Access Review

↓

Access Modification / Revocation

↓

Evidence & Audit Trail

42. ISO 27001 Connection

This procedure supports applicable ISO/IEC 27001 requirements relating to:

Identity management
Authentication information
Access rights
Access restriction
Privileged access
Access review
Segregation of duties
Supplier and 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).

43. Final Audit Trail

An auditor should be able to trace:

User → Business Need → Request → Approval → Account Creation → Authentication → Access → Review → Modification → Revocation → Verification → Evidence

The procedure should answer:

Who is the account for?
Why does the account exist?
Who approved it?
What access was granted?
Is MFA appropriately configured?
Does the access match the user’s role?
Was access reviewed?
What happened when the user changed roles?
What happened when the user left?
Were tokens, keys and privileged access also addressed?
Can the organization demonstrate the entire lifecycle?

Final Principle

Create accounts only when needed, give only the access required, protect the identity appropriately, review it periodically, and remove it when the business need ends — with evidence at every important stage.