Purpose #

The purpose of this SOP is to ensure user access requests are handled through a consistent, secure, and documented approval process. This reduces the risk of unauthorised access, over-permissioning, data exposure, and confusion when staff require access to client systems or resources.

Scope #

This SOP applies to requests involving:

• New or changed Microsoft 365 access
• Mailbox, shared mailbox, calendar, and distribution list access
• SharePoint, OneDrive, Teams, and file share access
• Line-of-business application access
• VPN, remote access, or remote desktop access
• Security group or role membership changes
• Printer, device, or network resource access
• Temporary access for projects, contractors, or leave coverage
• Removal or correction of incorrect access

Access Request Classification #

Access Control Principles #

• Access must not be granted without documented approval from an authorised client contact.
• Grant the minimum access required for the user to perform their role.
• Do not copy another user’s access blindly without confirming the business need.
• Temporary access must include an expiry date or review date.
• Privileged, administrator, payroll, finance, HR, security, or owner-level access must be escalated for review.
• Access requests from personal email addresses, verbal-only requests, or unverified contacts must not be actioned.
• All access changes must be documented in the ticket and, where appropriate, the client’s access register or internal documentation.

Workflow Steps #

1. Receive the access request.
   Confirm the requester, client, affected user, requested system or resource, business reason, urgency, and whether the request is for new, changed, temporary, or removed access.
2. Verify requester authority.
   Confirm the request came from an authorised client contact, manager, department head, business owner, or approved workflow. Do not proceed on verbal-only or unverified requests.
3. Confirm the exact access required.
   Identify the mailbox, folder, SharePoint site, Teams group, application, security group, VPN profile, device, or permission level being requested.
4. Check business justification.
   Confirm why the user needs the access, how long they need it, and whether the requested access aligns with their role.
5. Review risk level.
   Determine whether the request involves sensitive data, elevated permissions, financial systems, HR data, admin access, security tools, remote access, or client owner-level access.
6. Obtain documented approval.
   Ensure approval is captured in the ticket before any access is granted. For elevated or sensitive access, escalate before proceeding.
7. Apply least privilege.
   Grant only the access needed. Avoid broad groups, global admin roles, full mailbox access, full file share access, or unrestricted remote access unless specifically approved.
8. Provision the access.
   Add the user to the approved group, mailbox, SharePoint site, Teams team, application role, VPN profile, or resource using the correct administrative method.
9. Validate access.
   Confirm the change has applied, the user can access the required resource, and no unintended permissions were granted.
10. Update documentation.
    Record the access granted, approver, reason, date, technician, expiry or review date, and any related client documentation updates.
11. Notify the requester.
    Confirm the request is complete, advise of any limitations, and remind the requester that future access changes must follow the same approval process.

User Access Request Checklist #

• ☐ Requester confirmed
• ☐ Requester authority verified
• ☐ Client and affected user confirmed
• ☐ Requested system/resource identified
• ☐ Exact permission level confirmed
• ☐ Business reason documented
• ☐ Temporary access expiry date captured, if applicable
• ☐ Risk level reviewed
• ☐ Approval documented in the ticket
• ☐ Least privilege applied
• ☐ Access provisioned correctly
• ☐ Access validated
• ☐ Client documentation updated where required
• ☐ Requester notified of completion

Security Awareness Notes #

• User access changes are security-sensitive and must never be treated as routine admin work without approval.
• Attackers may attempt to impersonate managers or staff to gain access to mailboxes, files, finance systems, or remote access tools.
• Requests involving payroll, bookkeeping, banking, HR, confidential files, administrator roles, or shared mailboxes require extra caution.
• Do not rely on email display names alone. Confirm the sender address and approval authority.
• If the request seems unusual, urgent, secretive, or inconsistent with the user’s role, escalate before making changes.
• Never share passwords or bypass MFA as part of an access request.
• Access granted for temporary reasons must be reviewed or removed when no longer required.

Escalation Triggers #

Escalate to Level 2, senior support, cybersecurity, or the authorised client decision-maker when:

• The requester is not listed as an authorised contact
• The request is urgent but lacks proper approval
• The request involves administrator, owner, global admin, security admin, or privileged access
• The request involves finance, payroll, HR, legal, confidential, or sensitive client data
• The request appears suspicious, unusual, or inconsistent with the user’s role
• The request asks to copy another user’s access without explanation
• The request involves bypassing MFA, password sharing, or disabling security controls
• The request requires changes to conditional access, security groups, firewall rules, VPN, or remote access policy
• The technician is unsure whether the access is appropriate

Documentation Standards #

Every user access request ticket must include:

• Requester name and contact details
• Affected user name and account identifier
• Client name and site or department, if applicable
• Requested system, mailbox, folder, group, application, or resource
• Requested permission level
• Business reason for the access
• Approval source and approver name
• Date and time approval was received
• Access granted or changed
• Technician who completed the change
• Validation result
• Expiry or review date for temporary access
• Escalation notes, if applicable

Client Communication Scripts #

Common Mistakes to Avoid #

• Granting access based only on a verbal request
• Granting access before confirming the requester is authorised
• Copying another user’s permissions without reviewing the business need
• Granting broad access when limited access would be sufficient
• Forgetting to record the approver and business reason
• Failing to set an expiry or review date for temporary access
• Making privileged access changes without escalation
• Closing the ticket before confirming the access works as intended

Completion Criteria #

• The requester’s authority has been verified.
• The business reason and exact access required have been documented.
• Approval has been captured in the ticket before changes were made.
• Access has been granted using least privilege.
• Temporary access includes an expiry or review date.
• Access has been validated with the user or requester.
• The ticket includes complete documentation of approval, action, and outcome.

Quality Standard #

A completed user access request must clearly show who requested the access, who approved it, why it was needed, what exact permissions were granted, when the change was made, whether it was validated, and whether the access requires future review. Another PrecisionTech technician should be able to audit the ticket without needing additional clarification.

Version History #