In the first segment, we looked at one extreme of transfers – a job change entailing a move between HR systems. In this segment, we’ll look at the other extreme of transfers – a job change that may fall under the HR radar.
When we talked about the implications of HR as a source of record for identity management, we discussed that HR’s purpose is to pay people, not determine their access. The example given was that of a finance analyst – in HR terms, there’s no distinction between an accounts receivable analyst and an accounts payable analyst – they’re both finance analysts and they get paid the same way, so they have the same job code. In access terms, there’s a very big and important difference between accounts receivable and accounts payable.
When granularity is needed beyond what HR can provide through a job code, additional analysis is needed to ensure that these types of transfers are caught and handled.
Augmenting job codes
There are a number of ways to augment a job code to distinguish between roles when it is access-relevant but not HR-relevant.
The additional information *should* still be available from HR, as well. For example, consider the location of the individuals, or the manager’s job code or title. Manager name could be used as a last resort, but only if vacancy management is already in place.
The IAM team will need help from the HR team to determine what additional information can be used to accurately identify intra-departmental roles for transfer purposes. This can be quite challenging, and it may be a foreign concept to the HR team at first. This is again where prior relationship building will really come in handy.
As a last resort, identity manager can be configured with additional flags that can be set manually by an HR representative or manager if appropriate information is not readily available in the HR system. This, of course, will require the creation of one or more workflows.
Don’t forget the cleanup!
Once the job code augmentation parameters are identified, it’s good to run some reports and double-check current members of intra-departmental roles of interest. You may be unpleasantly surprised by what you find, but that’s always better than being unpleasantly surprised by what the auditors find. J
Populating the requirements list
Many IAM systems have built-in functionality to handle segregation of duties (SoD), but as with everything else, not all systems are created equal. If SoD is of particular concern in your organization, be sure to add the specific requirements to the master list so that they are addressed in the product evaluation.
In the next segment, we’ll take a look at special-case terminations and how they can affect access, and wrap-up the month’s activity.