Context-Driven Access Governance: Faster IT, Less Waste

At Synthesia, 200 new hires a year turned access requests into a daily chase through Slack and Notion. Every request needed context before IT could act: who approved it, which Okta group matched the role, whether the access should expire, and what evidence belonged in Jira. Strip that context out, and access governance becomes a guessing game where IT either slows everyone down or grants too much access just to keep work moving.

I've seen this pattern a bunch. The ticket says "Need Salesforce access." No role, no duration, no manager note, no reason. IT becomes the detective, security becomes the blocker, and finance keeps paying for licenses nobody has touched in 90 days.

Key Takeaways:

• Context turns access governance from ticket routing into decision quality.
• The missing context isn't just "who requested access." It's role, risk, duration, approval path, usage, and evidence.
• If an access request needs more than one follow-up question, your intake flow is broken.
• License waste usually starts as a context problem, because nobody knows whether access is still needed.
• Identity governance works better inside Jira and Slack because that's where the work and decisions already happen.
• Automated provisioning only works when app roles map cleanly to identity provider groups.
• Access reviews get faster when reviewers see usage context before they make keep or revoke decisions.

Why Context Breaks Access Governance First

Access governance breaks before any other identity workflow because every decision depends on facts that usually sit outside the ticket. The requester knows why they need the app. The manager knows whether it makes sense. The identity provider knows usage. Jira holds the work record. When those facts don't meet in one place, governance becomes manual archaeology.

The Ticket Is Usually Too Thin

Picture this: it's 4:47pm on a Friday, and an IT analyst opens a fresh ticket in Jira Service Management. "Need admin access to NetSuite for month-end." That's the entire ticket. No role specified, no end date, no approver tagged, no indication if this is one-off or a permanent change. The analyst now has to DM the requester, wait for a reply, DM their manager, wait again, then guess at the right Okta group. Twenty minutes of detective work for what should have been a 90-second decision.

Here's the diagnostic I'd use: if IT needs more than one follow-up question before granting access, the request form failed. Not the employee. Not the approver. The form. A good request captures the app, role, business reason, duration, and approver before IT touches it. Five fields. If any are missing, you're asking humans to compensate for a weak system, and humans compensate by either rubber-stamping or stalling.

Approval Context Gets Lost Between Tools

Four tools, one decision, zero shared memory. The manager approves in Slack. IT updates a Jira ticket. Someone adds the user to an Okta group. Six months later, an auditor asks why that access was granted. Fun times. Everyone is now searching across tools trying to reconstruct a decision that should've been a single record.

There's a fair case for separate IGA portals. They have deep controls, policy logic, real access review features. I get the logic. The catch is that high-growth teams already run intake and service work in Jira, and adding another portal usually creates a split-brain process. If your access request starts in Jira but governance lives somewhere else, you've turned a simple decision into an integration project. So what role does context play when it's scattered across four UIs? It plays the role of the thing everyone reconstructs from memory at audit time. If you want to see how a Jira-native model collapses the request-approval-provisioning handoff, Learn more about Multiplier.

License Waste Is a Context Problem Too

Finance sees license waste as a procurement problem. It usually isn't. Someone got a tool 8 months ago for a project. The project ended. The person changed teams. The license stayed active because nobody connected access to role, usage, and time. That's not procurement failing. That's governance without memory.

The threshold I like: 30 days of inactivity for high-cost SaaS apps, with exclusions for executives, contractors, or roles where login patterns are genuinely seasonal. If someone hasn't logged in for 30 days, don't revoke instantly. Send a warning, give a 7-day grace period, then reclaim. The honest limitation here is that last-login data isn't perfect for every app, especially ones with weak telemetry or SSO-only sessions. Fair. Still, an imperfect inactivity signal beats a finance spreadsheet built from app-owner memory every time. Context keeps the cleanup sane, and sanity is what lets you reclaim licenses without breaking workflows.

How Access Context Should Shape Every Decision

Access context should shape every decision by making risk, need, ownership, and usage visible before someone approves or revokes. The goal isn't to collect more fields for the sake of it. The goal is to give IT, security, and app owners enough signal to make the right call fast, the first time.

Start With a Request Quality Check

Ask yourself five questions before any request gets routed: Is the app named from an approved catalog? Is the role specified, not just "access"? Is there a business reason in plain language? Is there a duration, even if it's "permanent"? Is the approver pre-mapped, not guessed at? Score one point per yes. Anything under 4 out of 5 should bounce back to the requester automatically before IT ever sees it.

