Governance, Risk Management, and Compliance blog

GDPR: You prepare more records of processing activities than you should

[fa icon="calendar"] Monday, 14 May 2018 / by Jakob Holm Hansen

Due both to an eagerness to do things correctly and a fear of doing things wrong, many companies prepare far more records of their processing activities than necessary. Our expert explains how you can group together your processing activities and save yourself many hours of (wasted) work.

As already known, the GDPR sets a requirement that businesses must keep records of their processing activities. A record of a processing activity can be described as a record of a business's logically coherent processes. And what is that?

Let us take a few examples.

Personal information found in employment contracts, wage payments, sickness registrations, pension plans, performance reviews and the like, is all part of a logically coherent process that can be designated as "Staff Administration". GDPR does not require you keep records of all the subprocesses in your staff administration system. Nor a mapping out of what systems and platforms are used in the handling of staff administrative data. In this context, the regulation only requires companies to describe the overall purpose of processing personal information in staff administration.

Download our 7-step guide to implenting the EU GDPR

According to the same logic, customer contacts on a website, customer contacts over the telephone and customer contacts upon face-to-face meetings are not essentially different processes requiring the preparation of specific records. All customer contact, involving personal data, is a logically coherent process that can be designated as "Customer contact". In this manner, you can continue to group together processing activities, for example, "Issuing loans" and "Marketing activities".

What are you doing?

Jakob Holm Hansen, our CEO, states that it can be difficult to make groupings of logically coherent processes. Nevertheless, he recommends that the task be done.

"Try looking up your own company in the company register. What does it say you are doing? Do you run a grocery store, do you sell rubber shoes, or what is your core activity? Your purpose in doing business must be compared to your need to process data about the registered subject. In other words, does it make sense that the company processes such personal information about these people within the processes? That is the entire train of thought to be applied when preparing a record of a processing activity," says Jakob. "Remember as well: The record should be relevant to the registered subject, not just to you as a company. That is the whole idea behind GDPR."

“Remember as well: The record should be relevant to the registered subject, not just to you as a company. That is the whole idea behind GDPR."

Jakob Holm Hansen


Processing activities are not data flow analyses

Jakob explains that some confusion arises due to mixing the concepts of "record of processing activities" and "data flow analyses".

Whereas a data flow analysis is an overall view of the complete IT landscape - for example networks, infrastructures, storage, databases etc. – and how data moves between all applications, processing activities only form a record that offers an overview of how one processes personal data and in which overall processes.

"Some companies confuse the two things and start making a record of their data flows. First of all, GDPR does not require that. Secondly, preparing an overall picture of the entire IT landscape is an enormous task, since it is constantly changing."

Legal statutes make for a good benchmark

It might be a question of definition when determining whether any processes are more naturally associated with others. Consider for instance if you, as a company selling electronics, have customer contacts with both private individuals or public sector companies. Should the overall customer contact be considered one or two logically coherent processes?

"Sales to private individual and sales to companies are subject to different legislation. That is why the processing of personal information to one segment and to the other are two different processes, and one must keep two separate records of the processing activities. The same is the case if you as a company have both processed customer data for analysis purposes and customer data for sales purposes. These are two processes with two essentially different purposes. One is of a research character. The other deals exclusively with sales," says Jakob Holm Hansen.

"I understand very well that it can be difficult to tell the difference, but try to look at the legal basis that governs the field to which personal data processing is subject. If the processing of personal information in, for example, in all of a company's customer contacts is subject to the same legislation, the company will likely only keep one set of records. However, if the processes involving such data processing are subject to different legislation, then it can be assumed that records are kept of those processing activities that are logically coherent."

Data protection is a classic IT discipline

Once the purpose has been mapped out and records of the processing activities have been prepared, GDPR also requires that one describe how the registered data are protected during each processing activity.

"This is a classic IT discipline. It is about describing how, for example, one addresses access control, encrypted data, log files etc. There are many IT departments that already have a good grasp on this. This must be documented in another manner than that to which they have become accustomed, but they know the basic task," concluded Jakob.

More about the GDPR

Guide: Implementing the GDPR in 7-step - download here

Guide: Handling personal data security breaches in three phases - download here


Emner: eu general data protection regulation, GDPR, processing activities

Good enough IT risk management

The Neupart blog offers advice and knowledge of effective information security management, security strategies, risk management, compliance with information security standards and other requirements, business continuity planning, ISO2700x, EU Data Protection Regulation, PCI DSS, etc.

Popular Posts