1. Purpose

The User Access Management Procedure defines how user access to organizational information, systems, applications, cloud environments, databases, networks, SaaS platforms, and other technology resources is requested, approved, provisioned, reviewed, modified, and revoked.

The objective is to ensure that:

• Only authorized users receive access.
• Access is based on a legitimate business need.
• Users receive only the minimum access required.
• Access is appropriately authenticated and protected.
• Privileged access receives additional controls.
• Access is periodically reviewed.
• Access is promptly removed when no longer required.
• User access activities are supported by appropriate evidence.

Core Principle

Request → Verify → Approve → Provision → Verify → Review → Modify → Revoke → Record

---

2. Scope

This procedure applies to:

• Employees
• Contractors
• Consultants
• Interns
• Temporary workers
• Third-party personnel
• Privileged users
• Administrators
• Service/application users where applicable
• Other authorized users

It covers access to:

• Corporate identity/SSO
• Email and collaboration platforms
• SaaS applications
• AWS/Azure/GCP environments
• Servers
• Databases
• Source-code repositories
• CI/CD platforms
• VPN and remote-access systems
• Security platforms
• Customer environments
• File-sharing platforms
• Business applications
• Network resources
• Physical systems where relevant

---

3. Definitions

User

An individual authorized to access organizational systems or information.

Access

The ability to view, use, modify, administer, or otherwise interact with a system, application, information, or resource.

Privileged Access

Access that provides elevated administrative, security, configuration, or high-impact capabilities.

Access Owner

The person responsible for determining whether access to a particular system or resource is appropriate.

System Owner

The person accountable for the security and operation of a system or application.

Data/Information Owner

The person responsible for determining appropriate access to specific information.

Least Privilege

Providing only the minimum permissions required to perform an authorized business activity.

---

4. User Access Management Lifecycle

User access shall be managed throughout its lifecycle:

Business Need
↓
Access Request
↓
Identity Verification
↓
Risk & Access Assessment
↓
Approval
↓
Provisioning
↓
Authentication & MFA
↓
Verification
↓
Monitoring
↓
Periodic Review
↓
Modification
↓
Revocation
↓
Evidence & Record Closure

Access should not be treated as a one-time provisioning activity.

---

5. Access Management Principles

The organization should apply the following principles:

1. Business need
2. Least privilege
3. Need-to-know
4. Individual accountability
5. Unique user identity
6. Appropriate authentication
7. MFA where required
8. Role-based access where practical
9. Separation of duties
10. Time-limited access where appropriate
11. Privileged access protection
12. Periodic access review
13. Prompt access removal
14. Traceability and evidence
15. Risk-based controls

---

6. User Access Request

All non-emergency access should begin with a documented request.

The request should identify:

• User
• Department/organization
• Role
• System/application
• Environment
• Information accessed
• Required permissions
• Business purpose
• Start date
• Expiry date where applicable
• Privileged access requirement
• Production access requirement
• Third-party status
• Relevant project/business process

The User Access Request Form should be used where applicable.

---

7. Identity Verification

Before creating or modifying access, the user’s identity should be verified through an approved organizational process.

Verification may include:

• HR records
• Contractor records
• Approved supplier information
• Corporate identity provider
• Manager confirmation
• Third-party sponsor confirmation
• Other approved identity-verification mechanisms

Access should not be provisioned based solely on an informal email or verbal request where stronger verification is required.

---

8. Business Need Assessment

The requester and appropriate access owner should determine:

• Why access is required
• What business activity requires it
• Which system is required
• What information will be accessed
• What permissions are necessary
• How long access is required
• Whether standard access is sufficient
• Whether privileged access is required
• Whether production access is required

The requested access should be limited to the business requirement.

---

9. Access Level Assessment

Access should be categorized according to the permissions required.

Example:

Access Level	Example
Read Only	View reports
Standard User	Normal business application use
Contributor	Create/update information
Developer	Application development
Administrator	System administration
Privileged	Elevated technical/security permissions
Production	Access to live systems
Emergency	Temporary emergency administration

These categories are organizational examples and should be adapted to the organization’s technology environment.

---

10. Information Classification Assessment

Before granting access, consider the classification of information involved.

For example:

• Public
• Internal
• Confidential
• Restricted

