SailPoint Identity lifecycle

When a new worker appears in the authoritative source, the joiner process creates their identity cube and provisions birthright access, the baseline every person in that role, department and location needs on day one. The goal is day-one productivity with zero manual tickets: the new hire logs in and their core accounts already exist.

The design question here is what somebody gets before anybody asks for anything. That set is called birthright access, and it should be derived from their job rather than requested. Email, the intranet, the standard productivity tools, and whatever their department universally needs.

Getting the boundary right matters in both directions. Too little and the new starter spends their first week raising requests, which is the experience most organisations actually deliver. Too much and you have granted access to somebody who has not yet demonstrated they need it, to every person who joins, forever.

When someone changes department, manager, job title or employment type, the mover process adjusts their access to match the new position. Crucially, this means removing access tied to the old role as well as granting the new. Movers are where privilege creep is either reversed or, if handled carelessly, accelerated.

This is the stage that is done worst and it is worth understanding why. A move generates an obvious requirement, which is the new access, and a non obvious one, which is removing the old. The new access has somebody chasing it: the employee cannot do their job. The removal has nobody chasing it, so it does not happen.

The consequence accumulates. Somebody who has moved three times holds the union of four roles, and the combination is frequently something no policy would ever have approved deliberately: raising a purchase order, approving it, and releasing the payment. Nobody granted that. It assembled itself.

So the test of a lifecycle implementation is not whether joiners work. It is whether a mover's provisioning plan contains revocations.

On termination, the leaver process removes all access, typically disabling accounts immediately to stop access fast, then fully deprovisioning as cleanup completes. Prompt, complete offboarding is the most important single control for reducing orphaned-account and insider risk.

The distinction that matters operationally is between disable and delete, and they belong at different times. Disable should be immediate, because the risk window is the hours after somebody leaves unhappily. Delete should be later, because their mailbox, their files and their records are often needed by whoever picks up their work.

So a real leaver process is two steps separated by a defined period, with an exception list somebody owns. Which sounds like detail and is the difference between a process that gets followed and one that gets overridden the first time it deletes something a manager needed.

Rehires, long-term leave, contract extensions and conversions from contractor to employee are all lifecycle transitions too. Mature programmes handle these explicitly rather than treating them as edge cases.

Half a day in a test environment, and it is the exercise that tells you whether the lifecycle is real or just configured.

1. Create a test identity in the source with a department and a job title. Let aggregation run and record exactly what access appeared.
2. Compare that against what the birthright roles say it should be. Differences here are role model problems, not workflow problems.
3. Change the department. Watch the event fire and read the provisioning plan before it executes.
4. Count the revocations in it. If there are none, stop and fix the role model, because nothing downstream will save you.
5. Terminate the identity. Check each target system directly rather than trusting the status in the console.
6. Now reactivate it, as a rehire, and see what comes back.

Steps four and six are the ones that find real defects. Most implementations pass step one on the first attempt and fail step four, and step six is usually the first time anybody has thought about rehires at all.

Lifecycle events are driven by changes in the authoritative source. When HR marks someone as hired, transferred or terminated, aggregation brings that change into SailPoint, identity refresh detects the changed attribute, and a configured lifecycle event (in IdentityIQ) or lifecycle state transition fires the appropriate provisioning. This is why clean authoritative data and a reliable refresh cadence are prerequisites: the lifecycle is only as timely and accurate as the HR feed behind it.

The uncomfortable truth about triggers is that they are only as good as the source, and the source is usually an HR system operated by people with different priorities. Two specific problems come up everywhere.

Late data. A termination entered three days after the person left produces a leaver event three days late. The workflow is correct and the exposure is real, and no amount of configuration fixes it. It is a conversation with HR, supported by evidence about how often it happens.

Contractors and non employees. Frequently not in the HR system at all, or in it with an end date that keeps being extended, so the leaver event fires and has to be undone. Deciding where the authoritative record for non employees lives is a question worth settling before go live, because the answer is often that there is not one.

Measuring the gap between the real event and the system event is worth doing once, honestly. It is the number that describes your actual exposure, and it is usually larger than anybody expects.

• Orphaned accounts from manual offboarding are a perennial top audit finding and a real breach vector.
• Slow onboarding costs productivity and frustrates new hires and their managers.
• Inconsistent handling across teams undermines every downstream control.

Automating joiner, mover and leaver replaces all of that with a consistent, logged, auditable process that runs the same way every time.

The arithmetic is worth doing out loud, because it is what convinces a sceptical audience. A ten thousand person organisation with fifteen percent annual turnover and a similar internal move rate generates something like three thousand lifecycle events a year, each touching several systems. That is not a queue anybody works through by hand accurately.

The manual failure mode is not that it does not get done. It is that joiners get done, because people complain, and leavers do not, because nobody does. So the manual process degrades in exactly one direction, towards accumulated access, which is the direction that matters for risk.

• Define birthright carefully. Too little and new hires raise tickets on day one; too much and you institutionalise over-privilege.
• Handle the timing of leavers. Immediate disable protects fast; graceful deprovisioning handles mailboxes, data ownership and manager reassignment.
• Plan for imperfect HR data. Late or wrong feeds cause wrong-time provisioning; build tolerance and alerting.

See the Joiner, mover, leaver lesson for the specific IdentityIQ mechanics of lifecycle events and states.

Two more decisions belong on that list and are usually made by accident.

What to do when provisioning partially fails. One identity change touches six systems and four succeed. The identity now matches neither the old state nor the new one, and nothing announces it. Somebody has to own the failed request queue, and assigning that on day one is much cheaper than assigning it after the first mover spent a fortnight unable to work.

How much to automate before the data is good. Automation propagates whatever the source says, quickly and consistently. Turning it on over poor identity data does not create the mess, it just makes it arrive faster and with an audit trail. The defensible order is to fix the data, then automate, and the tempting order is the reverse.

Version note: the lifecycle concepts here are product independent and apply equally to the on-premise product and the cloud offering. How you configure them does not: the two have different models for expressing events and provisioning, so guidance written for one does not transfer to the other even though the vocabulary is shared. See the identity concept, identity governance, configuring a lifecycle event and federation.

• Movers that only grant. The single most common defect, and it is invisible in every dashboard.
• Trusting the console over the target system. A green status is not an account.
• No owner for failed provisioning. Partial states persist until somebody complains.
• Automating over bad identity data. Faster, more consistent, and still wrong.
• No plan for rehires and contractors. Both are common and both are usually handled after they first go wrong.

Configuring a joiner takes an afternoon, and building a mover and leaver process a business will keep accurate is the work the course covers.