Create an Access Review That Actually Works

92% of access reviews fail at the boring part, not the policy part. Teams know they should create an access review. What they don't have is an operating system for doing it without spreadsheets, ticket hopping, and license waste.

Most companies think the hard part is deciding who should keep access. I'd argue the hard part is making revocation actually happen after the decision, and making the evidence show up without someone rebuilding it by hand later.

Key Takeaways:

• To create an access review that actually reduces risk, start with applications that are approved, high-cost, or high-privilege
• The fastest review model is not "review everything" but the 30-60-90 Rule: 30 high-risk apps, 60-day inactive users, 90-day campaign windows
• If reviewers don't get login context, department, and group membership in one place, your review will turn into rubber-stamping
• A good access review should end in enforced revocation, not a CSV someone promises to clean up later
• License optimization and access reviews should be connected, because inactive access is often both a security problem and a spend problem
• Time-bound access cuts the number of ugly review decisions later, because fewer people end up with standing privilege in the first place

Why Most Teams Struggle to Create an Access Review That Matters

Creating an access review means setting up a repeatable process to check who has access to which apps, deciding whether they should keep it, and removing access that no longer makes sense. The problem is that most teams treat this like a documentation task when it's really an operating workflow. That's why the review looks complete on paper and still fails in practice.

The real bottleneck isn't policy

Most teams already know the policy. Review privileged access. Check inactive users. Get app owners involved. None of that is new. The issue is operational drag.

A workplace tech lead opens Jira for requests, Slack for approvals, Okta for group membership, a spreadsheet for the campaign, and then email because one reviewer never saw the notification. That's the day. Then an auditor asks for proof of who approved what, and now someone is stitching screenshots together like they're making a scrapbook for compliance. Sound familiar?

The old assumption is that a separate IGA portal gives you stronger governance. Fair point, on the surface. Dedicated tools can go deep. But if your actual work still starts in Jira, moves through Slack, and ends in your identity provider, splitting governance away from that flow creates delay by design. That's the hidden cost most teams ignore.

Manual reviews create two kinds of waste

The first waste is security waste. People keep access too long because nobody gets around to revoking it. The second is license waste. You keep paying for seats that nobody is using.

This is where a lot of teams miss the connection. An access review isn't only about least privilege. It's also one of the cleanest ways to find unused SaaS spend. If a user hasn't logged into an app in 60 or 90 days, that's not just a governance question. It's a budget question. Security and procurement are staring at the same problem from different sides.

A good mental model here is the Twin Waste Test. Ask two questions for every app in scope: if this access stays, does it increase risk? And if this access stays, does it increase cost? If the answer is yes to either one, it belongs in the review. If it's yes to both, it moves to the front of the line.

What this looks like in real life

At a high-growth SaaS company, a four-person IT team was supporting more than 400 employees while access requests were getting tracked in Slack channels and Notion boards. Notifications got missed. Provisioning was manual. Reviews became the kind of thing everybody agreed was important and nobody wanted to own. Once they standardized requests and automated the approval and provisioning flow, 75% of access requests became fully automated. That changed the review workload because the system got cleaner upstream.

I've seen this pattern a lot. Teams don't fail to create an access review because they're careless. They fail because the workflow is broken before the campaign even starts. So the better question isn't "who should review?" It's "what operating model makes review decisions real?"

If you want to see what Jira-native governance looks like in practice, Learn more about Multiplier.

How to Create an Access Review Without Turning It Into Spreadsheet Theater

To create an access review that people actually finish, you need clear scope, the right reviewer, decision context, and automatic follow-through on revocations. The framework I like is Scope, Reviewer, Context, Enforcement. I call it the SRCE model. If one of those four is weak, the whole campaign bogs down.

Start with the 30-60-90 Review Rule

30-60-90 is a practical threshold for building your first serious review. Review your top 30 risky or expensive apps. Flag users inactive for 60+ days. Run the campaign on a 90-day cadence if you're still building muscle.

Why these numbers? Because "review everything" usually means "finish nothing." A focused campaign gets done. And done matters more than ambitious.

If you're figuring out how to create an access review campaign for the first time, start with apps that hit one of these buckets:

1. Admin or elevated access
2. Finance, engineering, HR, or production systems
3. Expensive licenses with visible waste
4. Apps with frequent role changes
5. Apps that routinely create audit questions

There's a case to be made for reviewing every sanctioned app in one shot. In a mature enterprise, sure. But for most mid-market teams, that just creates backlog. The better move is to prove the workflow on a smaller scope, then expand.

