In the previous segment, we worked through the de/provisioning workflows. These are foundational to the non-employee management workflows in that a key objective of the non-employee management workflows is to terminate access when the non-employee departs. Without the de/provisioning workflows to trigger manual or automated tasks for access removal, the timely knowledge of a non-employeeâ€™s departure loses a lot of its power.
Non-employee management is a problem that many companies have because non-employee data is typically not centrally stored in an HR-like system as employee data is. By implementing this set of workflows, it creates a closed loop which allows identity manager to be the source of record for non-employees and closely track their comings and goings in a timely fashion.
Objective 1: Determine the appropriate scope
The scope discussion for non-employees is pretty cut-and-dry: the scope is non-employees. J But there are a few nuances.
For example, if there are employees whose HR system will not be integrated with identity manager, they may be managed like non-employees and be considered in scope.
Thereâ€™s also the distinction between fixed duration and ongoing non-employees as described in this monthâ€™s Introduction. Fixed duration non-employees are those that are around for a specified timeframe to do a specific piece of work â€“ such as a project resource or temp. These individuals should be tracked according to their projected end-date.
Ongoing non-employees are those that provide a continuous or intermittent service â€“ such as a supplier, and outsourcing provider, or the Cisco guy that the network team calls at 3am when something bad happens and the fix is beyond their expertise. In this case, the company has an ongoing relationship with the employer of the individuals in question, but the specific individuals may change.
For example, the Cisco guy may get a job elsewhere and be replaced by a new Cisco guy â€“ the company still gets support from Cisco, but itâ€™s important to know if this yearâ€™s guy is the same person as last yearâ€™s guy. In this scenario, individuals are recertified periodically on a schedule.
Objective 2: Populate the requirements list
The requirements for non-employee management are more internal. The associated workflows are straightforward and possible with any of the better products. But, there will be some configuration requirements. For example, the identity manager form thatâ€™s used to enter non-employees into the system should ask what type of non-employee it is (fixed duration vs. ongoing), and prompt for an end-date for fixed duration individuals. The end-date will be needed to trigger workflow tasks, asking the line manager if the person is leaving on time or if they are being extended.
The individualâ€™s company should also be a required element on the entry form â€“ itâ€™s helpful to recertify all individuals from a single company on the same schedule.
Objective 3: Identify prep-work
Hopefully, the non-employee cleanup occurred as part of the activities outlined in February and March. If not, itâ€™s time to get cracking on those â€“ itâ€™s important to know who all of the non-employees are, who they work for (their companyâ€™s name and your companyâ€™s line manager), what type of non-employee they are, what they do, and what their expected end-date is (if applicable).
This may be especially challenging for IDs of vendor support personnel like the Cisco guy, since they typically arenâ€™t around very often, and are rarely if ever on-site. With this type of non-employee you typically have to go find the one manager who recognizes their name, and even the manager who should recognize the name might not. But having a good, clean list of non-employees and their associated data will make implementing the workflows a breeze.
Itâ€™s also good to start thinking about the timings of the workflows:
- How long before an end-date does the line manager first get notified?
- How many times does the line manager get notified before thereâ€™s an escalation?
- What if no action is taken by the due date â€“ does the user get submitted for full termination, or are they just disabled?
- What is the cut-off for re-starting the workflow for an extended individual? (E.g., if the person is extended a week, itâ€™s probably safe to trigger termination on the new end-date. But what about if theyâ€™re extended a month or more? In that case, itâ€™s probably best to re-start the workflow and ask if there will be an additional extension.)
- How often should ongoing non-employees be recertified â€“ quarterly? semi-annually? annually? This is a policy question that may take some discussion and vetting.
In the next segment, we’ll discuss the full set of user and access recertification workflows.