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.