May 18

Categories of Data Subjects and the struggle to determine them

Getting started with your data mapping is often proved to be a hard project. In our experience, most companies struggle to define the data subject categories, which is the first step to build your data mapping. We are here to give you some tips and make your journey smoother!

There’s no one right way to define what data subject categories to use, because it depends mostly on your business structure and data subject categories vary from organisation to organisation. However, there are many wrong-ish ways to do it. This blog post aims at giving you some pointers that should help you ask the right questions to figure out which direction you should take.

 

Most common categories of data subjects

The top 10 most common data subject categories among DPOrganizer’s hundreds of customers are:

  1. Employees
  2. Suppliers
  3. Customers
  4. Job applicants
  5. Consultants
  6. Visitors
  7. Prospects
  8. Contractors
  9. Trainees
  10. Next of kin

These categories should cover pretty much all of the processing activities you carry out. 

But working with these categories might end up being a bad idea since doing so might mean packing different things into one. This leads to either oversimplifications or a lot of specifications within a category. It might be advisable to split some of them up or to add additional ones to make them fit your business reality.

 

How do you determine if a category is too broad?

This is not a black and white question. You should take a careful look at the processing activities carried out that would fall within a category and take an informed decision.

The essential questions you have to ask yourself are:

How similar are the processing activities carried out within a category? Can a clear distinction be drawn between sub-groups in terms of activities carried out? – If such distinctions exist, you have to determine whether they are just practical details or if they are relevant enough to make an actual difference from a data protection point of view.

Practical example

An example we like to give is concerning the data subject category employees. Your organisation likely consists of various departments, such as accounting, sales or HR. Chances are that you process the personal data of your employees in these departments in a similar way, i.e. using similar types of personal data for similar purposes. If such is the case, it makes sense to group them together in one category called employees.

Deviations from the rule

However, there might also be instances where different personal data processed for different purposes are in play, such as if you have back-office employees and on-site staff that carry out very different tasks. This might be the case if your organisation is – let’s say – a healthcare facility with an administrative office and medical personnel. In such a scenario it could be that there is CCTV surveillance in the hospital but not in the back-office or that hospital employees need to undergo a more rigorous hiring process requiring more personal data. Here you might want to use two data subject categories. Another example could be if you have business divisions that have independent procedures to process personal data of their employees or if you have operations in different locations with their own setup.

 

Factors to consider

Before you break down a data subject category to subcategories, you need to consider these factors:

  • Amount and types of personal data being processed
  • The sensitivity of personal data
  • Purposes
  • Retention times
  • Sharing of personal data with third parties
  • Information assets involved
  • General risk of the processing of personal data

In addition to the data protection orientated factors you should also take into consideration how many resources you have available to keep your processing records up to date. Following the mantra ‘perfect is the enemy of good’ you might want to start off with a more generic setup to get a better overview of the circumstances in your organization and the abilities of your data privacy program. As a second step, you can then decide to get more granular for parts of the processing that require more detail.

See more related posts »

Related blog posts