The European Union's General Data Protection Regulation ("GDPR") is arguably the most comprehensive - and complex - data privacy regulation in the world.  In the race to create documents to show they were in compliance, many companies inadvertently created documents that actually show that they are out of compliance.   The net result, is that instead of reducing liability, they have increased it.

Bryan Cave Leighton Paisner is publishing a multi-part series focused on what companies should be doing now that the GDPR is here.  This installment focuses on data inventories.

What is a data inventory?

Article 30 of the GDPR requires that most companies “maintain a record” of their processing activities.  For controllers that record should include the following information for each piece of personal data processed:

An explanation concerning the purpose of the processing;

• A description of the categories of data subjects involved;
• A description of the categories of personal data involved;
• A description of the categories of recipients who receive the data;
• A description of the countries outside the European Economic Area (if any) where the data is sent and the adequacy measures discussed in Error! Reference source not found. used to facilitate the transfer;
• The time period before which the data is anticipated to be erased; and
• A description of the security applied to the data.¹

In the lead up to the GDPR many organizations rushed to create data inventories in-house by using forms and templates supplied by law firms or supervisory authorities, or retained consultants to come in and complete a data inventory on their behalf. 

Why are data inventories dangerous?

Herein lies the problem.  Companies are required to “make the record [of their processing] available to the supervisory authority on request.”²  That means that if a supervisory authority investigates your organization the data inventory will more than likely be the first thing that they request. 

This following is a case study of a multi-national organization that retained a well-reputed consulting company to conduct a data inventory and to create the documentation required by Article 30.  The consulting firm leveraged technology to interview hundreds of individuals (e.g., online surveys) and then created a complex data inventory for the organization.  The overall cost approached $100k. 

At the end of the project, the organization requested that BCLP evaluate the data inventory as part of a holistic GDPR gap assessment.  Our evaluation found that the descriptions for 80% of the systems that were inventoried were either inaccurate (at best) or documentation of per se legal violations (at worst).  Indeed, had the inventory been produced to a supervisory authority they would have identified what appeared to be at least ten systemic violations of the GDPR that crossed dozens of data systems.  The tragedy was that the organization’s actual data practices – if correctly described and correctly documented – did not violate the GDPR.  The only violations were the ones that the data inventory created.

While the errors or issues created in the inventory are too many to list, the following is part of a three-part case study that describes some of the main problems that the inventory – if it were ever seen by a regulator – would have created:

Part 1: Listing consent as the permissible purpose

The consulting company had listed “consent” as the permissible purpose in 64% of the data systems– including for finance systems, billing systems,  HR payroll systems, HR expense reports, HR recruiting, HR timekeeping, etc.  This created many problems. 

First, the consulting company had not gone back and reviewed how the company was obtaining consent – instead they relied upon questionnaires that they had disseminated to various department heads.  Those department heads were not lawyers, they were not privacy professionals, and they had never read the GDPR.  As a result, when they said that there was “consent” they were using that terms as a layman would use it – not as would a supervisory authority.  When we drilled down to particular systems we found that in many cases there was no consent instrument, in other cases while consent had been obtained there was no documentation of the consent, and in still other cases the documentation that existed showed that the consent did not meet the standard within Article 7 of the GDPR to be effective which, among other things, requires that the consent be affirmative in nature, that data subjects be given the ability to withdraw their consent, and that data subjects receive sufficient information to make their consent informed under European standards.  The net result was that few, if any, of these systems had consent documented on a level that would withstand the scrutiny of a supervisory authority. 

Second, the consulting company had listed consent for numerous HR systems not realizing that the Article 29 Working Party – the predecessor to the European Data Protection Board – had taken the position that for “the majority of . . . data processing at work, the lawful basis cannot and should not be the consent of the employees . . .  due to the nature of the relationship between employer and employee.”^₃  Again the result was that a supervisory authority that reviewed the document would have found dozens of systems that, because consent was assigned as the basis of processing, arguably violated one of the GDPR’s requirements that could trigger the maximum administrative penalty of up to 4%.

1.  GDPR, Article 30(1)(b)-(g).

2. GDPR, Article 30(4).

3.  WP 259 at 8.

[View source.]