If Your Identity Data Sucks, So Will Your IAM Project

The two questions I hear most when I talk to customers preparing to embark on an identity and access management project are:

  • Where do I start?
  • What are some best practices to ensure the project’s success?

So, today I’ll discuss what I believe is the cornerstone of any successful IAM project, and that is identity data integrity.

Some start projects by designing workflows, provisioning rules, business transfers processes, roles definition, and self-service access requests. The problem is that nobody first looked at data sources and their corresponding data integrity, and the way attributes will map to the central IAM system. When they start building the processes and workflows, they realize that approval workflows are missing approver information ─ employee managers’ fields are empty ─ so workflows are not working properly and provisioning rules are not executing adequately.

Why is this happening? Because the underlying identity data sucks more than a Vampire convention!

Like garlic for a vampire’s attack, the antidote to this problem is to ensure that you examine the underlying data, and analyze its fidelity for the attribute mappings you intend to incorporate into your IAM system’s process, so you can remediate accordingly before putting any process in place.

Below is an out-of-the-box data integrity report from Dell’s One Identity Manager, which can help your IAM project get a great foundational start and maximize your chances of success. This sample report on the data quality of employee records highlights employees’ identity data that is missing department, cost center, location, and other attributes paramount for designing role definitions, approval workflows and other IAM processes. Additional pages of drill down information detail the employee’s missing department data, location data, etc. Having this information before you start an identity and access management project is the ticket to a successful project.

Anonymous