The first category is employees or associates. The defining criteria of an employee is that they are present in the HR system. The HR system will tell us when a person joins the company, when a persons personal data changes or when the person leaves or gets fired. This is of course especially true if the HR system also feeds payroll. In most cases the IDM system will be directly connected to the HR system which will mean that the IDM system automatically will be notified about any changes.
The second categories are people that aren't directly hired by the corporation but rather are hired by another entity or they are hired by the corporation but in a different employment form. This means that this category of people are usually not present in the HR system. The users are still working for the corporation as consultants, contractors, contingent labor or partner employees. These users still needs access to IT systems so we need to somehow include them in the IDM system so that we can control their access.
If you are lucky the corporation actually has a database or some kind of application that tracks these users. In some cases it may not be one application but anywhere from a couple to a dozen applications. In this case you can just connect to these systems and you can handle these users the same way you handle employees.
In many cases there simply isn't any system that keeps track of the contractors so they need to be entered by someone directly into your IDM system. Not only do they need to be created but the contractor information also need to be maintained. Bearing this in mind what kind of lifecycle events do we typically need to support? In my experience these are the most important:
- Creation
- Update of personal data
- Change of manager
- Termination
Update of personal data is always really hard to get actually get up and running. In most cases personal information about a contractor user tends to get stale which may or may not be an actual problem for the IDM system. For example if a contractor gets married and changes their name in the name information in the IDM system should be updated but in many cases this information is never entered into the IDM system.
Change of manager is a critical use case if you are using the manager as a source of truth about the contractor. It is common that a contractor initially gets hired to work for one manager but later the contractor switches projects and ends up working for another manager. If you don't have updated and correct information about which manager each contractor reports to you will have a problem. Another problem that you will encounter is that the contractors manager may have left the company without first reassign their reports to another employee. It is often a good idea to include a check for reporting contractors in the termination process for an employee.
Terminations is of course just as critical as creations. We do need to remove the access for contractors that no longer is working for the company but there is nothing that motivates anyone to share the fact that a contractor has left with us. The contractor is gone so the contractor won't tell us. The manager is unlikely to tell us as the manager has nothing to gain.
The standard solution to this problem is to implement mandatory recertification of contractors. When a contractor joins the contractor gets a finite life span. Typically life spans is somewhere between 90 days to a year. Unless the contractor gets extended the contractor will be terminated once the end date is hit.
In most cases the extension is done by the contractor manager either directly in a self service interface or by calling the helpdesk. In order to ensure that the manager remembers to extend the user you usually implement a reminder process that sends out a number of reminder emails typically starting 30 days before the termination is supposed to happen.
If the user no longer works for the manager that the idm system has listed then you have a problem. This is especially true if the manager has left the company. In many cases it therefor a good idea to send the warning email to the user as well as the manager. The user is usually motivated to talk to their current manager who will then make sure that the IDM system is updated and that the user is extended.
Once you have these processes in place your contractors life cycles are in place the audit and corporate information security departments should be happy. Or at least happy enough to leave you in peace for a while.
Great article! During analysis I would recommend the company to create a repository for contractors rather than entering them directly to IDM. My rationale is that someday may come and some other application will need to access the contractor data and they would want access it from IDM, making IDM an HR system involuntarily. I wonder what other arguments could be made against entering contractors directly to IDM.
ReplyDeleteIndeed a great article Martin. You would ,however, also want to consider including the case where a contractor is hired as a full-time employee and AD or other such resources (that are given to both a contractor and full-time emp) may fail to provision since the auto-generated logins which also form the DNs, stop OIM from creating a similar DN for the contractor who is now hired as a full-time employee.
ReplyDelete