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:
- Business need
- Least privilege
- Need-to-know
- Individual accountability
- Unique user identity
- Appropriate authentication
- MFA where required
- Role-based access where practical
- Separation of duties
- Time-limited access where appropriate
- Privileged access protection
- Periodic access review
- Prompt access removal
- Traceability and evidence
- 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
- 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.