Pick the reviewer based on decision quality, not org chart neatness

The best reviewer is the person who can make a clean keep-or-revoke call in under two minutes. That's the rule. If the reviewer needs three Slack threads and a spreadsheet to decide, you've picked the wrong person.

Sometimes that's the app owner. Sometimes it's the manager. Sometimes it's a specific person who understands the risk better than either. The mistake is assigning reviews based on who "should" own them politically instead of who can actually decide accurately.

When you create an access review, use a Reviewer Fit Rule:

1. If access is role-based and routine, send it to the manager
2. If access is specialized or expensive, send it to the app owner
3. If access is sensitive and cross-functional, assign a named reviewer directly

That sounds simple. It is simple. But simple is what scales.

Give reviewers enough context to avoid rubber-stamping

Rubber-stamping happens when the reviewer has no context and too many rows. They click keep because the cost of investigating is too high.

So before you launch a review, make sure the reviewer can see:

• user name and department
• current groups or roles
• job title
• last login
• a recommendation trigger, like inactive 90+ days

This matters more than most teams think. A reviewer looking at "John, Figma, Editor" has almost nothing to go on. A reviewer looking at "John, Product Design, last login 143 days ago, in Editor + Admin group" can actually decide.

Honestly, this is where most access review projects quietly die. Not in setup. In decision fatigue.

Build the campaign in a way people will actually finish

A draft campaign should be easy to inspect before it goes live. Name it clearly. Choose the apps in scope. Set dates. Check for missing reviewers. Fix gaps before you notify anyone.

The basic flow to create an access review campaign looks like this:

1. Open your access review workspace
2. Create a new review with a clear name
3. Select in-scope approved apps
4. Set start and end dates
5. Assign the default reviewer
6. Review the draft for missing users or missing reviewers
7. Start the campaign only when the scope is clean

That sequence sounds obvious. But skipping step 6 is where bad campaigns are born. If you launch with missing reviewers or weird app data, people lose trust fast. And once that happens, every future review gets more painful.

Enforcement is the part that separates a review from a report

A real access review ends with a change in the source of truth. A fake one ends with a spreadsheet export and a promise.

This is my strongest opinion on the whole topic. If a reviewer clicks revoke and nobody is removed from the right group, you did not complete an access review. You created a suggestion list.

That may sound harsh. But it's true. The Enforcement Threshold is simple: if revoked access isn't removed within one workflow cycle, your review process is incomplete. One workflow cycle might be immediate automation or a same-day ticket-driven change. Anything longer starts creating drift.

A fintech company dealing with long-lived privileged access used time-limited controls and automated expiry to reduce privileged access by 85%, with more than 1,300 access requests automatically revoked after approved windows. That's not just cleaner security. That's cleaner review math. Fewer standing privileges means fewer ugly exceptions the next quarter.

Reviews get easier when your access model is cleaner before the campaign starts. That's the pivot.

If you're mapping this into your own process, See how Multiplier works.

The Better Operating Model: Fewer Standing Privileges, Smarter Reviews, Lower SaaS Waste

The best way to create an access review is to make the review smaller before it even begins. That sounds backwards, but it's the whole game. If access is time-bound by default, if provisioning is tied to your identity provider, and if inactive licenses get reclaimed automatically, your quarterly review stops being a cleanup project and starts being a control check.

Use time-bound access to reduce future review volume

Time-bound access means elevated access expires unless there's a reason to renew it. That one design choice changes everything.

Without it, every quarter you review a pile of standing access that accumulated through good intentions and bad follow-up. With it, a lot of that access self-cleans. The review becomes narrower, faster, and more accurate.

Think of standing privilege like plaque on your teeth. Not glamorous, but true. You can wait six months and deal with a bigger mess, or you can reduce buildup daily and make the cleaning easy. Time-limited access does the daily work.

If the app is sensitive or the role is privileged, make duration mandatory. If the access is broad and low-risk, you may keep it persistent. That's a fair exception. Not every role needs a one-hour timer. But admin rights, production access, finance controls, and data-sensitive tools usually do.

Connect access reviews to usage-based license decisions

Most teams separate access governance from software spend. I think that's a mistake.

If somebody hasn't used a licensed app in 30, 60, or 90 days, you have two valid questions:

1. Should this person still have access?
2. Should we still be paying for this seat?

