Over the past few weeks I’ve been working with a prospective customer on their identity governance requirements. During one of the conversations on how to automate the identity provisioning processes an interesting comment was made. They preferred a human to perform all identity provisioning actions as then a human would have a chance to make a decision whether the requested permissions made sense. Now this raised some additional questions for me, not in the least on which framework and internal procedure the IT support engineer would use to decide which permissions would be correct. And how they are currently deciding whether granted access and access permissions are in line with those frameworks.

Digging a little bit further, the root cause for this uncertainty whether automated JML processes had less to do with the clarity of what should be provisioned for different types of employees and roles. But rather, the uncertainty was due to a major distrust in the quality of source data to work with. Their HR system is not consistent in how job functions are defined and attached to different employees. So two employees with the same function in the organization could have a different job title or role attached inside the HR system. Which obviously will lead to a lot of complexity in defining the provisioning rules inside any identity platform to get the right outcomes.

Generally my advice in such situations is to first make sure that the source uses a single consistent dictionary across all employees, both for the initial setup as well as ongoing for future employees. Because Garbage-In is Garbage-Out in such situations. On top of that, you want to make sure that processes exist to update this across the board when organizational changes need to be deployed across all systems. And more importantly, that those processes are actually followed and implemented. Because all too often the effort is done, disregarded after a few months and all of a sudden the IT support engineer is in charge again of making identity decisions. So clean up the source data, remove non-accurate data, because the ownership of correct data for identities is not with the IT department, but it’s where the relationship with the employee is owned. And follow this not just for employees, but this should be common practice for non-HR employees as well. Someone owns the relationship with a specific vendor that needs access to systems, so make sure that ownership for the identities also lies there.

Fortunately for this customer the amount of employees was not too high and it would have been a straightforward task. Even better for them was that an enterprising IT engineer had already done a lot of clean-up of this data in their ITSM platform. The job functions and job titles from the ISTM system were validated by HR and approved, new procedures written for future actions and the only thing left to do was to update the source data inside HR. By connecting multiple sources, enriching the data pulled from the HR system into the identity platform with data from the ITSM platform and then performing a write-back to the HR system with the updated attributes, this project was completed quickly by using the identity platform as a two-way ETL engine.

I understand this will not work everywhere and the exercise is meaningless if the procedures are not changed and implemented at an HR department level. And more importantly, this is the opportunity for us as identity practitioners to educate other departments on how their work supports building more secure operations at every level in the organization. Make this a shared responsibility and a shared journey, because security is too big of a job to leave to any single team within the organization.