Higher-sensitivity information should receive stronger access restrictions.

Examples include:

• Customer information
• Personal data
• Financial information
• Source code
• Security reports
• Production credentials
• Encryption keys
• Security configurations

Access to Restricted information should generally be limited to specifically authorized users with a legitimate business need.

---

11. Least Privilege Assessment

The access owner should determine the minimum permissions necessary.

Consider:

• Read vs write access
• Specific folders/resources
• Specific applications
• Specific AWS accounts
• Specific database schemas
• Development vs production
• Specific customer environments
• Administrative vs standard access

Avoid granting broad access simply because it is technically easier.

Example

A software developer requiring access to application logs may need:

Read → Development Logs

rather than:

Administrator → Entire Production Environment

---

12. Segregation of Duties Assessment

Before approving access, consider whether the requested permissions create a conflict between incompatible responsibilities.

Examples:

• Developer + production deployment approval
• Requester + approver
• Finance payment preparation + payment approval
• User provisioning + independent access approval
• Security administrator + audit approval

Where complete segregation is not practical, appropriate compensating controls should be considered and documented.

---

13. Access Approval

Access should be approved by the appropriate authority before provisioning.

Depending on the risk, approvals may include:

• User’s manager
• System owner
• Application owner
• Data owner
• Business owner
• Security/ISMS owner
• Privileged access approver

Higher-risk access should receive additional review.

Examples:

• Production access
• Administrator access
• Database administration
• Cloud administration
• Security-platform administration
• Customer-system access
• Restricted information access

---

14. User Account Creation

Once approved, the appropriate administrator or IAM function should create the account.

Accounts should:

• Be uniquely associated with the individual
• Use approved identity systems
• Have an identified owner
• Have an appropriate role
• Have appropriate authentication
• Have MFA where required
• Have an expiry date where appropriate
• Be recorded in the Identity Register

Shared user accounts should generally be avoided unless technically necessary and formally controlled.

---

15. Authentication Configuration

Authentication should be configured according to the organization’s Authentication & Password Policy.

Controls may include:

• SSO
• MFA
• Strong passwords
• Password managers
• Security keys/passkeys
• Conditional access
• Device controls
• VPN
• Certificate-based authentication
• Workload identities
• Temporary credentials

Actual passwords, API keys, MFA secrets, recovery codes, and private keys must never be stored in the access-management record.

---

16. Access Provisioning

After approval and identity creation, the administrator provisions the approved permissions.

Provisioning should match the approved request.

Verify:

• Correct user
• Correct system
• Correct environment
• Correct role
• Correct permissions
• Correct start date
• Correct expiry date
• MFA enabled where required
• Privileged permissions separately controlled

Any difference between approved and actual access should be investigated and corrected.

---

17. Access Verification

After provisioning, the access should be verified.

Verification Checklist

• ☐ Correct user
• ☐ Correct application/system
• ☐ Correct role
• ☐ Correct permissions
• ☐ Least privilege applied
• ☐ MFA configured
• ☐ Production access restricted appropriately
• ☐ Privileged access correctly configured
• ☐ Temporary access expiry configured
• ☐ Access recorded
• ☐ Evidence retained

The verification should be performed by an appropriate person rather than automatically assuming that provisioning was correct.

---

18. AWS User Access Management

For an AWS-based SaaS organization, access should preferably follow a model such as:

Employee Identity
↓
Corporate IdP/SSO
↓
MFA
↓
AWS IAM Identity Center / Approved Identity Mechanism
↓
AWS Role
↓
Specific AWS Account/Environment
↓
Minimum Required Permissions

Where practical:

• Avoid shared administrator accounts.
• Avoid unnecessary long-lived human access keys.
• Use role-based access.
• Separate development and production access.
• Restrict production privileges.
• Monitor privileged activity.
• Review cloud access periodically.
• Control emergency/break-glass access separately.

---

19. Production Access

Production access should receive additional controls based on risk.

Consider:

• Business justification
• System owner approval
• Security approval where required
• MFA
• Privileged account controls
• Logging
• Monitoring
• Time limitation
• Change-management requirements
• Periodic review

Developers should not automatically receive production administrative access merely because they require development access.

---

20. Privileged Access