That's why I like linking access reviews to actual login activity. Login telemetry gives you a far better signal than gut feel. It also changes the conversation with finance. Instead of saying "we should probably tighten access," you can say "we found 47 inactive seats in tools we review every quarter." Much better conversation.

The practical rule is this: if a license is expensive and inactivity crosses your threshold, route it into either automatic reclaim or the next review cycle. Don't let it sit in limbo. Limbo is where both risk and waste go to hide.

Keep governance where the work already happens

This is the contrarian point that really matters. The ITSM and IGA split is usually the real bottleneck.

Requests already happen in Jira. Approvals often happen in Slack. Provisioning runs through the identity provider. Audit evidence eventually gets asked for in Jira or in a compliance workflow. So why force access reviews into a separate portal and then reconcile everything back by hand later?

Some teams like the idea of a separate governance suite because it feels more official. I get it. Big control surface. Big policy language. But if it slows down the actual operators, the policy looks stronger than the practice. And practice is what auditors, employees, and budgets feel every day.

When governance lives in the same operational path, the byproduct is clean evidence. Not perfect evidence. Clean enough evidence, generated as work happens. That difference matters a lot.

A maturity model you can actually use

If you're trying to create an access review process from scratch, don't jump straight to full-scale certification across everything. Use this four-stage maturity model instead:

1. Stage 1: Visibility. Centralize requests and identify approved apps
2. Stage 2: Decisioning. Assign the right reviewers and give them real context
3. Stage 3: Enforcement. Execute revocations through the identity provider or tied workflow
4. Stage 4: Optimization. Use login activity to reclaim unused licenses automatically

Most teams want Stage 4 first because the savings story is easy to sell. Fair enough. But if Stage 2 is broken, the whole thing gets shaky. Decision quality comes before optimization.

The good news is you don't need a giant implementation to get better. You need one clean workflow that people will trust.

How Multiplier Puts Access Reviews, Revocations, and License Reclaim in One Workflow

Multiplier is built for teams that want to create an access review inside Jira Service Management, keep approvals moving in Slack, and execute changes through the identity provider. In plain English, the governance work lives where the team already works, and the evidence lands on the Jira issue instead of getting rebuilt later.

Reviews that end in actual revocation

Multiplier's Access Reviews let admins create campaigns in JSM, choose approved applications in scope, assign reviewers, and launch the review from a Jira-native workflow. Reviewers see user attributes, groups, last login, and recommendations in the review experience, which is exactly the context that cuts rubber-stamping. When a reviewer marks access for revocation, Multiplier can remove users from the relevant identity provider groups and document the change in Jira.

That's a big shift. You're not exporting a file and hoping someone cleans it up next week. You're tying the decision to the action. And for audit purposes, that closes the loop.

Less standing privilege and less wasted spend

Multiplier also attacks the problem before the review starts. Time-Based Access makes elevated access temporary by default, with a duration like 1, 6, or 24 hours and automatic removal at expiry when access is provisioned through identity provider group membership. So the pile of standing privilege shrinks over time instead of growing quarter after quarter.

Then there's Auto Reclaim. Multiplier continuously ingests last-login data from the identity provider for in-scope apps, lets admins define inactivity thresholds and grace periods, warns inactive users by email, and revokes access automatically if they still don't log in. That means you can connect access governance to SaaS cost control with real usage data, not guesswork. Worth noting, Auto Reclaim is available on the Advanced edition.

The workflow stays inside Jira and Slack

Multiplier rounds this out with Approval Workflows, the Application Catalog, Automated Provisioning via identity provider groups, and the Slack App. Employees can request sanctioned app access through JSM or Slack. Approvers can act in Slack or Jira. Once approved, provisioning happens through mapped identity provider groups, and the ticket records what changed. Multiplier isn't provisioning directly inside every SaaS app on its own. It provisions through the identity provider groups you map, which is exactly the kind of boundary that keeps the workflow authoritative.

If your team is trying to create an access review without adding another portal, this is the model. Reviews, approvals, provisioning, time-bound access, and license reclamation all connect back to the same operational record. Get started with Multiplier.

Create the Review Once, Then Make the System Do the Boring Part

If you want to create an access review that actually improves security and lowers cost, don't start with a giant compliance exercise. Start with one clear campaign, a tight scope, real reviewer context, and enforced revocation.

That's the real shift. You stop treating access review as a quarterly spreadsheet ritual and start treating it like an operating workflow. Once that happens, least privilege gets easier to enforce, SaaS waste gets easier to spot, and audits get a lot less dramatic.