Practical approaches to doing data mapping and building RoPA.

Since the adoption of the GDPR in 2016, the requirement of Article 30 to have records of processing activities (RoPA), which covers both data controllers and data processors, has been among the most debatable ones. While the GDPR is not the only legal framework requiring to put RoPA in place, there are also other good reasons (apart from legal ones) to do so. In this article, DPOrganizer attempts to look closer at how to build a good RoPA and make related processes in the company sustainable enough.

GDPR rules and management approaches

As mentioned above, the GDPR Article 30 requires both data controllers and data processors to put RoPA in place. Upon closer look, it might become clear why this is perceived as a ‘curse’ by many organisations. Indeed, the RoPA must literally include a detailed map of what is happening with personal data within (and – to some extent – outside) an organisation: what is being processed, for what purposes, for how long, how it is protected, where it is transferred to, who it is shared with, etc., the level of detail differs for controllers and for processors.

However, such a perception is far from being fair. Apart from being a stand-alone legal requirement, building a good RoPA also streamlines compliance with other requirements. For example, privacy notice is largely informed by RoPA, meaning that drafting and updating privacy notice(s) is much easier when an organisation has a sufficiently detailed and regularly updated RoPA. Besides, RoPA serves as an enabler when it comes to ensuring compliance with data breach risk assessment and notification requirements – moreover, RoPA might become a real ‘game changer’ for an incident response team aiming to report a breach within a 72-hour timeline. On top of that, RoPA may facilitate going through different data protection audits. Finally, after all, it helps build trust by demonstrating to other actors that an organisation is in control of the personal data it is responsible for.

The GDPR knows some exemptions from the requirement to maintain RoPA – when an organisation employs fewer than 250 persons unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data or criminal records data (Article 30(5)). This first and foremost covers small and micro enterprises. However, even when this is not mandatory from a legal point of view, it is still recommended to get busy with building RoPA, for the reasons mentioned above.

First steps towards comprehensive RoPA

Behind building RoPA the process of identification of personal data collected and processed is laying. In practice, this is usually done through information-gathering interviews driven internally (e.g., by a privacy manager, by a data discovery team) or externally (by engaging an outside consultancy). During that process, an interviewer (either internal or external) has a sit-down with the typical functions that collect, store, use, share and otherwise process personal data and tries to identify personal data throughout the data lifecycle. Data discovery tools might support this process.

Typical questions to be asked during those information-gathering interviews are usually as follows:

• Who collects, uses, stores and otherwise processes personal data?;
• What personal data types are involved and what is the purpose of collection and further processing?;
• Where is personal data physically stored?;
• When and how is personal data collected?;
• Who is personal data shared with, why is this happening, what is the role / functionality of those data recipients?;
• When / how is personal data collected?;
• For how long is personal data stored, what is the justification for the designated retention period, how is personal data deleted?;
• What technical and organizational security measures and controls are in place to protect personal data?

As can be seen from the suggested list of questions above, interviewed stakeholders might be required to have some degree of understanding of such concepts like ‘personal data’, ‘data controller / processor’, ‘data sharing’ to be able to properly understand the questions being asked and to give meaningful and comprehensive answers. This might present a certain challenge. With this in mind, an interviewer should make sure that the respondents have undergone some basic privacy training before the information-gathering interviews take place. Failure to do so may impede the interview process and result in the responses being inaccurate and/or incomplete, thus affecting the accuracy and completeness of RoPA.

At the same time, it might well be the case that an interviewer has to talk to stakeholders having little-to-no understanding of those concepts. In this case, it is recommended to start a conversation with some general ‘opener’ questions like ‘what do you usually do in your role on a daily basis?’, ‘what processes are you involved in and how do they look?’, ‘who do you interact with?’, etc. Answers (that ideally should be insightful and detailed) normally provoke more pinpoint questions – e.g., ‘you said that you ask job applicants to fill out a form, but what types of data they are asked to provide in this form and how do we use it?’.

Building vs. Maintaining

Building RoPA is just the first stepping stone towards compliance: maintenance of its accuracy and completeness is just as important. However, a privacy project is not a ‘one-man army’ exercise, and the privacy team normally cannot be constantly aware of each data processing activity occurring in each function, whether new processing activities emerge and how they change over time.

This challenge requires respective RoPA maintenance routines to be put in place, requiring particular stakeholders within the organisation to assist the privacy team (or another RoPA owner) in keeping RoPA updated. Oftentimes those stakeholders are some employees in specific functions (departments) within the organisation whose responsibilities include keeping certain pieces of RoPA (in part assigned to them) updated or, at least, notifying the privacy team (or another RoPA owner) about occurring changes requiring updates to RoPA. Where so-called ‘privacy champions’ are nominated in the organisation’s functions (departments), those are normally made responsible for that.

For the sake of clarity and proper governance, and to comply with the GDPR accountability requirements, the routines and procedures for keeping RoPA updated should be reflected in the organisation’s documentation (policies, manuals, procedures, guidelines, etc.). Like in all other cases, this documentation just remains a piece of paper, unless relevant stakeholders are duly trained. So, to put it into practice, staff should receive training and understand who does what.

RoPA vs. privacy notice

As mentioned above, building a good RoPA streamlines compliance with other requirements, with one of them being an information provision requirement (Articles 13, 14 of the GDPR). In most cases, the required pieces of information are provided to data subjects through privacy notices (those are also often called privacy notifications, privacy policies, or similar).

It can be noticed that the list of what should be communicated to data subjects in privacy notices is much longer than that of what should be included in RoPA. However, there is a broad area of intersection between RoPA and privacy notice. In particular, both of them should contain the following information: the purpose of the processing, legal basis, categories of personal data concerned, recipients (categories of recipients), retention periods, information about third countries transfers.

The GDPR requires the information to be provided to data subjects “in a concise, transparent, intelligible and easily accessible form, using clear and plain language”, while there are no any specific requirements as to how the information should be reflected in RoPA. However, from the management perspective, it is still recommended to reflect the information in RoPA following the same standard, i.e., keeping it concise, transparent, intelligible, in clear and plain language. There are at least two strong reasons for that approach:

– Repurposing. As mentioned above, privacy notice is largely informed by RoPA. Privacy notices are way easier and quicker to create and update when pieces of text can be just copied from RoPA. For example, if in RoPA purpose is described in a concise, transparent, intelligible way, in clear and plain language, this description might be copied to privacy notice with few or no tweaks;

– Better understanding and transparency. RoPA needs to be understood also by those stakeholders who were not a part of the RoPA building team. Those might be both externals (e.g., supervisory authorities) and internals (e.g., newly hired privacy manager or even DPO). It always helps avoid unnecessary questions and save much time (otherwise spent on discussions and clarifications) when the RoPA’s text is clear and understandable right from the beginning.

For the same reason (although this is not a legal requirement) it makes sense to include in RoPA pieces of information required to be included in privacy notice. For example, the GDPR Article 30 does not require RoPA to cover the description of the legitimate interest pursued by the data controller or by a third party, but it still makes sense to reflect it in RoPA – to keep it transparent for other stakeholders consulting RoPA and to make drafting and updating privacy notices easier.

As for the description of personal data categories concerned, again, those have to be notified to data subjects “in a concise, transparent, intelligible and easily accessible form, using clear and plain language”. With this in mind, broad and unclear wording (e.g., “HR data”), as well as exemplary lists of personal data categories (e.g., “Name, email address, etc.”) should be avoided in RoPA and privacy notices. It is acceptable to group personal data categories but it is important, for the sake of clarity and transparency, to specify what is included in each group (e.g., “Contact details (email address, phone number, home address)”).