For every approved app, define the roles employees can request, then map each role to what it actually grants. Viewer access to Figma isn't the same decision as admin access to GitHub. Obvious, I know. Yet a lot of request flows treat them like the same ticket type. That's how overprovisioning sneaks in. One form, too many meanings.

The before-and-after is stark. Before: "Need access to Tableau." After: "Need Tableau Viewer for Q3 pipeline reporting, approved by manager, 30-day duration." One creates a Slack thread. The other clears review in under a minute.

Separate Routine Access From Risky Access

Not every request deserves the same approval path. Treating every app like it's production infrastructure is how IT becomes the bottleneck. Auto-approving everything because people are annoyed is how least privilege quietly dies. Both extremes are lazy in different ways.

Use this routing rule: if the app is low-risk and the role is standard, send it to the requester's manager or app owner. If the role is privileged, financial, customer-data adjacent, or production-touching, require explicit security approval plus time-bound access. If the requester needs access for under 24 hours, default to temporary. If they need it permanently, force a business reason that survives an access review six months from now.

The better move is context-based friction. Add friction where risk is high. Remove it where the request is obvious. Same workflow engine, different lanes.

Use Duration as a First-Class Signal

Duration is the most ignored field in access governance, which is strange because it tells you almost everything. Someone who needs access for 1 hour during a Sev1 incident is a completely different risk profile than someone asking for permanent admin rights. Same app. Same person. Different context.

If the access is elevated, sensitive, or temporary by nature, never grant it without an expiry. Give employees common durations: 1 hour, 6 hours, 24 hours, 7 days. Anything longer should require a stronger justification. Not because employees are untrustworthy, but because humans are genuinely bad at remembering cleanup work after the urgent task is done.

At Stavvy, privileged access was cut by 85% by moving toward a just-in-time model. The point wasn't to make engineers beg. The point was to make privileged access available the moment it was needed, then remove it when the job was done. That's a very different emotional experience. Less waiting. Less standing access. Fewer awkward audit questions later.

Tie Provisioning to Identity Provider Groups

Provisioning gets reliable when access decisions map cleanly to identity provider groups. That's the operational layer most teams skip. The Jira ticket can say approved, but if someone still has to manually copy the request into Okta, Entra, or Google Workspace, you haven't automated the real work. You've just made the front end prettier.

Before automating anything, run a mapping audit. Pick your 20 most-requested apps. List every role people ask for. Then match each role to the identity provider group that grants it. If a role can't be mapped cleanly, don't automate it yet. Fix the group structure first. Otherwise you'll automate confusion, and that's worse than manual work because mistakes happen faster.

This is where access governance starts looking like good operations. Catalog shows approved apps. Role maps to a group. Approval changes ticket status. The identity provider becomes the system that actually grants access. So what role does context play after approval? It becomes the instruction set automation uses without guessing.

Make Usage Data Part of Reviews

Access reviews fail when reviewers only see names and app lists. A manager sees 40 users with access to a tool and clicks keep on all of them because they don't have time to investigate each person. I get it. Nobody wakes up excited to review spreadsheet rows, especially when the spreadsheet doesn't say whether someone actually used the app recently.

A better review includes last login, department, job title, group membership, requester history, and a system recommendation. If someone hasn't logged in for 90 days, that should be visible at a glance. If someone changed departments 3 months ago, that should be visible too. Reviewers still make the final call. They just shouldn't have to hunt for the facts.

The decision rule is straightforward:

1. Revoke access for inactive users over your threshold unless there's a documented exception.
2. Keep access when usage matches the person's current role.
3. Escalate when usage is active but the role looks too privileged.
4. Time-bound access when the need is real but temporary.

That last bucket is where waste quietly disappears. You don't always need a hard keep or revoke. Sometimes you need "keep for 7 more days, then remove." Context gives you that third option.

Treat Audit Evidence as a Byproduct

Audit evidence shouldn't be rebuilt after the fact. That's where teams lose hours. Approval happened in Slack, provisioning happened in the identity provider, the review decision sits in a spreadsheet. Then audit season arrives and everyone starts taking screenshots like it's 2014.

Attach evidence to the work record as the work happens. Request submitted. Approver assigned. Approval granted. Group updated. Access expired. License reclaimed. Review completed. Every event connects back to the originating ticket. Not because auditors love Jira, but because a single record collapses the story gap.

Synthesia is a good example of the operational payoff. They grew from 100 to over 400 employees, processed 3,800+ access requests in a year, and automated 75% of them with a 4-person IT Ops team. That's not just faster ticket handling. That's context being captured once, then reused across approval, provisioning, and evidence.

Where Context Turns Into Cost Savings

