In the previous segments, we focused on special-case transfers that may be hard to recognize. At the macro level, when a user transfers between HR systems, a legitimate transfer can be mistaken for a termination, leading to poor customer service (and the trouble that ensues).
At the micro level, when a user transfers within a department, the transfer may be missed altogether if the affected job codes are not flagged in some way as needing additional information.
In this segment, we focus on two special-case terminations:
- The terminated user takes a leave of absence (LOA) prior to termination
- The terminated user is laid off as part of a reduction in force (RIF)
In each case, the user no longer needs access, but remains active in the HR system because they continue to be paid by the company.
This can pose a security threat, especially in the case of the laid-off employee.
The solution lies with HR…
In these cases, the simplest solution lies with HR: ensuring that the system has – and that HR representatives and hiring managers actively use – a “last day worked†field.
This field is ideal for access management because when it comes down to it, if the employee is no longer working, they no longer need access – irrespective of whether they’re still getting paid.
I strongly recommend working with the HR team to implement or clean up the last day worked field as needed to make it usable with identity management – it simplifies terminations tremendously. If it’s not an option, processes should be developed to handle the afore-mentioned special cases. For example:
- Design a process that will review the termination reason on the day that the termination is entered into the system. If the reason is RIF, determine when the access should be cut off (since RIF information is so highly sensitive, it is normally not entered into the HR system until the user is notified, so the date of entry might be usable as the last day for access)
- Alert on any user that goes into LOA status but that also has a termination date entered into the system, and design a process for verifying if the user is returning from LOA or going straight to termination, and process accordingly. Some manual intervention may be required here – some employees on LOA may still require their access, while others will not. HR should be able to help with this.
…but IAM configuration plays a part
When designing the interface between identity manager and HR, it’s important to consider how terminations will be identified.
If the HR system stores a reliable last worked date, the configuration of identity manager will be simple. If not, careful thought needs to be put into the design of the interface.
Simply going by the effective date of termination without any additional validation will preclude automation of the special cases mentioned above, and although they are relatively rare, these special cases can pose significant security risk if not properly addressed.
In summary
When properly configured, de/provisioning workflows help realize a significant portion of IAM’s value by reducing the time and effort of managing access, while tremendously increasing the accuracy.
However, in the case of transfers and terminations, there are some special cases that need to be thought through to ensure that the de/provisioning workflows are truly complete.
The activity this month was primarily to think about these special cases, and document how they will be handled. It’s possible that a “do nothing†or manual processing approach will suffice, but some organizations will want to spend some time designing automated solutions so that these special users don’t slip through the cracks.
Populating the requirements list
This month, most of the requirements (with the exception of the SoD requirements mentioned in Part 2) are not for the product, but rather for the design team.
Be sure to specify the needs when it comes to special cases for terminations and transfers. Engage HR and management to come to an agreement about how much effort will be put into handling these cases in an automated fashion versus simply implementing manual processes. As usual, there is no right answer here – as long as the right people are involved in the decision and they get a good understanding of the risks and rewards, the right answer for your organization will be reached.
How can I help?
Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.
0 comments