Why this matters
Access requests look like small admin tasks. They are the point where security, speed and money meet. Handled in chat, you end up with no record of who asked, who said yes, or what was granted. Then someone leaves and their accounts stay live for months.
Both failure modes cost you. Slow requests push people to share logins or keep a private copy of a tool, and that is hard to unwind. Loose requests spread a paid seat to people who open the app twice a year, and each account is a way in.
The fix is a dull process: one form, named approvers, provisioning through groups, and a review you can show a security reviewer. This guide on how to handle software access requests covers building that for a company of twenty to a few hundred people.
Before you start
List your applications before you approve anything. Pull the list from your identity provider, the software lines on your finance reports, and a pass through bookmarks on managed devices. For each app, write the owner (a person, not a team), the data it holds, and whether login goes through single sign on.
Find your source of truth for people. That is the HR system, or the payroll export if HR is thin. Every request should point to a person record with a manager and a start date, because joiners and leavers cause most access problems.
Decide in writing who can approve what. A three tier matrix works: low risk tools any manager can approve, medium risk needs the app owner, high risk needs the app owner plus whoever owns the data, such as finance or customer records. Name a backup approver for every tier so one holiday does not stall the queue.
Pick where requests live. A ticketing tool with a request form beats email because you get categories, timestamps and searchable history. Check that it supports approval steps and reminder emails before you commit.
How to do it
The flow has four stages: intake, decision, provisioning and record. Keep each stage in one place so nothing depends on someone remembering a call. The steps below build it. A small team can run a first version within a week and tighten it after twenty requests.
Intake. The form asks for the person, the application, the role or scope, the business reason, how long it is needed, and who pays for the seat. Make the application a dropdown fed by the catalog, so nobody types the design tool three ways. If the app has roles, list them in plain words: viewer, editor, admin.
Decision. Route by tier, and show the approver what the person already has. That turns a yes or no into a yes to the gap, which is usually a smaller grant. Write the approved scope into the ticket so the person doing the provisioning does not guess.
Provisioning and record. Do the work through a group in your identity provider rather than by hand in each app. Close the ticket with what was granted, when, and when it expires. That expiry field is what makes a review possible later.
- Write a short app catalog. List every application that holds company data or a paid seat. For each one, record the owner, the login method and the roles it offers.
- Assign one owner per app. The owner answers access questions and reviews the user list each quarter. Pick someone who uses the tool, not whoever is highest up.
- Set approval tiers. Sort apps into low, medium and high risk. Write down who approves each tier and who covers when that person is away.
- Build the request form. Add fields for person, app, role, reason, duration and cost owner. Make the app a dropdown and show the role list only after an app is chosen.
- Map roles to groups in your identity provider. Create one group per app and role, named for both. Give the app access to that group and nothing else, so provisioning becomes a membership change.
- Provision, then timestamp. Make the change, then log the group, the approver and the expiry in the ticket. Hold a response target you can keep, such as same business day for tier one.
- Put an expiry on elevated access. Admin and finance roles should carry a date. When the date passes, the group membership drops without anyone chasing it.
- Close the loop with the requester. Send a short message with what was granted and how to ask for more. It reduces repeat tickets and leaves a written trace.
- Run a quarterly access review. Send each app owner their user list with one question: keep or remove. Record the answers in the ticket so removals carry a date.
How to check it worked
Track three numbers: time from request to working access, the share of requests that came through the form, and the number of accounts removed at review. A low form share means people are still asking in chat and your record is incomplete.
Trace ten closed requests each month from end to end. Confirm the approver sat in the right tier, the group matches the role requested, and the close note is there. Broken paths surface fast this way.
Compare group membership in your identity provider with the app's own user list for two or three apps. People who left or moved teams show up here long before they show up in an incident.
Read a few tickets the way a requester would. Cut any field the approver never reads. If the same question keeps arriving in the queue, fix the form text instead of answering it again.
Mistakes to avoid
Approving in chat. A thumbs up in a direct message is not a record. If a request arrives that way, paste it into the tool and have the approver confirm there.
Handing out the admin role because it is faster. Broad roles stick. Grant the narrow one, and if admin is genuinely needed, put an expiry date on it.
Forgetting the mover case. When someone changes team, old access usually stays. Treat a role change as a leaver plus a joiner: pull the old groups, then add the new ones.
Letting the queue rest on one approver, or on a shared mailbox nobody owns. Set the backup rule and check the queue weekly for anything past your target. If building this from scratch is too much on top of everything else, a managed setup is one option among several. Cloudverg's IT service desk setup is $6,500/month and covers an access request and approval workflow, inventory tied to people, and joiner, mover and leaver checklists.
Frequently asked questions
Who should approve a software access request?
The person who owns the application, and the owner of any sensitive data it touches. A direct manager can approve low risk tools but should not be the only approver for finance, payroll or customer records. Name a backup for each approver.
What should an access request form include?
The person, the application, the exact role or scope, the business reason, how long the access is needed, and who pays for the seat. Add the manager and a project name so the request makes sense six months later. Keep it short enough to finish in a minute or two.
How often should you review who has access?
Quarterly for apps holding sensitive data such as customer records or payroll, and once a year for everything else. Send each owner their user list with one instruction: keep or remove. Log the answers in your ticketing tool so every removal has a date and a name.