In the last article, we discussed how to identify access transfers from HR data. Now weâ€™re in the home stretch: terminations.
Compared to transfers, terminations are pretty easy, but there are a couple of gotchas, as mentioned in this monthâ€™s introduction. A termination in the HR system means the employee is no longer getting paid. However, the termination date for getting paid may or may not coincide with the date the employee should stop having access to the companyâ€™s systems.
As with transfers, removing terminated usersâ€™ access in a timely fashion is a key control for a variety of audit regulations, including SOX and PCI. On the other hand, itâ€™s also a customer service issue â€“ remove the userâ€™s access too soon and itâ€™s disruptive to the business (and can cause significant turmoil if the employee has not yet been notified of their termination).
Here are the key considerations for how HR data can be manipulated to feed identity management the right information to handle terminations.
â€œLast Day Workedâ€
If your HR system has a Last Day Worked field and it is actively populated and used, youâ€™re home free â€“ 99.9% of the time last day worked = last day access is needed. In this case, there is one possible gotcha: if the employee stays on in their current job function, but as a contactor.
Remember, the HR system focuses on payroll. Because of this, if an employee changes status from â€œemployeeâ€ to â€œcontractorâ€ they may still be terminated from an HR perspective â€“ especially if non-employees are stored in a different HR system. From an access perspective, itâ€™s business as usual, although such individuals might need to be run through the transfer process to re-approve their access.
There are three ways to handle an employee becoming a contractor in the same job function; by handle I mean ensuring that the user does not experience an access interruption:
- Find out if this is even a possibility at your company. If it isnâ€™t, youâ€™re done.
- Find out if the HR system has some sort of flag (e.g., a termination reason â€“ see below) that will identify this situation. If they donâ€™t, see if this can be added to the system â€“ that would be ideal.
- Accept that this is a rare occurrence and not worth handling with technology. In this case, consider launching an awareness campaign with hiring managers and HR so that they remember to notify your access services team when this situation arises.
Analyzing termination reasons
If Last Day Worked is not a field that is reliable, an analysis must be done on termination reasons. Typically, the HR system will provide some sort of drop-down menu where the reason for termination is specified â€“ things like â€œgot another job,â€ â€œretired,â€ â€œreduction in forceâ€ (i.e., laid off) â€“ although these are typically represented as codes, not text.
There is usually an indication if the termination was voluntary or involuntary. The list of reasons isnâ€™t trivial â€“ there can be a couple dozen reasons including things you might not expect like â€œdeceased,â€ â€œgoing to active military duty,â€ and â€œdidnâ€™t like the dress code.â€ As an aside, I was amused to see one HR system in which military duty was considered an involuntary termination, while deceased was considered a voluntary termination. 🙂
It is important to analyze all of the termination reasons and determine (with the help of the HR experts) which termination reasons would normally correspond with the last day of work, and which might not.
The terminations reasons that most likely need to be flagged are listed here, but there may well be others â€“ make sure that the HR team clearly explains any of the more ambiguous reasons:
- Reduction in force
- Leave of absence (this is one that might need to be looked at even when there isnâ€™t a termination associated with it, but thatâ€™s outside of our current scope)
- Becoming a contractor (if thatâ€™s an option)
You may also want to discuss executive termination with the HR team. Although this may not be flagged specifically in the termination reasons, executives are the most likely to keep getting paid for a long time even when theyâ€™ve stopped needing access. Additional workflows may be needed to handle this situation, or simply an awareness campaign with the HR department so that they remember to notify the access services team when an executive gives notice.
â€œTermination Dateâ€ and â€œAction Dateâ€
In the identity management world, we typically consider the termination date to be the last day that someone works. In the HR world, termination date is usually the first day that the user doesnâ€™t get paid â€“ in most cases this would be the day after the last day worked. This is an important distinction, and one that should be confirmed for your HR system, because you donâ€™t want to cut off someoneâ€™s access on the last day they work â€“ this is the day when theyâ€™re trying to wrap things up and get going. Thereâ€™s no telling if theyâ€™ll be done by 10am or 10pm, and it can have a pretty negative business impact if a premature loss of access keeps them from finishing their work.
If HR termination date = last day the person works, make a note to configure identity management to begin the auto-deprovisioning processes on HR termination date + 1. If HR termination date = first day the person isnâ€™t getting paid anymore, it can safely be used as the date to start auto-deprovisioning.
For those termination reasons where the access termination date is before the HR termination date, the action date might be useful. The action date is the date on which the information is entered into the system. For example, itâ€™s common practice to enter a termination into the system for someone being laid off after theyâ€™ve been notified of the layoff. If laid off = escorted out right away, identity management could use the action date (or action date + 1) to trigger auto-deprovisioning. In this case, action date would be before termination date.
In the case of a vacation or leave of absence before termination, there may not be usable data in the system. These scenarios should be discussed with the HR team, and a workflow or awareness campaign might be warranted.
In the next article, weâ€™ll wrap up this monthâ€™s activities with a general discussion of HR data cleanliness, and how identity manager can find the HR data it needs and pull it.