Diversity data collection - Getting it right! (pt1)

When it comes to the collection and use of diversity data, every organisation I've worked with has done so to strive towards a diverse and inclusive workplace through tracking and analysing data. But even those with the purest of intentions must be questioning their approach in these seemingly never-ending headlines of data breaches. 

What has struck me the most is the recurring theme of personal and sensitive data being stored beyond the purpose for which it was collected. And this, in my view is the greatest hurdle for HR departments looking to collect diversity data, facing the questions:

• Why are we collecting this?
• When are we collecting this?
• How are we storing this?

In this three-part blog I am going to explore this challenge and with my observations of 10 years of providing analysis of workforce diversity, see if I can come up with an approach that gets it right.

Part 1: The ring of governance

Before data is collected HR departments need to consider governance. This isn't an easy task and often not an area of expertise within HR. But data governance is a requirement in all aspects of people data. Diversity data is both personal and sensitive and should be classified as highly restricted in all HR departments. This classification requires extra steps be taken to ensure its safety and reduce the risk and impact of a breach. These steps include:

Defining the purpose for the data being collected.
This is about transparency about the full extent to which the data is going to be used. A lot of organisations are good at declaring that data collected is confidential and won't be used to identify any individual. But they don't always extend the declaration to include that the data will be used for analysis and therefore accessible to reporting teams, or that it will be used to interface to other systems to create user profiles. The misuse of data, no matter how unintentional, is a breach. It's vital to make sure that the declaration of purpose includes all possible uses of the data for the duration of its lifecycle

Identifying the process through which the data is collected.
This refers to the methodology of data collection as well as the HR lifecycle process that it relates to. The most common methodology I have observed is the use of a "form" or module within the HR payroll system which is completed during or after the onboarding process. Increasingly organisations are trying to capture diversity data during the recruitment process and using this to pre-populate and employee profile. If this is done right, then great. If not, then it risks a breach. I'll explain more in part 2.

Building confidence in the security of the systems used to store the collected data.
HR systems are evolving at a rapid pace with big players such as Oracle, Workday, SuccessFactors and Cornerstone all offering "end-to-end" HR systems. End-to-end simply means that all HR processes can be executed from within a single "front end" platform. In other words, HR operations or line managers can do everything all in one place. The reality of these systems is that they are not truly end-to-end. Many are made up of modules that we're legacy best of breed systems acquired by the big players over time. Whether you have an end-to-end HRIS or a collection of systems, data needs to flow between them. The movement of data from one system to another can result in a breach. The potential of this movement needs to be understood, transparent and declared as part of the purpose of collection.

Quality of the resulting diversity data
The above governance considerations can have an impact on the structure and quality of the data produced. Which in turn impacts the analytical value when trying to evidence a diverse and inclusive workplace. There are some things that an analyst needs to be able to do their job well. This includes being able to access the data in its raw form without fear of a breach. The data being structured and stored in such a way that there is a single source of truth and not conflicting data across multiple systems or modules. Whilst having the ability to link this data to other system data through an identifiable field.

All of these aspects need to be taken into consideration when collecting diversity data, no matter where in the lifecycle it is collected.

In part 2 I share some of the observations I've made over the years of analysing and providing insights on diversity data.