Context turns into cost savings when access data is used to reclaim licenses, remove standing privilege, and reduce manual IT work. The savings don't come from one big cleanup project. They come from small decisions happening every day, based on usage, role, duration, and ownership.

Reclaim Licenses Before Renewal Panic

SaaS waste usually becomes visible right before renewal. Finance asks why spend is up. IT pulls reports. App owners guess who still needs what. Then everyone rushes through a cleanup project that should've been running all year. I've been in those rooms. Nobody is having a great time.

Make the threshold policy-based, not panic-based. For expensive apps, set inactivity rules around 30, 60, or 90 days depending on how often the app should be used. A daily work tool can use a shorter threshold. A quarterly reporting tool needs a longer one. If the user crosses the threshold, warn them before removing access. That avoids the classic mistake where you save one license and create 3 support tickets.

Luno's story shows the scale of the manual problem. They grew to nearly 1,200 employees with hundreds of access requests coming through Slack, email, and Jira. IT was chasing approvals and manually assigning Okta groups, with routine requests taking 5 to 30 minutes each. After moving to automated access workflows, they cut IT workload on access requests by 80%. That's real capacity back.

Don't Confuse Access Removal With Cost Control

Revoking access isn't automatically cost control. You can revoke the wrong access and tank someone's productivity for a week. You can also keep the wrong access and waste budget for months. Context decides which side you're on.

A good reclamation process has 4 checks before removal:

1. Has the user logged in within the inactivity threshold?
2. Is the user in an excluded group?
3. Is the app tied to a role where usage may be seasonal?
4. Has the user been warned with time to respond?

That fourth one matters most. A warning creates a clean path for exceptions. If the person needs the app, they log in or respond. If they don't, the license gets reclaimed. Not perfect, because last-login data isn't reliable for every app. Much better than asking app owners to guess from memory.

Use Context to Decide What Should Be Automated

Automation should start where context is clear. If the app has defined roles, mapped identity provider groups, low approval complexity, and regular request volume, automate it. If the request type is rare, high-risk, or poorly mapped, keep it manual until the context improves. That's the line.

Start with your top 10 request types by volume. For each one, ask:

1. Can the requester choose from approved roles?
2. Does each role map to an identity provider group?
3. Is the approver predictable?
4. Can access be revoked automatically?
5. Is the audit record created without screenshots?

Four yes answers, automate it. Fewer than three, fix the workflow first. Teams often do the opposite. They buy automation, point it at messy processes, then wonder why the output is messy. The tool didn't fail. The context was never ready.

How Multiplier Automates Access Decisions in Jira

Multiplier connects request context, approvals, identity provider group changes, and audit evidence into one workflow inside Jira. Employees request access in Jira Service Management or Slack, approvers decide where they already work, and approved changes execute through Okta, Entra ID, or Google Workspace group mappings.

App Catalog and Group-Based Provisioning

The core move is turning vague requests into structured choices. The Application Catalog shows approved apps, roles, and request paths inside Jira Service Management, with the same request flow available through Slack. Employees pick the app and role, and the request creates a Jira issue with the right context attached. Not a random Slack message. Not a free-form ticket. A governed request.

Once approved, Automated Provisioning uses mapped identity provider groups to add or remove access. The identity provider stays authoritative. For SSO apps, group membership drives the entitlement downstream, and the Jira ticket records the result. It's not magic. It's just the right sequence: request, approve, group change, evidence. The exact sequence most teams try to run manually across four tools.

Auto Reclaim and Time-Bound Access

The cost-savings angle comes from two places: temporary access and inactive license cleanup. Time-Based Access lets requesters choose a duration, such as 1, 6, or 24 hours, then removes access when the window expires through identity provider group membership. Auto Reclaim uses last-login data from connected identity providers, applies inactivity thresholds and grace periods, warns users, then revokes access if they stay inactive.

That's the part finance and IT both care about. Fewer stale licenses. Less manual cleanup. Better evidence. Auto Reclaim is on the Advanced edition, and its accuracy depends on identity provider login data, so it won't cover every app perfectly. Fair tradeoff. For connected apps with reliable telemetry, it gives teams a repeatable way to cut SaaS waste without turning renewal season into a spreadsheet sprint.

Jira Context Is Where Governance Finally Works

Context is the difference between access governance that looks good in policy and access governance that actually works in a busy IT queue. Capture the app, role, reason, duration, approver, usage, and evidence in the same workflow, and you can move faster without giving up control.

The real shift is mental. Stop treating access as a ticket that needs completion. Treat it as a decision that needs context. Automation becomes easier to trust, reviews become easier to finish, and SaaS waste becomes easier to catch before renewal panic hits.