Privileged access should be separately managed.

Examples include:

• Cloud administrator
• Database administrator
• Security administrator
• Network administrator
• Identity administrator
• CI/CD administrator
• Repository administrator
• Backup administrator

Privileged access should be:

• Specifically justified
• Explicitly approved
• Individually attributable where practical
• Strongly authenticated
• Limited to the required permissions
• Monitored according to risk
• Periodically reviewed
• Removed when no longer required

Relevant privileged access should be recorded in the Privileged Access Register.

---

21. Temporary Access

Temporary access should have:

• Business justification
• Start date
• Expiry date
• Appropriate approval
• Defined scope
• Appropriate authentication
• Review requirement
• Automatic expiry where technically possible

Temporary access should not become permanent simply because the expiry date was overlooked.

---

22. Contractor Access

Contractor access should be managed through the organization’s contractor and third-party access processes.

Before provisioning:

• Verify contractor identity
• Confirm organization
• Confirm sponsor
• Verify contract/SOW
• Check NDA/confidentiality requirements
• Determine required systems
• Assess information classification
• Define start/end dates
• Obtain appropriate approval

Contractor access should be reviewed and revoked when the engagement ends or business need changes.

---

23. Third-Party Access

Third-party access should be assessed based on:

• Business purpose
• Organization
• Individual user
• Contract/SOW
• Information accessed
• System criticality
• Access level
• Production access
• Privileged access
• Duration
• Security requirements

Where appropriate, use named accounts rather than shared credentials.

---

24. SaaS Application Access

Access to SaaS applications should be controlled through approved identity and access-management processes.

Examples:

• Microsoft 365
• GitHub
• Jira
• Slack
• Salesforce
• HR systems
• Customer support platforms
• Security platforms

The organization should know:

• Who has access
• Why they have access
• What role they have
• Whether they have administrator privileges
• What information they can access
• When access was last reviewed

---

25. Source-Code Access

Source-code access should be limited according to job responsibilities.

Controls may include:

• Named accounts
• SSO/MFA
• Repository-level permissions
• Branch protection
• Protected production repositories
• Administrative access restrictions
• Periodic access reviews
• Contractor expiry
• Prompt access removal

Developers should not automatically receive repository administrator permissions.

---

26. Database Access

Database access should be based on role and business requirement.

Where appropriate:

• Use individual identities.
• Avoid shared database accounts.
• Restrict production access.
• Use read-only access where sufficient.
• Separate application and administrative access.
• Protect credentials through approved secrets-management mechanisms.
• Log administrative activity where appropriate.
• Review access periodically.

---

27. Service and Application Accounts

Service accounts and application identities should be managed separately from normal employee accounts.

Each should have:

• Identified owner
• Business purpose
• System/application
• Required permissions
• Authentication mechanism
• Privilege level
• Secure credential storage
• Review frequency
• Lifecycle status

Where practical, use workload identities, managed identities, or temporary credentials rather than long-lived credentials.

Actual credentials must not be recorded in the User Access Register or access request forms.

---

28. Role Changes

When a user changes role:

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

The organization should not simply add new permissions while leaving old permissions in place.

This helps prevent privilege accumulation.

Examples:

• Developer → Engineering Manager
• Finance → Operations
• Support → Security
• Contractor → Employee
• Employee → Different Business Unit

---

29. Access Review

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

The review should determine whether:

• The user still exists
• The user still requires access
• Access remains appropriate
• Permissions match the current role
• Privileged access remains justified
• Temporary access has expired
• Contractor access remains valid
• Third-party access remains required
• Dormant accounts exist
• Excessive permissions exist
• SoD conflicts exist

Review results should be documented.

---

30. Access Reconciliation

Access records should be reconciled against actual system access.

Potential sources include:

• HR records
• Identity Provider
• SSO
• AWS IAM/Identity Center
• Azure
• GCP
• SaaS platforms
• VPN
• GitHub
• Databases
• Security platforms

Reconciliation Process

Collect → Compare → Identify Differences → Investigate → Correct → Verify → Update Records

This helps identify orphaned, unauthorized, dormant, or incorrectly recorded accounts.

---

31. Dormant Accounts

Inactive accounts should be identified and assessed.

Consider:

