Sep 17, 2018 12:00:00 AM | EU How to cope with the vagueness of article 30 GDPR

The GDPR imposes many rights and obligations on organisations that require software support. Any software supplier will have to make decisions on how to interpret the GDPR and where GDPR compliance software or data processing is needed. Because of the countless vague concepts in the Regulation, suppliers will have different interpretations which of course can lead to a varied number of outcomes within the software. Therefore, it will be quite a challenge to connect different software offerings to each other and maintain functionality whilst meeting the requirements of the GDPR Article 30.

Some practical applications of software connections in the GDPR compliance domain are:

• Data breach notifications to the supervisory authorities (instead of filling in web forms manually)
• Connections between data discovery tooling and article 30 registers (in order to inventory uses of personal data automatically)
• Data portability between different article 30 register software applications (enabling changing software suppliers while keeping data entered)
• Exchange of processing activities between controllers and processors (allowing for easier completion of the article 30 register)

Most of these examples relate to article 30, requiring a register of processing activities. Many of the other rights and obligations of the GDPR relate to insight into an organisation's 'privacy landscape', and therefore will have some link to the article 30 register.

Establishing Software Connections within GDPR

To establish software connections, applications need to 'talk' to each other. They often do this via so-called 'application programming interfaces' (APIs). For these to function, a standardised model of the GDPR is highly desirable. This model would describe the exact attributes of GDPR concepts such as personal data categories, data subject categories, controllers and processors. This can then be managed by the connection of GDPR compliance software.

Data Processing and GDPR

Over the past months, we have talked to many people about the description of processing activities in varying ways. For instance, one respondent had a connection on the level of individual categories of personal data instead of only on a processing level. Another had linked personal data categories to data subject categories. And a third had assigned retention terms to systems instead of personal data categories.

We know that all these description choices were made with very good reasons, although they do not literally follow from the GDPR. Anyone describing a processing activity will have their own focus points, depending on their governance model as well as local policies and practices. The problem is that once descriptions will vary, it also becomes very difficult to reuse such descriptions among software systems.

In the current absence of further guidance from the European Data Protection Board (EDPB), organisations, law firms, consultancy firms and data software suppliers also have to guess what the meaning is of the exact wording of GDPR articles, article 30 in particular. Being a lawyer, I know that it is impossible to remove all vagueness from a law. Concepts rarely have a binary meaning.

Of course, the text of the GDPR is full of political compromises, allowing important decisions to be made later in time, by supervisory authorities and courts. But there is a lot of uncertainty among privacy professionals about whether they comply. Even the Dutch Supervisory Authority, currently doing a survey among organisations in different sectors about their article 30 register, formulates its questions cautiously.

This high degree of uncertainty begs the questions: why was there not a more precise approach to, for instance, the article 30 register? A more formally specified description of elements and relations between them, explaining what entities and which relations should be kept for each processing record, would have helped decreasing that uncertainty. It would also facilitate the automated communication on the register between stakeholders.

Hopefully there will be clear guidance from the EDPB on the article 30 register soon, allowing controllers and processors to be more certain about the entities and relations they need to put into the register, as well as providing clarity on the degree of detail of the inventory. This will both increase legal certainty as well as improve efficiency of the software market for GDPR compliance.