IT account provisioning and access requests
Access provisioning is where least privilege either happens or quietly does not. When requests arrive by chat and get actioned on trust, nobody can later answer who approved an access grant or why a departed contractor still has a login. This procedure makes the approval and the justification part of the request rather than an afterthought.
- 1
Requesting Manager submits the request naming the person, the system, the access level, and the business reason.
Requesting Manager
The business reason is not bureaucracy. It is what lets anyone later judge whether the access is still needed, and requests without one cannot be reviewed.
- 2
IT Administrator confirms the request came from that person's actual manager.
IT Administrator
Requests arriving from the person who wants the access, or from a colleague acting helpfully, are the most common route to unauthorised access. Verify through a known channel, never by replying to the request itself.
Verified: go to step 3
Cannot verify: go to step 10
- 3
IT Administrator checks whether the requested level is privileged or grants access to customer data.
IT Administrator
Standard access: go to step 5
Privileged or customer data: go to step 4
- 4
System Owner reviews and approves the request, and records that approval.
System Owner
A second approver for privileged access, recorded. This is the control an auditor tests, and it only exists if the record does.
Approved: go to step 5
Denied: go to step 10
- 5
IT Administrator grants the minimum access that satisfies the stated reason, using a role or group rather than individual permissions.
IT Administrator
Groups over individual grants. Individually granted permissions are invisible in aggregate and nearly impossible to review later.
- 6
IT Administrator records the grant: who, what system, what level, who approved, and the date.
IT Administrator
This record is what makes the periodic review in step 8 and offboarding possible at all. Without it both become guesswork.
- 7
IT Administrator confirms the access works and notifies the Requesting Manager, without sending credentials over an unencrypted channel.
IT Administrator
Never send a password by email or chat. Use a first-login reset or your password manager's sharing mechanism.
- 8
System Owner reviews all access to their system on a defined cadence and confirms each grant is still needed.
System Owner
Timing: Quarterly
The reviewer has to be the person who understands what the access does, not IT. IT can produce the list but cannot judge necessity.
All still required: the procedure ends
Access no longer needed: go to step 9
- 9
IT Administrator revokes the unneeded access and records the revocation and its date.
IT Administrator
Revocations are recorded exactly like grants. "When was this removed" is asked as often as "who approved this".
Revoked: go to step 8
- 10
IT Administrator records the request as denied with the reason and informs the Requesting Manager.
IT Administrator
Record denials too. A denied request that is resubmitted through a different route is a signal worth being able to see.
Recorded: the procedure ends
Change these before you use it
- Define what counts as privileged in step 3 for your systems, explicitly and in writing. Left vague, everything becomes standard access.
- Name your actual request channel. A procedure that says "submits the request" without naming where will be bypassed by chat messages.
- Set the review cadence in step 8 per system rather than uniformly. Customer data monthly and an internal wiki annually is more realistic than quarterly for everything.
- If you use single sign-on and an identity provider, most of steps 5 to 7 become group membership changes, and the procedure gets shorter and more reliable.
- Connect this to your offboarding procedure so the grant record in step 6 is the checklist used on someone's last day.
This is a starting point, not compliance advice. It is written to be adapted, and a procedure that touches access, money, or customer data needs to match how your business actually operates and whatever rules apply to you. Use it as a first draft to edit, not a policy to adopt.
Make it yours in a couple of minutes
Rather than retyping this and editing it, describe your own version of the process out loud or click through it once, and get a first draft with your actual steps, roles, and systems in it. No account needed to see the result.
No account neededNo credit cardSee the whole SOP before you sign up