• Last login
• Business need
• User status
• Employment status
• Contractor status
• Project status
• Application requirement
• Security risk

Where access is no longer required, the account should be disabled or removed according to the organization’s account-management process.

---

32. Access Modification

Access modifications may occur because of:

• Role change
• Project change
• New business responsibility
• System change
• Security requirement
• Risk assessment
• Incident
• Customer requirement
• Regulatory requirement

Changes should follow the same principles as new access:

Need → Assessment → Approval → Change → Verification → Evidence

---

33. Access Revocation

Access should be revoked when it is no longer required.

Triggers include:

• Employee termination
• Resignation
• Contractor engagement ending
• Third-party relationship ending
• Role change
• Project completion
• Temporary access expiry
• Security incident
• Credential compromise
• Lost/stolen device where appropriate
• System retirement

Revocation should cover relevant:

• Identity provider
• Email
• SaaS
• VPN
• Cloud
• Source code
• Databases
• Customer systems
• Security platforms
• API credentials/tokens
• Physical access

Disabling email alone does not demonstrate complete access revocation.

---

34. Emergency Access Revocation

Immediate revocation may be required where there is:

• Suspected credential compromise
• Malicious activity
• Lost/stolen authentication device
• Security incident
• Unauthorized access
• Emergency termination
• Significant policy violation

The organization should prioritize containment and document the action afterward.

---

35. Access Revocation Verification

After revocation, verify that access has actually been removed.

Where relevant, verify:

• Account disabled
• SSO access removed
• SaaS access removed
• AWS/cloud roles removed
• VPN removed
• Repository access removed
• Database access removed
• Privileged roles removed
• API tokens/keys addressed
• Active sessions terminated where required
• Physical access removed
• Identity Register updated

Evidence should be retained.

---

36. Access Exceptions

Exceptions should be documented where normal access requirements cannot be followed.

Record:

• Exception
• Business reason
• Risk
• Affected system
• Information involved
• Compensating control
• Owner
• Approval
• Expiry/review date

Exceptions should be periodically reviewed.

---

37. Access-Related Security Incidents

Access-related events should be handled through the organization’s incident-management process.

Examples:

• Unauthorized access
• Excessive permissions
• Stolen credentials
• Shared credentials
• Privileged account misuse
• Dormant account abuse
• Unauthorized third-party access
• Access-control configuration error

The organization should assess whether the event affects:

• Confidentiality
• Integrity
• Availability
• Personal data
• Customer data
• Contractual obligations
• Regulatory requirements

---

38. Access Records

The organization should maintain appropriate records such as:

• User Access Request Forms
• Identity Register
• Authentication Information Register
• Access Control Matrix
• Privileged Access Register
• Access Review Reports
• JML records
• Contractor Account Register
• Third-Party Access records
• Access Revocation records
• Exception Register
• Relevant system logs

Records should be protected from unauthorized modification.

---

39. Roles and Responsibilities

Management

• Approve access governance requirements.
• Provide appropriate resources.
• Review significant access risks.

Managers

• Confirm business need.
• Approve or reject employee access.
• Notify role changes and departures.

System/Application Owners

• Define appropriate access levels.
• Approve access to systems they own.
• Review access periodically.

Data Owners

• Determine appropriate access to sensitive information.

IT/IAM

• Create and modify accounts.
• Provision approved access.
• Maintain authentication mechanisms.
• Remove access when instructed.

Security/ISMS Team

• Define security requirements.
• Review higher-risk access where required.
• Support access reviews and audits.

Users

• Use access only for authorized purposes.
• Protect authentication information.
• Do not share accounts or credentials.
• Report suspected unauthorized access.

Internal Audit

• Independently evaluate the effectiveness of access-management controls.

---

40. Evidence

Typical evidence may include:

• Access requests
• Approvals
• Provisioning records
• IAM/SSO configuration
• MFA configuration
• Access-control lists
• AWS IAM/Identity Center configuration
• Privileged access records
• Access review reports
• JML records
• Contractor records
• Access revocation evidence
• Change tickets
• System logs
• Exception approvals
• Incident records

Actual passwords, API keys, tokens, MFA secrets, private keys, or other credentials should never be retained as audit evidence.

---

41. Metrics

