At 4:47 p.m. on the Friday before an audit, somebody asks who still has access to your finance apps. You have 90 days of login data in Okta, a Jira queue full of old tickets, and a spreadsheet nobody fully trusts.
That's where a compliance-driven inactivity review usually breaks. Not at the review meeting. It breaks when activity data, access decisions, identity changes, and evidence live in different systems.
A user hasn't logged in for 60 days. Fine. But did their manager approve keeping access? Was the account removed? Did the identity provider accept the change? Can you prove all of that without rebuilding the story by hand? Those are the questions that matter.
Key Takeaways:
- Treat inactivity as a review signal, not automatic proof that access is unnecessary.
- Set different inactivity thresholds based on application risk and usage patterns.
- Keep the decision, revocation, and evidence connected to one Jira issue.
- Execute access changes through your identity provider, not through manual app updates.
- Build exceptions into the process so leave, seasonal work, and service accounts don't create bad revocations.
- Test whether reviewers can prove completion without opening a spreadsheet.
Why Inactivity Reviews Break During Audit Preparation
Inactivity reviews break when the evidence is separated from the action. Login data may come from the identity provider, reviewer decisions may sit in a spreadsheet, and revocations may happen inside individual applications. Each part can work on its own. The problem appears when someone needs to prove the full chain.
A 90-Day Login Gap Doesn't Prove Access Is Wrong
A 90-day login gap tells you an account looks inactive. It doesn't tell you whether the user still needs access, whether the application is used seasonally, or whether the identity provider has accurate telemetry. That distinction matters. Compliance-driven inactivity reviews need a human decision backed by useful context.
I've seen teams treat the inactivity threshold as the decision itself. User inactive for 90 days, access revoked. Sounds efficient. Then someone removes a finance lead from an application used only during quarterly close, or disables a contractor who's returning next week. Now you're apologizing on Monday and re-provisioning by hand. The threshold should start the review, not finish it.
The evidence you need is broader:
- Last recorded login
- Current role and department
- Application and access level
- Manager or application owner
- Reason to keep or revoke access
- Confirmation that the identity change succeeded
Split Workflows Turn Evidence Collection Into Reconstruction
An IT manager opens a spreadsheet at 8:30 on the Monday before an audit and finds "revoke" beside 17 users. No ticket number, no date, no record showing whether those removals actually happened. They check Slack for approvals, then Okta for group membership. Two hours later, they're still matching names to accounts, and the audit is three days out.
Spreadsheet-based reviews can work for ten applications and one reviewer. That's a fair reason teams start there. The weakness shows up when the review has several owners, hundreds of users, and real identity changes to track. Picture reconciling a bank statement against receipts stored in four different drawers, half of them missing dates, some in a coworker's handwriting. Every gap creates another question you have to chase, and each question adds an hour to a week you don't have.
A Jira-native record changes the evidence model. The request, review decision, access change, and status can stay attached to the same issue. If that workflow matches how your team already works, learn more about Multiplier to see how access governance can live inside JSM instead of another portal.
A Review Isn't Complete Until the Access Changes
A completed review with unfinished revocations is still an open control. The reviewer may have made the right call. Security still has the wrong access state until somebody removes the user from the correct identity provider group.
Manual follow-up is where good intentions tend to die. The review closes on Friday, the revocation list gets sent to IT, and Monday brings onboarding tickets plus a production incident. By Wednesday, several removals are done and several aren't. Nobody's being careless. The workflow simply separates judgment from execution, and the gap between them is where access stays live longer than it should.
One fast-growing AI company processed more than 3,800 access requests in a year while supporting over 420 employees with a four-person IT team. About 75% of those requests were fully automated. The interesting part isn't only the saved time. When execution runs through the same system as the decision, the approved state and the actual identity state become much harder to separate.
The better question isn't, "Did we finish the spreadsheet?" It's, "Can we prove every decision became an authoritative identity change?"
How to Build Compliance-Driven Inactivity Reviews in Jira
A reliable inactivity review connects five things: trustworthy login data, an application-specific threshold, useful reviewer context, an enforced identity change, and evidence in Jira. Build those pieces in that order. If one is missing, the review may look complete while access stays exactly where it was.
Can You Trust the Login Data?
Can you trace the last-login value back to the identity provider and explain what it represents? Start there. Some applications send useful login telemetry through Okta, Entra ID, or Google Workspace. Others have stale records, shared accounts, or no usable activity data at all.
An incomplete signal isn't useless. It just needs a boundary. If an application doesn't provide reliable activity data, don't label the account inactive based on a blank field. Route that application through a manual certification path and record why. Honestly, this is less elegant, but it beats pretending missing data means no usage.
Before putting an application into an automated inactivity workflow, verify:
- The identity provider receives a usable last-login value.
- The value belongs to the person being reviewed.
- Shared and service accounts can be identified.
- The application's normal usage pattern is understood.
- Revocation can be enforced through a mapped identity provider group.
Set Thresholds Based on Application Behavior
Thirty days may be right for a collaboration tool people open every morning and completely wrong for tax, planning, or quarterly reporting software. A single company-wide threshold is easy to explain. It's also likely to generate false positives across a mixed SaaS stack.
I'd start with three bands, then adjust from actual usage. High-frequency applications might use 30 days. Periodic applications might use 60 or 90 days. Seasonal applications should get a manual review tied to their business calendar, not an automatic clock. Here's a rule I'd hold to: if an app's real usage cycle is longer than your threshold, you're not measuring inactivity, you're measuring the calendar. A quarterly-close app on a 30-day clock will flag the same finance lead four times a year for doing nothing wrong.
Build the first threshold table like this:
- List normal usage frequency: Daily, weekly, monthly, quarterly, or seasonal.
- Add application risk: Low-risk productivity access shouldn't be treated like an admin role.
- Choose an inactivity trigger: Set the point where review begins, not automatic guilt.
- Set a grace period: Give the user time to confirm usage before revocation.
- Name exclusions: Document service accounts, approved leave, and other valid exceptions.
A global threshold is still reasonable for a small stack with similar applications. I get the logic. Once the stack grows past a couple dozen apps, though, application behavior matters more than administrative simplicity.
Separate License Waste From Access Risk
An unused license costs money. An unnecessary privileged role creates security exposure. Both may begin with the same inactivity signal, but they shouldn't follow the same decision path.
For a basic design tool license, the reviewer may only need last login, department, and a short grace period. Production administration is different. Reviewers should see the role, the access level, the user's job, and any valid reason for keeping elevated rights. Same signal. Different stakes.
The split also changes who approves the action. Finance or IT may own routine license reclamation, while an application owner or security reviewer handles privileged access. Mix those decisions into one generic queue and you get rubber-stamping. People stop asking what access means because every row looks identical, and a privileged admin role slides through with the same click as a spare Figma seat.
A useful rule is simple: if revocation could interrupt a core business process, require an owner decision. If access is low-risk and unused past a defined threshold, a notification plus grace period may be enough.
Put the Reason Beside the Decision
A reviewer opens the campaign and sees five inactive users. Three left the department, one is on parental leave, and one uses the application during quarterly close. A binary Keep or Revoke choice, with no context attached, forces the reviewer to go investigate each person somewhere else.
The Jira issue should carry enough information to make the decision without a Slack hunt. Include identity attributes, current groups, last login, the application owner, and the proposed action. Then require a reason for exceptions or revocations. That reason matters six months later, when a different auditor asks why access remained.
I prefer evidence captured during the work, not added after. Rebuilding evidence later creates transcription mistakes and missing dates. It also turns an ordinary review into an IT fire drill the week before the audit. If the reviewer decision is recorded beside the identity action, audit prep becomes checking the record rather than recreating it.
The minimum evidence chain should show:
- Who was reviewed
- What application and role were in scope
- Which activity signal triggered the review
- Who made the decision
- Why access was kept or revoked
- When the identity change occurred
- Whether the change succeeded
Make the Identity Provider the Enforcement Point
Revoking access in a spreadsheet changes nothing. Removing the user from an authoritative identity provider group changes the actual entitlement and creates a repeatable path for future reviews.
Group-based access is the cleanest option when the application uses SSO and mapped groups. The reviewer chooses Revoke, the workflow removes the membership, and the Jira record receives the outcome. If the identity provider returns an error, the review stays open for follow-up. Failed execution shouldn't look like completed governance.
Some applications can't support that model. Non-SSO tools may still need a manual administrator to remove access inside the application. Fair enough. Keep those applications in the same review process, but make the manual status visible and require confirmation before closure.
For teams trying to connect reviewer decisions to authoritative group changes, see how Multiplier works across Jira, Slack, and the identity provider.
Test the Exceptions Before Launching the Review
What happens when an employee is on leave, an account belongs to a service, or the login feed is stale? If the answer is "the reviewer will figure it out," the process isn't ready.
Run a small test with real edge cases before launching the full campaign. Pick one ordinary user, one privileged user, one person on leave, one service account, and one application without reliable telemetry. Walk every record from detection to Jira decision to identity change. It's not glamorous. It catches the failures a clean sample hides.
Exceptions need owners and expiry dates. A person on approved leave may keep access until a set return date. A service account may be excluded while its owner and purpose are recorded. An application with missing telemetry may stay on manual review until the data source improves.
Use three questions during the test:
- Can the reviewer decide without opening another system?
- Can IT prove whether the revocation succeeded?
- Can someone understand the exception six months later?
If any answer is no, fix the workflow before you scale it. The process should produce evidence while people do the work, not ask them to document everything again the night before an audit.
How Multiplier Connects Jira Reviews to Identity Changes
Multiplier keeps the inactivity review, reviewer action, identity change, and audit record inside the Jira workflow. It uses login data from connected identity providers, supports policy-based reclamation, and can execute revocations through mapped groups. The operating model taught above becomes part of normal JSM work instead of a separate compliance project.
Auto Reclaim Handles Policy-Based Inactivity
Multiplier's Auto Reclaim feature monitors last-login data for in-scope applications connected to the identity provider. Admins define an inactivity threshold, a grace period, and group exclusions. When a user crosses the threshold, they receive a warning. If they remain inactive after the grace period, access is revoked and a Jira ticket records the action.
That mechanism fits lower-risk, policy-based reclamation where the decision can be made from a known threshold and reliable telemetry. It also keeps the warning and revocation connected to Jira. Auto Reclaim is available on the Advanced edition, and its accuracy depends on the login data provided by the identity provider. Applications without useful telemetry can't be treated the same way.
Access Reviews Add Human Decisions and Enforced Revocation
Multiplier runs access review campaigns inside JSM for applications marked Approved. Reviewers see user attributes, group memberships, and last-login context, then choose Keep or Revoke. A Revoke decision removes the relevant identity provider group membership and creates Jira evidence for the change.
Multiplier also supports application catalogs and approval workflows in Jira and Slack, which means the original grant can follow the same evidence path as the later review. That connection matters. You can trace access from request, to approval, to provisioning, to review, to revocation without stitching together separate portals.
Automatic removal requires access to be controlled through identity provider groups. Purely manual or non-SSO grants still need manual action. That's a real limitation, and it's worth planning around rather than hiding it.
If you want the review decision and identity change tied to the same Jira record, get started with Multiplier and map one in-scope application first.
Keep Inactivity Reviews Ready for the Next Audit
Compliance-driven inactivity reviews work when activity signals lead to decisions, decisions lead to identity changes, and every step leaves evidence in Jira. A spreadsheet can list inactive users. It can't guarantee that access was removed or prove the identity provider accepted the change.
Start with one application that has reliable login data and group-based provisioning. Set a sensible threshold, test the exceptions, and follow five users through the complete flow. If you can prove each decision without rebuilding the story by hand, you've got a process that can grow.
Frequently asked questions
- How do I set up inactivity thresholds for different applications?
To set up inactivity thresholds, start by analyzing the usage patterns of each application. 1) Identify how often users typically log in (daily, weekly, monthly). 2) Set different thresholds based on this frequency—30 days for high-frequency apps, 60 or 90 days for periodic ones. 3) Document any exceptions for seasonal applications or users on leave. Using Multiplier, you can automate this process by defining inactivity policies that align with your organization's needs.
- What if I need to revoke access for a user but they're on leave?
If a user is on leave, document their status and set a return date for access review. 1) Create an exception in your inactivity review process to keep their access until they return. 2) Use Multiplier to track this exception so it's visible in your Jira records. 3) When they return, confirm their access needs before proceeding with any revocation. This way, you maintain compliance while respecting their leave.
- Can I automate access requests for non-SSO applications?
Yes, using Multiplier's Application Catalog feature. 1) Add the non-SSO app to the catalog manually, capturing necessary approvals. 2) Employees can request access through the JSM portal or Slack. 3) While provisioning stays manual, Multiplier still logs the request and approval process, giving you an audit trail. This helps streamline access management even for non-SSO tools.
- When should I run access review campaigns?
Schedule access review campaigns regularly—quarterly or bi-annually, depending on your organization's needs. 1) Start by selecting applications marked as 'Approved' for review. 2) Assign reviewers who know the users and their access needs. 3) Use Multiplier to run the campaign, which streamlines evidence collection and keeps all decisions in Jira for audit purposes.
- Why does my inactivity review process need to connect to an identity provider?
Connecting to an identity provider is what makes access changes stick. 1) It ensures any changes are enforced directly through the identity provider, keeping access state consistent. 2) Multiplier automates this connection, revoking access and logging changes in Jira. 3) This integration prevents gaps in access control and keeps you compliant.
