Your HRMS Knows Who Joined. Does Your IT Team Know What Access They Should Have?

[#1]

When a new employee joins, HR, management, and payroll are aligned. But IT is often left guessing which groups or permissions are required.

HR knows the employee. IT has to know the access.

HRMS platforms track identity details like department and role. However, they don't automatically define security boundaries. For instance, should every Engineering hire get full AWS admin rights? Likely not. Access governance defines these specifics.

Probably not.

That's where access governance begins.

The hidden problem with "just automate onboarding"

Automation isn't just about creating accounts. Without governance, you miss critical controls:

• Who approved the access and why?
• What happens when a user changes teams?
• How is temporary access revoked?

Provisioning is just the start, lifecycle management is the goal.

 

Think of the employee lifecycle as an access lifecycle

Instead of treating onboarding as one event, look at the entire journey:

Access doesn't end when the onboarding ticket closes.

Controlled automation in action

Replace free-form requests with structured workflows. Automation should manage the heavy lifting, while humans focus on high-risk approvals:

• Standard: Manager approval triggers automatic provisioning.
• Sensitive: Multi-tier approval (Manager + Owner).
• Privileged: Time-bound access that expires automatically.
• Scheduled: Access is automatically granted to the designated user starting from a selected future date. 

Scaling with Jira Service Management (JSM)

JSM acts as the governance layer, connecting your HRMS and identity platforms to ensure consistency. It handles the mover/leaver scenarios that often lead to "access creep."

The Governance audit test

Can you reliably answer these for an employee hired 6 months ago?

• What access was granted and who approved it?
• Has it been reviewed since?
• Can you remove it all tomorrow if they leave?

The long-term payoff

Without Governance	With a Structured Governance Model
More employees ↓ More applications ↓ More access requests ↓ More manual work ↓ More exceptions ↓ More access creep ↓ More audit pain	More employees ↓ Standardized requests ↓ Defined approval rules ↓ Automated provisioning ↓ Periodic reviews ↓ Controlled revocation ↓ Consistent audit evidence

If answering requires spreadsheets and manual searches, you have an access-governance problem. Start small, automate key rules, and build a scalable lifecycle.

[Elena_Elevatic]

hi @James Anderson thanks for this post, The mover case is the one that quietly does the most damage — joiner and leaver at least have a trigger event someone remembers to act on. A role change three teams later usually doesn't, so the old access just sits there next to the new access. If JSM is already the governance layer for provisioning, the same workflow that grants access on hire should re-evaluate on every HRMS role/department change, not just run once at onboarding.

[Prabhu Palanisamy _Onward_]

My default answer to our customers - do not automate access provisioning if you don't have context.

Step1: Use Assets to load user, groups, roles, licenses and associate with users. For this you need to imports from employee data from HRIS e.g BambooHR. Role, group and license data from Identity provider e.g Entra ID and device data from device management tools e.g Intune.

Step2: Provide support agents with rich context on the request, i.e the department of the user, location, hiring manager, current role and group assignment. This will enable the agent to make informed decisions.

Step3: Once you have step 1 and step 2 then look for automations based on clear rules e.g department sales, assign salesforce license etc.

To summarize, use assets build the context graph of the user and their assignments. Use that to enrich service tickets and finally automate with clear rules for provisioning and deprovisioning access.

[James Anderson]

Hi,

I agree with the core point that context should come before automation, but I wouldn't make Jira Assets a prerequisite for safe access provisioning.

Assets can be a valuable context and relationship layer, but the more important question is where the authoritative data comes from and how the access decision is governed.

For example, if the HRIS says Department = Engineering, Role = Software Engineer and a defined policy says Engineering + Software Engineer → GitHub Developer, that can be evaluated deterministically without first copying the identity into Assets.

The bigger distinction is between context, policy and execution:

Authoritative identity data → resolve context → evaluate access policy → approval when required → provision → audit → continuously re-evaluate.

Assets can enrich that process, particularly when you need relationships across users, groups, applications, devices and licenses. But I would be careful about making a replicated Assets dataset the source of truth for access decisions. Replicated data can become stale, and access governance ultimately needs to answer not only "what does this user currently have?" but also "what should this user have, why, who approved it, and what should happen when their context changes?"

That's also why I think mover events are just as important as joiners. If someone's department or role changes, the system should re-evaluate their access and remove what is no longer justified, rather than simply using the enriched context to grant additional access.

So I'd frame it as: build context, define policy, then automate with guardrails. Assets is one way to build that context, not necessarily a prerequisite for automation.

[James Anderson]

Hi @Elena_Elevatic 

Absolutely. The mover case is where access provisioning really becomes access governance. A department or role change shouldn't simply trigger additional access. It should trigger a re-evaluation of the user's existing access against the new role, so the system can determine what should be added, retained, or removed. Otherwise, every career move becomes another opportunity for privilege creep: new access gets added, old access gets forgotten. That's why I see the HRMS event as the trigger, but the governance layer needs to evaluate the before vs. after state, apply the relevant access policies, route exceptions for approval, and then provision/deprovision accordingly. Joiner gives you access. Mover proves whether your governance actually works. 

[Aditya_miniOrange]

@James Anderson 

Thanks for this post and discussion. Here are my thoughts

This is exactly where the difference between access automation and access governance becomes important.

HRMS can tell you that an employee joined, moved teams, or left. Identity platforms can help provision and remove access. But the missing piece is often the decision-making layer:

What access should this person receive?
Who should approve it?
Does that access still make sense after a few months?

A mature governance approach adds context before provisioning.

For example:

• Engineering hire → GitHub access may require manager approval.
• Production AWS access → May require manager + application owner approval.
• Temporary admin access → Requires approval with an expiry date.

Instead of relying on users to manually decide the right approver or chasing approvals over email, structured workflows can automatically determine the required approval path based on factors like application, role, department, access level, or risk.

This is where Jira Service Management, along with miniOrange Access Governance, can become more than a ticketing platform. It can act as the governance layer between HR systems and identity platforms:

HR System → Access Workflow → Approval Decision → Identity Platform → Application Access

The key is maintaining visibility throughout the lifecycle:

• Who requested the access?
• Why was it required?
• Who approved it?
• When was it provisioned?
• Has it been reviewed?
• Was it revoked when no longer required?

This also helps during access reviews and audits, where the question is rarely:

"Can you create an account?"

The real question is:

"Can you prove why this user has this access today?"

Combining structured approval workflows, automated provisioning/deprovisioning, periodic reviews, and complete audit trails helps organizations move from simply managing accounts to actually governing access throughout the employee lifecycle.

[James Anderson]

@Aditya_miniOrange

This is a really important distinction: access automation answers "how", while access governance answers "what, why, and under what conditions."

And I think there is one more piece that becomes interesting here: context shouldn't just be used to make the initial provisioning decision. It should become an input to continuously re-evaluate access.

Imagine:
Day 1: Engineering + Software Engineer → GitHub + Jira + Confluence
Month 8: Moves to Product → GitHub access may no longer be justified
Month 12: Gets temporary production access → should expire automatically
Month 18: Leaves → everything should be traceable and removable
If we're only automating the provisioning step, we've automated the easiest part. 😄

The real governance loop is more like:

Context → Policy → Decision → Approval → Provision → Monitor → Re-evaluate → Revoke

And that's where I think JSM becomes particularly interesting. The ticket/workflow shouldn't just be the "request form". It can become the decision and evidence trail connecting HR events, business context, approval decisions and identity platforms.

The question I keep coming back to is:

"Can we explain why this person has this access today, not just why we gave it to them 18 months ago?"

That's probably the real test of access governance.