75% of access requests should not need a human in IT touching groups by hand. If managing IT access requests still means Jira tickets, Slack pings, Okta tabs, and a spreadsheet for audit evidence, you're not doing governance. You're doing admin cleanup.
I've seen this pattern a lot with fast-growing companies. At 100 employees, manual access feels manageable. At 500, it becomes a queue. At 1,200, like Luno, hundreds of routine requests start showing up across Slack, email, and Jira, and IT ends up chasing approvals instead of fixing higher-value problems.
The mistake is treating access as a ticket problem. It’s really an evidence problem, because every request eventually has to answer three questions: who approved it, what changed, and when did it get removed?
Key Takeaways:
- Managing IT access requests breaks when approvals, provisioning, and audit evidence live in different tools.
- The real bottleneck usually isn’t requester volume. It’s the handoff between Jira, Slack, and your identity provider.
- If a request takes longer than 15 minutes to route, approve, and provision, you should look for automation points.
- Audit-ready access means the ticket, approval, provisioning action, and revocation all stay tied together.
- Time-bound access should be the default for admin roles, production systems, and sensitive data.
- Access reviews work better when reviewers can see usage context before making keep or revoke decisions.
If you want to see what Jira-native access governance looks like in practice, Learn more about Multiplier.
Why IT Access Requests Break Inside Split Systems
IT access requests break when intake, approval, provisioning, and evidence are split across too many systems. Jira may hold the ticket, Slack may hold the decision, Okta or Entra may hold the actual access, and a spreadsheet may hold the audit story. That split creates delay, risk, and cleanup work.
The ticket is usually not the bottleneck
Most IT teams blame request volume first. Fair. When the company is hiring fast, the queue gets ugly. New hires need Slack, Zoom, Jira, GitHub, Figma, Salesforce, finance tools, data tools, admin roles, temporary access, and a bunch of random “can I get access to this?” one-offs. It piles up fast.
But the ticket itself is rarely the thing slowing you down. The slow part is everything around the ticket. Someone has to know who approves the app. Someone has to find the right group. Someone has to make the change in the identity provider. Someone has to prove it happened later. I’d argue that if your access request process requires more than two tool switches after ticket creation, you’ve already created the problem.
Picture an IT service manager at 9:12 AM on a Tuesday. A product manager asks for editor access to a design tool in Slack, a new engineer files a Jira ticket for GitLab access, and a finance hire emails their manager about NetSuite. Three requests. Three channels. Three different evidence trails. By lunch, the work isn’t hard, but the tracking is broken.
Audit evidence gets expensive when you recreate it later
Audit evidence gets expensive when the workflow wasn’t designed to create it in the first place. The NIST SP 800-53 access control family is pretty clear that account management needs documented approvals, changes, and removals. Auditors don’t just ask whether access exists. They ask why it exists.
The trap is that most companies treat evidence as an after-the-fact activity. They approve access in Slack, provision it in the identity provider, then rebuild the story in a spreadsheet before SOC 2 or ISO 27001. It feels normal because everyone does it. Still, it’s a bad operating model. You’re paying twice for the same work.
Luno is a good example of what happens when growth exposes the weakness. They grew to nearly 1,200 employees and saw routine access requests coming through Slack, email, and Jira. IT had to chase managers and manually assign Okta groups. Each request might only take 5 to 30 minutes, which sounds small until hundreds of them hit the queue.
Standing access becomes the shortcut nobody meant to create
Standing access grows when temporary access is annoying to request and annoying to remove. If getting admin access takes too long, people ask for broader roles. If removing access takes manual follow-up, the cleanup gets pushed to later. Later usually means “when the audit forces us.”
Security teams know this is risky. The Verizon 2024 Data Breach Investigations Report continues to show the role credentials play in breaches, which is why least privilege keeps coming up in board decks and security reviews. But least privilege fails when the operational path is too painful. People will always route around friction when work is blocked.
That’s the part that makes managing IT access requests so frustrating. The company says it wants speed and control. The workflow gives you neither. So the better question is not “how do we process more tickets?” It’s “how do we make the right access path the easiest path?”
How to Build an Access Request System That Audits Itself
An access request system audits itself when each request creates a complete record as work happens. The request, approval, identity provider change, expiry, and review outcome should all tie back to one source of truth. For Jira-heavy teams, that source should usually be the Jira issue.
Diagnose where your access process is actually leaking
3 questions will tell you more than a 20-slide process review. Where does the request start? Where does approval happen? Where is the actual access changed? If the answers point to three different tools, your process is leaking evidence and time.
I like starting with a very boring audit. Take the last 25 access requests and trace each one from request to closure. Don’t interview people yet. Just look at the record. If you can’t tell who approved the request, which identity provider group changed, and whether access expired, the process isn’t audit-ready. It might be functional. Different thing.
Use these checks before you automate anything:
- Count tool switches: More than two after request creation usually means delay is baked in.
- Check approval location: Approval outside the ticket needs to be copied back or it won’t survive audit pressure.
- Trace the group change: If the Jira issue doesn’t show the Okta, Entra, or Google Workspace action, evidence is incomplete.
- Look for expiry: Admin and sensitive access without a removal date should be treated as standing privilege.
- Sample closed tickets: If 5 out of 25 tickets can’t prove what changed, the system is weaker than it looks.
A quick concession though. Not every app can be fully automated. Some legacy tools, finance systems, or niche SaaS apps still need manual provisioning. That’s fine. The point isn’t to automate every weird edge case on day one. The point is to make the standard path clean enough that the exceptions are obvious.
Put intake where employees already ask for work
A product manager asking for Figma access doesn’t care about identity governance. They care about doing their job. If the access process starts in a separate IGA portal they rarely use, adoption drops. Then people go back to Slack, because Slack is where work already happens.
For Jira Service Management shops, the request should start in JSM or chat, then create a structured Jira issue automatically. App, role, reason, duration, requester, manager, approver. All of it should be captured up front. No “what access level do you need?” comment thread two hours later. No IT person guessing whether “Figma access” means Viewer, Editor, or Admin.
The practical rule is simple: if IT has to ask a follow-up question on more than 20% of access tickets, your intake form is under-specified. Add role choices. Add app owners. Add duration for sensitive roles. Add a required business reason for higher-risk access. Not a giant form. Just enough structure to make the next action obvious.
A self-service app catalog works like a restaurant menu for internal tools. Not because it’s cute, but because it limits ambiguity. People pick from sanctioned apps, choose the role they need, and the system knows who should approve it. The kitchen doesn’t get “make me food.” IT shouldn’t get “give me access.”
Route approvals based on risk, not habit
Who should approve access? The lazy answer is “the manager.” Sometimes that’s right. Often it isn’t. Managers know whether the person needs the tool for their job, but app owners usually know whether the requested role is risky.
For low-risk tools, auto-approval may be perfectly reasonable. For department tools, manager approval may be enough. For admin roles, production access, finance systems, security tools, or customer data, approval should go to the app owner or system owner. If you treat every request the same, you either slow everything down or under-control the risky stuff. Usually both.
A usable approval model has three lanes:
- Low-risk access: Auto-approve or route to manager with minimal friction.
- Business app access: Route to manager or app owner depending on role.
- Privileged access: Require app owner approval, duration, and clear revocation.
I’ve seen teams overcorrect here. They get burned once, then add approval layers to everything. That makes the process look safer on paper, but it pushes people back into side channels. Better to be strict where the risk is real and fast where it isn’t. That’s how you get compliance without making everyone hate IT.
Provision through identity provider groups
Access changes should happen through identity provider groups whenever possible. If Jira says approved, the next step shouldn’t be an IT admin opening Okta, finding the user, finding the group, making the change, and commenting “done.” That’s exactly the kind of copy-paste work that breaks at scale.
Group-based provisioning gives you a cleaner chain. The app role maps to a group. Approval changes the ticket status. The identity provider API adds the user to the mapped group. The ticket records the action. For SSO apps, the downstream entitlement flows from the identity provider to the app through the normal SAML or SCIM path.
A threshold worth using: if an app receives 10 or more access requests per month, map its common roles to identity provider groups. Under that volume, manual handling may be acceptable for now. Above it, the admin time and audit cleanup usually cost more than the setup effort.
The IBM Cost of a Data Breach Report 2024 puts real numbers behind security failures, but the operational lesson is smaller and more daily. Manual identity changes create more chances for stale access, missed revocation, and unclear evidence. You don’t need a giant breach model to justify fixing that. You just need to count how many times someone says, “Wait, who gave them access?”
If you’re at the point where requests are growing but headcount isn’t, See how Multiplier works.
Make expiry the default for sensitive access
Temporary access should be the default for sensitive systems. Not a special process. Not a weird exception. If someone needs admin access for 1 hour, 6 hours, or 24 hours, the request should include the duration before approval.
Stavvy is a strong example. After funding and acquisitions, they had long-lived privileged access hanging around. They moved to just-in-time access and reduced privileged access by 85%, with more than 1,300 access requests automatically revoked after approved windows. That matters because the biggest risk often isn’t the original grant. It’s the access nobody remembered to remove.
Use a simple rule here:
- Production access gets a duration.
- Admin roles get a duration.
- Sensitive customer data gets a duration.
- Break-glass access gets a duration and a reason.
- Repeated temporary access gets reviewed for a better permanent role.
The exception is worth saying out loud. Time-bound access only works cleanly when the access can be removed through group membership or another reliable control point. If a tool requires manual work inside the app, automatic revocation may not be possible. That doesn’t kill the model. It tells you which apps need either manual review or a better integration path.
Run access reviews from the same evidence trail
Quarterly access reviews fail when reviewers get a spreadsheet with names and app names but no useful context. They rubber-stamp because they don’t know what changed, when the user last logged in, or why the person has the role. I don’t blame them. That’s not a review. That’s a guessing exercise.
A better access review starts from the same record system used for requests. Reviewers should see the user, department, job title, group membership, last login, and a recommendation if the user looks inactive. Then the keep or revoke decision should trigger the removal work, not create another follow-up task for IT.
The review process should answer five questions:
- Is the user still employed and in the same role?
- Has the user logged into the app recently?
- Does the role match the current job?
- Was access originally approved for a time-bound need?
- Can revocation be enforced immediately through the identity provider?
When reviews live apart from requests, you end up reconciling history. When reviews live with the request trail, you’re checking reality. Big difference.
How Multiplier Keeps Jira Audit-Ready
Multiplier keeps Jira audit-ready by tying requests, approvals, provisioning, reviews, and revocations back to Jira issues. Employees request access through a JSM app catalog or Slack, approvers decide in Jira or Slack, and approved changes run through Okta, Entra ID, or Google Workspace groups.
Jira becomes the access record, not just the ticket queue
Multiplier is built around a pretty practical idea: if the work starts in Jira, the evidence should stay in Jira. The Application Catalog gives employees a structured place to request approved apps and roles. Approval Workflows route decisions to managers, app owners, or specific users through Jira and Slack. Automated Provisioning then adds or removes users from mapped identity provider groups when the Jira issue reaches the right status.
That solves the annoying middle layer. No separate portal for employees to learn. No Slack approval that gets lost. No IT admin manually adding groups and then pasting screenshots. For time-sensitive access, Time-Based Access lets requesters choose durations like 1, 6, or 24 hours, then removes group membership when the window expires. That’s the part most manual workflows never get right.
Reviews and license cleanup use the same operating model
Access Reviews in the platform replace spreadsheet campaigns with Jira-native review work. Reviewers can see user attributes, groups, last login, and recommendations, then choose keep or revoke. When revocation is selected for supported identity provider group access, the removal can be executed and documented through Jira tickets. For audit teams, the useful part is boring in a good way: the record shows the decision and the change.
Auto Reclaim uses login telemetry from the identity provider to flag inactive users, warn them, and revoke access after the grace period if they stay inactive. That’s especially useful for SaaS waste, because unused licenses often sit around until finance complains. The same motion applies: policy, notification, revocation, Jira evidence. If you’re ready to turn access requests into an auditable Jira workflow, Get started with Multiplier.
Access Requests Get Easier When Evidence Stays Put
Managing IT access requests gets easier when the workflow creates evidence while the work happens. Not later. Not during audit week. The request, approval, provisioning action, expiry, and review decision all need to stay connected, because that’s what turns access from a queue into a control.
The old way made sense when companies were smaller. A few tickets, a few approvals, a few group changes. Then headcount grows, apps multiply, audits get stricter, and suddenly the spreadsheet is running the security program. Not ideal.
The better path is boring, focused, and repeatable. Put intake in Jira and Slack. Route approvals by risk. Provision through identity provider groups. Make sensitive access temporary. Run reviews from the same evidence trail. That’s how IT stays lean without losing control.
Frequently Asked Questions
How do I handle access requests for new hires?
To handle access requests for new hires, you can use Multiplier's Application Catalog within Jira Service Management. 1) Set up the catalog with approved applications that new hires typically need. 2) Allow employees to request access through the JSM portal or Slack, where they can easily select the app and role they need. 3) Automate the approval workflow to reduce delays and make sure requests route to the right approvers. This way, new hires can get the access they need quickly and efficiently, minimizing the administrative burden on your IT team.
What if I need to revoke access for multiple users?
If you need to revoke access for multiple users, you can use Multiplier's Access Review feature. 1) Create an access review campaign in Jira, selecting the relevant applications and reviewers. 2) Reviewers will see user details, including their access levels and last login dates, making it easier to decide who to revoke access from. 3) Once decisions are made, Multiplier will automatically remove users from the relevant identity provider groups and document the changes in Jira. This helps maintain a clean and compliant access management process.
How do I ensure access requests are audit-ready?
To keep access requests audit-ready, you should: 1) Use Multiplier to tie every access request, approval, and provisioning action back to a Jira issue. This creates a complete record of all actions taken. 2) Make sure that all approvals and changes are documented within the same system, eliminating the need for separate spreadsheets. 3) Regularly conduct access reviews to verify that access is still appropriate and that any expired access is revoked. This way, you maintain a clear audit trail that satisfies compliance requirements.
When should I implement time-based access for sensitive roles?
You should implement time-based access for sensitive roles whenever elevated access is granted. 1) Set up Multiplier to require requesters to specify a duration for access during the request process. 2) After approval, access gets provisioned automatically and set to expire after the specified duration. 3) This approach minimizes the risk of long-term standing access and helps maintain security by ensuring that access is only available when truly needed.
