A former employee had production access for 65 hours after termination. IT deprovisioned within 45 minutes of finding out. The audit still failed, because IT found out three days late. This is the actual shape of most access-policy failures: not a slow response, a late discovery. HR-driven provisioning fixes the second problem, which is the one that was never IT's to fix alone.
Friday, 5:00 PM: a finance manager terminates an employee in Workday. Friday, 5:01 PM: IT doesn't know. HR emails the termination notice Sunday night. Monday, 10:15 AM: IT starts deprovisioning. Total time the account stayed live: 65 hours. The compliance policy requires 24.
Nobody in that sequence was careless. HR did their job the moment they knew to do it. IT did their job the moment they knew to do it. The 65 hours lived entirely in the gap between those two moments, a gap neither team controlled and neither team was measuring.
That gap is the actual subject of this article. Not provisioning speed. Discovery speed. (For the broader pattern behind why provisioning breaks down at scale in the first place, that's its own piece.)
The Accountability Nobody Actually Has Control Over
IT carries three specific accountabilities, and all three depend on the same missing input:
- Enforcing least privilege
- Maintaining SOC 2 and ISO 27001 compliance
- Deprovisioning within a fixed window after termination
Each one depends on knowing an event happened, which is the one thing IT doesn't control. HR is accountable for keeping HRIS current, and they generally do. But HRIS being accurate and IT being informed are two different facts, and the distance between them is measured in emails, Slack messages, and weekly CSV exports.
An auditor doesn't split this fairly. "Former employee had access for three days, who's responsible" gets answered with "the systems weren't connected," which is another way of saying both teams were accountable for an outcome neither one could single-handedly produce.
HR-driven provisioning closes that gap by making the HRIS update itself the trigger. HR still does exactly what they already do, update Workday, BambooHR, or whichever system of record they run. The difference is what happens next: instead of that update sitting in HRIS until someone remembers to communicate it, it fires an event IT's systems receive immediately. HR keeps the accountability they already have. IT gets the control that was always missing.
The reframe that matters here: IT isn't provisioning slowly. IT is provisioning promptly on information that arrived late. Fix the arrival time and the rest of the pipeline, which was mostly fine, starts working.
One Discovery Gap, Five Broken Policies
Every access policy IT is held to assumes IT knows about the triggering event close to when it happens. Late discovery breaks that assumption identically across very different policies, which is why the same three-day gap shows up as five separate kinds of failure.
The additive-only failure mode deserves its own line, because it's the quietest and the most common. When someone gets promoted, the new access almost always gets added.
The old access almost never gets removed. Not out of negligence, but because "give them what they need now" is a completed task the moment it's done, while "check what they no longer need" was never anyone's assigned step.
Run this pattern across a few hundred role changes a year and you get a workforce holding the union of every job they've ever had. That's a much larger attack surface than anyone individually decided to create.
It's why movers get treated as identity management's orphan child: joiners and leavers get automated first, and the harder, quieter middle case waits.
Why HRIS, Specifically, Should Be the Trigger
HR isn't the source of truth because of hierarchy. It's the source of truth because it's the only system that has four things IT needs at the moment they're needed, not the moment someone remembers to relay them:
- Timing: knows the dates before anyone else does
- Context: structured fields, not a one-line Slack message
- One record: no second copy that can drift out of sync
- First knowledge: HR always learns first; the only variable is how fast that reaches IT
Each is worth unpacking on its own.
Timing. HRIS knows the hire date, the promotion date, the termination date, the contract end date, before anyone else does, because those dates are what HR enters to do their own job. IT needs exact timing to schedule deprovisioning for the actual termination moment rather than the moment an email gets read.
Context. A Slack message saying "Josh starts Monday as an engineer" is missing everything a policy engine needs to act correctly: which team, what seniority, contractor or full-time, which office. HRIS has all of it as structured fields, because HR needed those fields for their own workflows first.
One record instead of two. The moment IT starts maintaining its own copy of employee data, that copy starts drifting from HRIS the day it's created. Six months later, HRIS says Engineering Manager and IT's spreadsheet says Software Engineer, and access reflects whichever one someone last updated. There's no fix for this except not maintaining a second copy.
First knowledge. HR always learns about a lifecycle event first, because they're the ones recording it. The only variable is how long it takes that knowledge to reach IT: days over email, hours over Slack, or minutes over a direct system trigger. HR-driven provisioning is simply choosing the fastest of those three paths as the default one.
The Seven Events Worth Automating
Every lifecycle event maps to a specific policy, and each one has a detail that manual coordination reliably gets wrong. These seven map onto the same joiner, mover, leaver arc every identity program eventually has to cover, broken down to the level a policy engine actually needs.
"Better Collaboration" Isn't the Fix. Integration Is.
The default response to provisioning delays is "HR and IT should communicate better": weekly syncs, a shared Slack channel, a Monday CSV export. It feels like progress and it isn't, because collaboration and integration solve different problems. Collaboration is people coordinating, which is valuable for agreeing on policy but doesn't scale past a certain volume. Integration is systems coordinating, which scales without adding headcount.
A weekly CSV looks like automation and behaves like a fax machine: someone still has to export it, someone still has to import it, and the data is up to seven days stale the moment it lands. It breaks the moment the person who exports it takes a week off, and it can't tell IT which three records changed since last week without a manual diff. None of that is integration. It's manual coordination with a spreadsheet in the middle.
The version that actually works keeps collaboration for what it's good at, agreeing on which fields matter, which policies apply to which roles, what counts as a valid team name, and hands ongoing operation to a system that reads HRIS directly and reacts to changes as they happen. Setup takes a conversation. Running it takes nobody.
The Failure Mode That Looks Like Success
Two mistakes show up most often here, and both look like progress from the inside:
- Maintaining a second employee database and calling it integration
- Treating SCIM as if it covers the whole job, not just the account
The first is the more expensive one. It starts reasonably: IT needs fields HRIS doesn't have, so a spreadsheet or an internal tool fills the gap. It ends with two systems of record that silently disagree, because HR updates HRIS and nobody updates the second copy on the same schedule.
The bill for that gap is real and unglamorous. At a 500-person company running roughly 50 promotions a year, even a modest 20% miss rate means ten employees carrying the wrong access for a few months at a stretch, discovered only when someone complains they can't approve a budget or access a tool their new role requires. If you're maintaining any employee data outside HRIS for provisioning purposes, that's the tell that the integration isn't actually one.
The second mistake is quieter: SCIM gets treated as "we automated provisioning" when SCIM only creates the account. Permissions, which repos, which Jira projects, which Slack channels, still get configured by hand, which means the account exists on day one and the actual access arrives whenever someone gets to it.
The Challenges of IT-Driven Provisioning on Its Own
"IT-driven" here means IT provisioning access based on what it can find out and act on independently, without HRIS pushing the event automatically. It's the default model most companies run today, and it breaks down in predictable, well-worn ways.
Discovery is reactive by design. IT doesn't get told when a lifecycle event happens; it has to notice. That means checking email, asking around, waiting for a ticket, or running a periodic audit to catch what slipped through. Every one of those paths adds delay between the event and IT's awareness of it.
Context arrives stripped of the details policy needs. Even when IT does learn about an event, it usually comes through an informal channel, missing the structured attributes, department, seniority, employment type, location, a policy engine actually needs to provision correctly. IT ends up guessing, or asking follow-up questions that add more delay on top of the delay that already happened.
It doesn't scale with headcount. IT-driven discovery requires a proportional amount of effort for every new event. More hires, more role changes, more departures all mean more instances of IT having to notice, ask, and act. The model that works at 50 employees becomes a full-time job at 500.
Requests get handled. Revocations don't. IT-driven provisioning is usually structured around requests: someone asks for access, IT grants it. That works reasonably well for the grant side. There's rarely an equivalent request for taking access away, since revoking a departed or role-changed employee's old access isn't anyone's job to ask for. This is the mechanism behind the additive-only pattern covered earlier.
Compensating data structures drift. To cope with not being told directly, IT teams often build their own tracking, a spreadsheet, a ticketing queue, an internal database, to approximate what HR already knows. That copy starts diverging from HRIS the moment it's created, since nothing keeps the two in sync automatically.
The audit trail becomes a liability instead of an asset. When an auditor asks when something happened and when IT acted on it, an IT-driven process usually answers with a forwarded email timestamp or someone's memory of a meeting. That's a much weaker record than an HRIS timestamp tied directly to a policy-evaluated action.
What Changes
Given all of that, HR-driven provisioning doesn't ask HR to work differently. They keep updating HRIS exactly as they do now. What changes sits entirely on the IT side: instead of waiting for that update to reach them through a second channel, their system reads it directly, in close to real time, and evaluates it against policy immediately.
Two examples show what that looks like in practice:
- A termination scheduled for Friday 5:00 PM triggers deprovisioning at 5:01, not the following Monday
- A promotion updates access within minutes instead of whenever the weekly export lands
This is also the specific foundation zero-touch provisioning is built on. HR-driven provisioning solves when and what, HRIS fires the event and carries the context a policy needs. Zero-touch is what happens to everything downstream of that event: the account creation, the permission configuration, the verification that access actually works. You can't get to zero-touch without this piece in place first, which is why it's worth treating as its own project rather than a footnote inside a bigger automation initiative.
Zluri's HRMS integrations read directly from the HR systems companies already run, Workday, BambooHR, Rippling, and others, and turn every lifecycle event into a policy-evaluated trigger the moment it's recorded, not the moment someone remembers to mention it. This is one piece of a broader access management practice; the exact fields, Directory Management setup, and attribute-mapping details behind it are covered in how Zluri handles HR-driven provisioning.
Frequently Asked Questions
What is HR-driven provisioning?
An approach where the HRIS update itself triggers access changes automatically, rather than IT discovering the same event later through email, Slack, or a periodic export. When HR marks someone terminated, IT's systems receive that event within minutes, not days.
Isn't this the same as syncing our HRIS with our IdP?
Related but not identical. An HRIS-to-IdP sync typically moves basic attributes (name, email, department) for authentication purposes. HR-driven provisioning uses those same signals to trigger policy enforcement, deprovisioning on a deadline, revoking outdated access on a role change, expiring contractor access on the contract end date. The sync creates the pipe; policy enforcement is what runs through it.
How is this different from zero-touch provisioning?
HR-driven provisioning is the trigger layer: HRIS fires the event with the context a policy needs. Zero-touch provisioning is everything that happens automatically after that trigger, account creation, permission configuration, verification. HR-driven provisioning is the prerequisite; zero-touch is what it makes possible.
Does HR need to change how they work?
No. HR keeps doing exactly what they already do, updating HRIS when someone joins, moves, or leaves. The change is entirely on the IT side: systems that listen to those updates directly instead of waiting for a second notification.
What if HRIS data is incomplete or inconsistent?
Then policy enforcement fails quietly on exactly the records with bad data, an empty team field, a job title that doesn't match any defined policy. This is why implementation starts with a data-quality pass, not just wiring the integration: confirming required fields are populated and using consistent values before the policy engine has to guess.
What if HR updates HRIS late?
Then the trigger is late too. HR-driven provisioning doesn't fix data-entry timing, it fixes the delay between HRIS being updated and IT knowing about it. If HRIS itself lags reality, that's a separate conversation about HR's own process, and a real audit trail actually helps here: it shows plainly whether a compliance gap traces back to a late HRIS update or a late system reaction, instead of leaving both teams guessing.
Does this replace access reviews?
No, it complements them. HR-driven provisioning keeps access correct at the moments that matter, hiring, transfers, terminations. Access reviews catch the drift that accumulates between those moments, when policy wasn't applied consistently or a manual exception was never revisited. Automated correctness at the event level plus periodic review is the actual full picture.
.svg)