Useful access-management metrics may include:

Metric	Example
Access Requests	Number processed
Approval Time	Average time
Access Review Completion	% completed
Excess Access	Number identified
Dormant Accounts	Number identified
Orphaned Accounts	Number identified
Privileged Accounts	Number
Temporary Access	Number expired/revoked
Access Revocation Time	Average time
JML Exceptions	Number
Access Incidents	Number
MFA Coverage	% where applicable

Metrics should support management decisions rather than become compliance reporting for its own sake.

---

42. AWS SaaS Startup Example

Consider a 40-person SaaS company operating on AWS.

A new developer joins.

Required Access

• Corporate SSO
• MFA
• Git repository
• Jira
• Development AWS account
• Development database

Not Automatically Granted

• AWS production administrator
• Production database administrator
• Security administrator
• Billing administrator

Process

HR Notification
↓
Developer Role Identified
↓
Access Request Submitted
↓
Engineering Manager Approval
↓
System Owner Approval
↓
SSO + MFA Created
↓
Git/Jira/Development AWS Access Provisioned
↓
Access Verified
↓
Identity Register Updated
↓
Periodic Access Review

If the developer later becomes a DevOps engineer requiring production administration, a separate privileged-access assessment and approval should be performed.

---

43. Startup-Friendly Implementation

A startup does not necessarily need a sophisticated IAM/GRC platform to establish a controlled process.

A practical minimum setup can include:

1. Identity Register

Know who has identities.

2. User Access Request

Document why access is required.

3. Approval Workflow

Ensure appropriate approval before provisioning.

4. Access Control Matrix

Define standard roles and permissions.

5. Privileged Access Register

Track elevated access separately.

6. Access Review

Periodically verify actual access.

7. JML Process

Manage joiners, movers, and leavers.

8. Revocation Process

Remove access when the business need ends.

9. Evidence

Retain enough evidence to demonstrate that the process operates effectively.

---

44. Quick Audit Checklist

An auditor should be able to select a user and trace:

User → Identity → Business Need → Access Request → Approval → Provisioning → Authentication → Actual Access → Review → Modification → Revocation

Check:

• ☐ User identity verified
• ☐ Business need documented
• ☐ Access approved
• ☐ Appropriate access level selected
• ☐ Least privilege applied
• ☐ Classification considered
• ☐ SoD considered
• ☐ MFA configured where required
• ☐ Privileged access separately controlled
• ☐ Provisioning matches approval
• ☐ Access reviewed
• ☐ Excess access corrected
• ☐ Leaver access revoked
• ☐ Contractor/third-party expiry managed
• ☐ Evidence retained

---

45. Relationship With Other ISMS Documents

Document	Relationship
Identity Management Policy	Defines identity-management requirements
Authentication & Password Policy	Defines authentication requirements
User Access Request Form	Initiates access
Access Control Matrix	Defines role/permission expectations
Identity Register	Records identities
Authentication Information Register	Records authentication mechanisms
Privileged Access Register	Records elevated access
JML Procedure	Manages joiners, movers and leavers
Contractor Account Procedure	Manages contractor accounts
Third-Party Access Procedure	Manages external access
Access Review Report	Records periodic access verification
Access Revocation Checklist	Supports access removal
Segregation of Duties Policy	Addresses conflicting responsibilities
Incident Management	Handles unauthorized/compromised access
Risk Register	Records significant access-related risks

---

46. ISO 27001 Connection

User Access Management supports the organization’s implementation of identity, authentication, access-control, privileged-access, and related information-security controls.

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

The procedure should therefore be implemented as part of the organization’s overall risk-based access-control framework rather than treated as a standalone checklist.

---

47. Final Audit Trail

The organization should be able to demonstrate:

Who is the user?
Why does the user need access?
What information/system is involved?
What access was requested?
Who approved it?
What access was actually granted?
Was authentication appropriately protected?
Was privileged access separately controlled?
Was access periodically reviewed?
Was unnecessary access removed?
Was access revoked when the business need ended?
Can the organization provide evidence?

Final Principle

User access is a lifecycle, not a one-time approval. Give users the access they need, protect it appropriately, review it periodically, remove what they no longer need, and maintain enough evidence to demonstrate that access remains authorized and controlled.