1. Purpose
The User Access Request Form is used to formally request, review, approve, provision, modify, or revoke a user’s access to organizational information, systems, applications, cloud environments, databases, SaaS platforms, networks, and other technology resources.
The form provides evidence that access was:
- Requested for a valid business purpose
- Appropriate for the user’s role
- Reviewed against least-privilege requirements
- Approved by an authorized person
- Provisioned correctly
- Periodically reviewed
- Modified or removed when no longer required
Core principle:
Business Need → Request → Verify → Approve → Provision → Verify → Review → Revoke
2. When to Use This Form
Use this form for:
- New employee access
- Contractor or consultant access
- Third-party access
- New application access
- Access to customer systems
- Cloud access
- Database access
- Source-code repository access
- Production access
- Privileged or administrative access
- Temporary access
- Additional access
- Role changes
- Access modifications
- Access restoration
- Emergency access
- Access revocation
3. Request Information
| Field | Details |
|---|---|
| Access Request ID | |
| Request Date | |
| Requested By | |
| Requester Department | |
| Request Type | New / Modify / Temporary / Emergency / Revoke |
| Required From | |
| Required Until | |
| Priority | Normal / High / Critical |
| Related Project/Business Process | |
| Related Ticket/Change ID |
4. User Information
| Field | Details |
|---|---|
| User Name | |
| Employee/Contractor ID | |
| Email Address | |
| Department | |
| Job Title | |
| Manager | |
| Employment Type | Employee / Contractor / Consultant / Third Party |
| Organization | |
| Start Date | |
| End Date, if applicable | |
| User Status | Active / Temporary / External |
The user’s identity should be verified before access is provisioned.
5. Business Justification
Business Purpose
Why does the user require this access?
Business Activity Supported
What would happen if access is not provided?
Access should be based on a documented business need rather than convenience or broad job-role assumptions.
6. Information and System Requested
| Resource | System/Application | Environment | Information Accessed | Classification | Access Required |
|---|---|---|---|---|---|
| Production / Test / Dev | Public / Internal / Confidential / Restricted |
Examples:
- Microsoft 365
- GitHub
- Jira
- AWS
- Production database
- Customer portal
- VPN
- Security platform
- Finance application
- HR system
7. Access Level Requested
Select the minimum access required.
| Access Level | Requested |
|---|---|
| Read Only | ☐ |
| Standard User | ☐ |
| Create/Modify | ☐ |
| Data Export | ☐ |
| Application Administrator | ☐ |
| System Administrator | ☐ |
| Database Administrator | ☐ |
| Cloud Administrator | ☐ |
| Security Administrator | ☐ |
| Production Access | ☐ |
| Privileged Access | ☐ |
| Emergency/Break-Glass | ☐ |
| Other | ☐ |
Specific Permissions Required
Avoid generic requests such as “Full Access” unless the business requirement genuinely requires it.
8. Access Scope
Clearly define the resources the user can access.
| Area | Details |
|---|---|
| Application | |
| AWS/Azure/GCP Account | |
| Database | |
| Repository | |
| Network/VPN | |
| SaaS Platform | |
| Customer Environment | |
| Data/Information | |
| Specific Role | |
| Specific Permissions |
9. Authentication Requirements
| Requirement | Applicable |
|---|---|
| Corporate Identity/SSO | ☐ |
| MFA | ☐ |
| Security Key/Passkey | ☐ |
| VPN | ☐ |
| Device Management | ☐ |
| Conditional Access | ☐ |
| Privileged Authentication | ☐ |
| Other | ☐ |
Where required, access should use approved authentication mechanisms and individually attributable accounts.
10. Privileged Access Assessment
Complete this section when elevated or administrative access is requested.
Is privileged access required?
☐ No
☐ Yes
Why is privileged access required?
Can standard access meet the requirement?
☐ Yes
☐ No
If No, explain:
Privileged Role Requested
Production Access Required?
☐ No
☐ Yes
Temporary Privileged Access?
☐ No
☐ Yes
If temporary:
Start: __________
Expiry: __________
Privileged access should be separately reviewed and recorded in the Privileged Access Register.
11. Third-Party / Contractor Access
Complete when the user is external to the organization.
| Field | Details |
|---|---|
| Third-Party Organization | |
| Internal Sponsor | |
| Contract/SOW Reference | |
| NDA in Place | Yes / No / N/A |
| Access Start Date | |
| Access Expiry Date | |
| Systems Required | |
| Information Accessed | |
| Security Assessment Completed | Yes / No / N/A |
Third-party access should normally have a defined business purpose and expiry date.
12. Temporary Access
Is the access temporary?
☐ No
☐ Yes
If Yes:
| Field | Details |
|---|---|
| Business Reason | |
| Start Date/Time | |
| Expiry Date/Time | |
| Auto-Expiry Configured | Yes / No |
| Approver | |
| Review Required | Yes / No |
Temporary access should be removed when the approved period ends.
13. Risk Assessment
Consider:
- Information classification
- System criticality
- Production access
- Customer data
- Personal data
- Financial information
- Source code
- Security information
- Privileged permissions
- External/third-party access
- Remote access
- Duration of access
- Potential segregation-of-duties conflict
Risk Level
☐ Low
☐ Medium
☐ High
☐ Critical
Risk Considerations
Compensating Controls, if required
14. Segregation of Duties Check
Does the requested access create a potential conflict with another responsibility?
☐ No
☐ Yes
☐ Not Applicable
If Yes:
Conflict Identified:
Compensating Control:
Approver:
15. Approvals
Access should be approved before provisioning unless an authorized emergency process applies.
| Approval | Name | Decision | Date | Comments |
|---|---|---|---|---|
| User’s Manager | Approve / Reject | |||
| System/Application Owner | Approve / Reject | |||
| Data Owner, if applicable | Approve / Reject | |||
| Security/ISMS, if required | Approve / Reject | |||
| Privileged Access Approver | Approve / Reject | |||
| Business Owner | Approve / Reject |
Not every request requires every approval listed above. The organization should define approval requirements based on access risk.
16. Access Provisioning Record
To be completed by IT/IAM/System Administrator.
| Field | Details |
|---|---|
| Account/Identity Created | |
| Identity/Account ID | |
| System/Application | |
| Role Assigned | |
| Permissions Granted | |
| MFA Enabled | Yes / No / N/A |
| SSO Configured | Yes / No / N/A |
| Start Date | |
| Expiry Date | |
| Provisioned By | |
| Provisioning Date | |
| Ticket/Change Reference |
17. Access Verification
After provisioning, verify that the user received only the approved access.
Verification Checklist
- ☐ Correct user identity
- ☐ Correct system
- ☐ Correct environment
- ☐ Correct role
- ☐ Correct permissions
- ☐ Least privilege applied
- ☐ MFA enabled where required
- ☐ Temporary expiry configured where required
- ☐ Privileged access separately recorded
- ☐ No unnecessary access granted
- ☐ Access successfully tested
- ☐ Evidence retained
Verified By: ____________________
Date: ____________________
18. AWS Access Example
For an AWS-based SaaS organization, an access request might look like:
| Field | Example |
|---|---|
| User | Developer |
| Business Need | Application development |
| Environment | Development |
| AWS Account | Development Account |
| Authentication | Corporate SSO + MFA |
| Role | Developer |
| Access | Application resources and development logs |
| Production Access | No |
| Production Administrator | No |
| Approval | Engineering Manager + System Owner |
| Evidence | IAM Identity Center configuration and access request |
If production access is subsequently required, it should be requested and approved separately according to the organization’s privileged/production access process.
19. Access Modification
Use this section when changing existing access.
Existing Access
Access to Remove
Access to Add
Reason for Change
Role Change?
☐ No
☐ Yes
When a user’s role changes, existing access should be reassessed rather than simply adding new permissions.
20. Access Revocation
Use when access is no longer required.
Reason
☐ Employee Leaving
☐ Contractor Engagement Ended
☐ Role Change
☐ Project Completed
☐ Access No Longer Required
☐ Security Incident
☐ Credential Compromise
☐ Temporary Access Expired
☐ Other
Revocation Checklist
- ☐ Account disabled/revoked
- ☐ Application access removed
- ☐ SaaS access removed
- ☐ Cloud access removed
- ☐ Production access removed
- ☐ Privileged roles removed
- ☐ VPN access removed
- ☐ Repository access removed
- ☐ API tokens/keys reviewed
- ☐ Active sessions terminated where required
- ☐ Physical access removed where applicable
- ☐ Identity Register updated
- ☐ Access records updated
Revoked By: ____________________
Date/Time: ____________________
21. Emergency Access
Emergency access may be granted when immediate action is required to protect systems, information, customers, or business operations.
Emergency access should be:
- Explicitly authorized
- Limited to the required scope
- Individually attributable where practical
- Strongly authenticated
- Logged/monitored according to risk
- Time-limited where practical
- Reviewed after use
Emergency Reason
Approver
Post-Event Review Completed
☐ Yes
☐ No
22. Exceptions
Any deviation from normal access requirements should be documented.
| Exception | Reason | Risk | Compensating Control | Approver | Expiry |
|---|---|---|---|---|---|
Exceptions should not become permanent access arrangements without appropriate review.
23. Evidence to Retain
Depending on the request, evidence may include:
- Completed User Access Request Form
- Manager approval
- System owner approval
- Data owner approval
- Security approval
- IAM/SSO configuration
- AWS IAM Identity Center records
- Application role assignment
- MFA configuration
- Access provisioning ticket
- Change record
- Privileged Access Register entry
- Access review record
- Access revocation evidence
- Exception approval
- Third-party contract/SOW/NDA
- Audit logs
Never record passwords, API keys, access tokens, MFA secrets, recovery codes, private keys, or other actual authentication secrets in this form.
24. User Acknowledgement
I confirm that:
- I have requested access for a legitimate business purpose.
- I will use the access only for authorized activities.
- I will protect authentication information assigned to me.
- I will not share my account or credentials.
- I will comply with applicable security policies.
- I will immediately report suspected unauthorized access or credential compromise.
User Name: ____________________
Signature/Approval: ____________________
Date: ____________________
25. Final Approval
Access Decision:
☐ Approved
☐ Approved with Conditions
☐ Rejected
☐ Pending Additional Information
Final Approver: ____________________
Date: ____________________
Comments/Conditions:
26. Access Request Record
| Field | Details |
|---|---|
| Request ID | |
| User | |
| Access Granted | |
| Approval Date | |
| Provisioning Date | |
| Expiry Date | |
| Review Frequency | |
| Last Review | |
| Next Review | |
| Current Status | Active / Expired / Revoked |
| Related Identity ID | |
| Related Privileged Access ID | |
| Related Risk ID | |
| Evidence Location |
27. Relationship With Other ISMS Documents
The User Access Request Form should work as part of the broader access-control lifecycle:
User Access Request → Approval → User Account Management → Access Provisioning → Identity Register → Access Review → Access Modification/Revocation
Related documents include:
- Identity Management Policy
- Authentication & Password Policy
- Access Control Policy
- Access Control Matrix
- Identity Register
- Authentication Information Register
- Privileged Access Register
- Joiner-Mover-Leaver Procedure
- Contractor Account Procedure
- Third-Party Access Procedure
- Access Review Report
- Access Revocation Checklist
- Segregation of Duties Policy
- Asset Return Checklist
- Employee Offboarding Checklist
- Credential Compromise Response Procedure
28. Startup-Friendly Implementation
A small SaaS organization does not necessarily need a complex IAM platform to demonstrate this control.
A controlled ticketing system, workflow tool, or GRC spreadsheet can be used initially.
The minimum process should be:
1. User identified
↓
2. Business need documented
↓
3. Access requested
↓
4. Appropriate owner approves
↓
5. Least privilege applied
↓
6. MFA/authentication configured
↓
7. Access provisioned
↓
8. Provisioning verified
↓
9. Access periodically reviewed
↓
10. Access removed when no longer required
For higher-risk access such as production, administrator, database, security, or cloud access, use additional approval and review controls.
29. Quick Audit Checklist
An auditor should be able to select a sample user and answer:
- ☐ Was the user properly identified?
- ☐ Was there a documented business need?
- ☐ Was access approved?
- ☐ Was the correct system identified?
- ☐ Was information classification considered?
- ☐ Was least privilege applied?
- ☐ Was MFA configured where required?
- ☐ Was privileged access separately controlled?
- ☐ Was access actually provisioned as approved?
- ☐ Can provisioning be evidenced?
- ☐ Was access reviewed periodically?
- ☐ Was unnecessary access removed?
- ☐ Was access revoked when the user left or no longer needed it?
- ☐ Are exceptions documented?
- ☐ Can the organization demonstrate the complete audit trail?
30. ISO 27001 Connection
The User Access Request Form supports the organization’s broader implementation of identity and access-management controls.
The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA) rather than treating this form as evidence that every access-related control is automatically applicable.
The form provides an important audit trail connecting:
Business Need → Identity → Access → Approval → Control → Evidence → Review → Revocation
31. Final Audit Trail
For every important access request, the organization should be able to demonstrate:
Who requested the access?
Why was it required?
What information/system was involved?
What level of access was requested?
Who approved it?
What access was actually granted?
Was authentication appropriately protected?
Was the access reviewed?
When was it modified or revoked?
Can the organization provide evidence?
Final Principle
Do not grant access simply because someone asks for it. Identify the business need, verify the user, define the minimum required access, obtain appropriate approval, provision securely, verify the result, review it periodically, and remove it when the business need ends.