Contact details of individuals are widely processed. A client profile in a webshop, delivery address, customer service request, and many other processing require the name of an individual.
Names are more than sequences of characters
An automatic system receiving and storing customer complaints may treat customer names as random characters, checking them for length, capitalization, and special characters. An employee processing customer complaints or selecting job candidates for an interview may be more vigilant. Most manual processing activities are conducted by individuals who are well aware of different ethnic groups and are not necessarily neutral.
Think of 'Bram de Jong', 'Krzysztof Wiśniewski', or 'Heiner Schneider' (the names are taken from a list of the most popular names, and any match with real people is purely coincidental). Would you expect them to be Dutch, Polish, and German, correspondingly, and all male?
Should I care?
According to the GDPR A. 9 (1) 'Processing of personal data revealing ... ethnic origin ... shall be prohibited'. Additional consent is required (or the necessity to comply with a legal obligation in the field of employment), and additional safeguards are needed, such as conducting a DPIA.
In most situations, you can treat names as neutral characters, and most companies do so. In the majority of processing activities, the names are not processed in a way that reveals ethnic identities. Think of taking online orders which are processed automatically and uniformly, with customer names moving between systems and labels without any analysis.
But you need to stay alert to the (usually, manual) activities where perceived ethnic origin may be taken into account. As a controller of these activities, you are responsible for identifying and assessing the risks, and taking appropriate risk mitigation measures. You are also obliged to take appropriate measures to minimize personal data processing.
What to do?
Keep this in mind when building the records of processing data activities (RoPA) and assessing risks of each activity. In particular, look at:
- Attempts to parse, group, or otherwise analyze names by automatic systems, as that may lead to processing ethnic origins or profiling.
- Manual operations where certain tensions are expected, such as customer calls, or people selection (recruitment, housing, etc.)
- Multi-lingual, international, or outsourced (manual) operations (travel, call centers) where employees may be dealing with international clients and group them mentally.
The processing is often not explicit, and no database field called 'ethnicity' is created. But various ethnicity-specific comments are often left in chats, emails, and other documents. They do reveal the processing happening, and have already resulted in corrective actions by courts and authorities.
From the GDPR compliance documentation perspective, for most operations it is still acceptable and compliant to use the personal data category 'contact details' representing names, together with addresses, emails, phone numbers, and other ways of contacting them. Many companies conduct just one or two processing activities where names are actually looked at.
It is more compliant to split the 'contact details' category into a category for name-revealing data (names, emails, social media profiles, and other contact records that may reveal the name) and another category for nameless contact data (physical addresses, phone numbers). This will help in documenting the processing activities, associated risks, and your efforts on minimizing personal data processing, in compliance with the 'data minimization' GDPR principle (GDPR A. 5 (c)).
You may also want to conduct Data Protection Impact Assessments (DPIA) for activities where names are processed. Conducting the DPIA, regardless of its outcome, is compliance evidence on its own.
We can help with these tasks as part of the PrivacyDocs GDPR consultancy services.