User Access Request Form & Procedure
1. Purpose
The User Access Request process ensures that access to organizational information, applications, cloud environments, networks, databases, SaaS platforms, and other systems is:
- Business-justified
- Authorized
- Limited to the user’s role
- Based on least privilege
- Approved by the appropriate owner
- Provisioned securely
- Traceable through evidence
- Periodically reviewed
Core Principle
Right Person → Right Access → Right System → Right Purpose → Right Time
2. Scope
This process applies to:
- Employees
- Contractors
- Consultants
- Interns
- Temporary workers
- Third-party users
- Service or technical accounts where applicable
It covers access to:
- Corporate applications
- Email and collaboration tools
- SaaS applications
- AWS/Azure/GCP environments
- Production systems
- Development and testing environments
- Databases
- Source-code repositories
- VPN/remote access
- Security systems
- Customer systems
- File-sharing platforms
- Administrative/privileged systems
3. Access Request Lifecycle
The standard process is:
Business Need
↓
Access Request
↓
Verify User
↓
Identify Required Access
↓
Risk & Sensitivity Assessment
↓
Manager Approval
↓
System/Asset Owner Approval
↓
Security Approval Where Required
↓
Provision Access
↓
Verify Access
↓
Record Evidence
↓
Periodic Review
↓
Modify / Revoke When No Longer Required
4. Access Request Information
Every request should contain enough information to determine whether the requested access is appropriate.
| Field | Information |
|---|---|
| Request ID | Unique request number |
| Request Date | Date submitted |
| Requestor | Person requesting access |
| User Name | Person receiving access |
| Employee/Contractor ID | Identification |
| Department | Department/team |
| Job Role | User’s business role |
| Manager | Reporting manager |
| System/Application | System requiring access |
| Environment | Production / Development / Test |
| Access Type | New / Modify / Temporary / Privileged |
| Requested Role | Application role/profile |
| Business Purpose | Why access is required |
| Information Accessed | Type of information |
| Classification | Public / Internal / Confidential / Restricted |
| Access Duration | Permanent / Temporary |
| Start Date | Required date |
| End Date | If temporary |
| Business Owner | Relevant owner |
| System Owner | Relevant system owner |
| Approvals | Required approvals |
| Provisioned By | IT/System Administrator |
| Completion Date | Date access was provided |
| Evidence | Ticket/log/reference |
5. User Information
Requestor
- Name:
- Employee/Contractor ID:
- Department:
- Job Title:
- Manager:
- Email:
- Employment Type:
User Receiving Access
- Name:
- Employee/Contractor ID:
- Department:
- Role:
- Manager:
- Employment Type:
- Start Date:
Where the request is for a contractor or third party, the relevant contract or engagement should also be verified.
6. Access Requested
System/Application
- Application/System:
- Business Process:
- System Owner:
- Environment:
- URL/Resource:
- Requested Role:
Access Type
Select one:
- New Access
- Modify Existing Access
- Temporary Access
- Privileged Access
- Emergency Access
- Third-Party Access
- Project-Based Access
Requested Permissions
Describe specifically what the user needs to do.
Examples:
- Read
- Create
- Update
- Delete
- Approve
- Export
- Configure
- Administer
- Deploy
- Manage users
Avoid vague requests such as:
“Give access to everything required.”
7. Business Justification
The requestor must explain why the access is required.
Example
“The employee is joining the customer support team and requires read-only access to the customer support platform to respond to customer tickets.”
A valid business justification should explain:
What access is needed + Why it is needed + For what business activity
8. Information Being Accessed
Identify the type of information the user may access.
- Public information
- Internal information
- Confidential information
- Restricted information
- Customer information
- Personal data
- Financial information
- Source code
- Security information
- Production data
- Credentials/secrets
- Other: __________
9. Least Privilege Assessment
Before approving access, ask:
- Does the user actually need this access?
- What specific activities will the user perform?
- Can a lower level of access satisfy the requirement?
- Does the user need write access?
- Does the user need delete access?
- Does the user need export/download capability?
- Does the user need production access?
- Does the user need administrative privileges?
- Is the access temporary?
- Does the requested access create segregation-of-duties concerns?
Example
If a support employee only needs to view customer tickets:
Read-only access may be appropriate instead of:
Full administrator access.
10. Privileged Access
Privileged access includes access such as:
- AWS Administrator
- Cloud root-level administration
- Database administrator
- Security administrator
- Identity administrator
- Domain administrator
- Production administrator
- Source-code repository administrator
Privileged access should receive additional scrutiny.
Consider:
- Business justification
- Strong authentication/MFA
- Named individual account
- Least privilege
- Separate administrative account where appropriate
- Approval by appropriate owner
- Logging and monitoring
- Periodic review
- Time-bound access where practical
11. Production Access
Production access should be separately identified.
Questions
- Why is production access required?
- Is non-production access sufficient?
- What exact resources are required?
- Is read-only access sufficient?
- Is the access permanent or temporary?
- Is MFA enabled?
- Is activity logged?
- Is additional approval required?
Example
A developer may require:
Temporary read-only access to production logs for troubleshooting.
This is different from:
Permanent administrator access to the production AWS account.
12. Temporary Access
Temporary access should have:
- Start date
- End date
- Business justification
- Approval
- Defined permissions
- Automatic or manual expiry
- Access revocation confirmation
Example
External security consultant requires AWS read-only access for a VAPT assessment from 10 October to 15 October.
Access should be removed when the engagement ends.
13. Third-Party Access
For contractors, consultants, auditors, suppliers, and other external parties:
Verify:
- Contract/SOW
- Business requirement
- Confidentiality obligations
- NDA where applicable
- Data access requirements
- Security requirements
- Approved scope
- Named users
- Expiry date
- Required monitoring
Third-party accounts should not be shared between multiple individuals.
14. Access Approval
Approval should be based on the type and sensitivity of access.
| Access | Typical Approval |
|---|---|
| Standard business application | Manager / Application Owner |
| Confidential information | Manager + System/Data Owner |
| Production access | Manager + System Owner + Security where required |
| Privileged access | Manager + System Owner + Security/authorized approver |
| Restricted information | Data/System Owner + appropriate security approval |
| Third-party access | Business Owner + System Owner + Security/Procurement where applicable |
| Temporary access | Relevant owner + expiry date |
The exact approval matrix should be defined by the organization.
15. Segregation of Duties
Before approval, check whether the requested access creates a conflict.
Example
A person should not normally be able to:
Create a supplier → Approve the supplier → Approve payment
without appropriate controls.
If separation is not practical in a small organization, documented compensating controls should be considered.
16. Provisioning
After approval, the authorized administrator provisions access.
Provisioning should include:
- Correct user identity
- Correct system
- Correct role
- Correct permissions
- MFA where applicable
- Appropriate authentication
- Required restrictions
- Logging/monitoring
- Expiry for temporary access
The administrator should not provide more access than approved.
17. Access Verification
After provisioning, verify:
- User can access the intended system.
- User has the approved role.
- User does not have excessive permissions.
- MFA is enabled where required.
- Temporary expiry is configured where applicable.
- Access is logged where required.
The verification result should be recorded.
18. AWS SaaS Example
A new engineer joins an AWS-based SaaS company.
Requirement
The engineer needs to troubleshoot application issues.
Request
System: AWS Production
Access: Read-only application/log access
Purpose: Production troubleshooting
Environment: Production
Duration: Permanent, subject to review
Assessment
The engineer does not need:
- IAM administration
- User creation
- KMS administration
- Security policy changes
- Production database deletion
- AWS account administration
Controls
- Individual AWS identity
- SSO
- MFA
- Least-privilege IAM role
- Read-only permissions
- CloudTrail logging
- Periodic access review
Result
The engineer receives only the permissions required for the troubleshooting role.
19. Access Request Approval Record
Manager Approval
- Approved: Yes / No
- Name:
- Role:
- Date:
- Comments:
System/Application Owner Approval
- Approved: Yes / No
- Name:
- Role:
- Date:
- Comments:
Security Approval
Required where applicable.
- Approved: Yes / No / Not Required
- Name:
- Role:
- Date:
- Comments:
20. Provisioning Record
| Field | Details |
|---|---|
| Provisioned By | |
| Provisioning Date | |
| System | |
| Role Granted | |
| Permissions Granted | |
| MFA Enabled | Yes / No / N/A |
| Expiry Configured | Yes / No / N/A |
| Ticket/Change ID | |
| Evidence | |
| Verification Completed | Yes / No |
21. Access Request Decision
Decision
- Approved
- Approved with Conditions
- Rejected
- More Information Required
Conditions
Reason for Rejection / Conditions
Approver
Name: ______________________
Role: ______________________
Date: ______________________
22. Emergency Access
Emergency access may be required during:
- Security incidents
- Critical production failures
- Major outages
- Urgent vulnerability remediation
Emergency access should be:
Authorized → Time-Limited → Logged → Monitored → Reviewed → Revoked
After the emergency, the access should be reviewed and removed if no longer required.
23. Access Modification
When a user’s role changes:
Identify Existing Access → Compare New Role → Remove Unnecessary Access → Add Required Access → Verify → Record
Do not simply add new permissions while leaving old permissions active.
Example
An employee moves from:
Engineering → Customer Support
Engineering access should be reviewed and removed where no longer required.
24. Access Review
Approved access should be periodically reviewed based on organizational risk.
Review should verify:
- User still exists.
- User still has the same role.
- Business need still exists.
- Permissions remain appropriate.
- Privileged access is still required.
- Temporary access has expired.
- Third-party access remains valid.
Higher-risk access may require more frequent review.
25. Access Request Evidence
Maintain evidence such as:
- Access request ticket
- Business justification
- Manager approval
- System owner approval
- Security approval
- Provisioning record
- IAM configuration
- MFA configuration
- Access logs
- Temporary access expiry
- Access review records
- Exception approvals
- Revocation records
26. Common Mistakes
❌ “Give whatever access the employee needs.”
Too vague.
❌ Shared accounts
Individual accountability is lost.
❌ Permanent temporary access
Temporary access should expire.
❌ Manager approval only
Sensitive systems may require system/data owner or security approval.
❌ Add access without removing old access
This creates privilege accumulation.
❌ Returning a laptop means access is removed
Digital access must be separately revoked.
❌ Admin access for convenience
Administrative access should have a documented business need.
27. Startup-Friendly Access Model
A small startup does not need a complicated workflow.
Standard Access
Request → Manager Approval → System Owner → Provision → Verify
Sensitive Access
Request → Business Justification → Manager → System/Data Owner → Security → Provision → Verify
Privileged Access
Request → Risk Review → Manager → System Owner → Security/Authorized Approver → Time/Scope Control → Provision → Monitor → Review
Emergency Access
Emergency → Authorized Approval → Temporary Access → Log → Review → Revoke
28. User Access Request Checklist
Request
- User identified
- Business role identified
- System identified
- Access level identified
- Business justification provided
- Information classification identified
- Production access identified
- Privileged access identified
- Temporary access identified
Approval
- Manager approval
- System/application owner approval
- Data owner approval where required
- Security approval where required
- SoD reviewed
Provisioning
- Correct user account
- Correct permissions
- Least privilege applied
- MFA enabled
- Logging enabled where required
- Expiry configured where applicable
Verification
- Access tested
- Permissions verified
- Evidence recorded
- Request closed
29. Relationship with Other ISMS Documents
The User Access Request supports:
- Access Control Policy
- Access Revocation Checklist
- Employee Offboarding Checklist
- Contractor Offboarding Checklist
- IT Asset Handover Form
- Asset Ownership Register
- Information & Asset Inventory
- Information Classification Policy
- Segregation of Duties Policy
- Privileged Access Management
- Remote Working Policy
- BYOD Policy
- SaaS Application Register
- Cloud Asset Inventory
- Incident Management Procedure
- Risk Register
The overall lifecycle is:
Request → Approve → Provision → Use → Review → Modify → Revoke
30. ISO 27001 Connection
User access requests provide operational evidence that access rights are granted based on business need, authorization, and appropriate security controls.
Relevant areas include:
- Access control
- Identity and authentication
- Least privilege
- Privileged access
- Segregation of duties
- User access lifecycle
- Information classification
- Logging and monitoring
- Supplier/third-party access
The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).
31. Final Audit Trail
A complete access request should allow an auditor to trace:
Who requested access?
↓
Why was access required?
↓
What access was requested?
↓
Who approved it?
↓
What access was actually provisioned?
↓
Was it verified?
↓
Was it reviewed?
↓
When was it modified or revoked?
Final Principle
Access should never be granted simply because someone asks for it. It should be requested for a defined business need, approved by the appropriate authority, limited to the required permissions, securely provisioned, periodically reviewed, and revoked when no longer required.