Data Mapping & the GDPR: "Records of Processing Activities"

  • Author: Niklas Drexler
  • Last updated: 01.07.2020
  • Category: General Obligations

Any privacy law implementation program is based a proper data mapping. But is it even a legal obligation? Under the GDPR, the answer is a clear "yes" for most of modern businesses. Article 30 requires companies to maintain so-called "records of processing activities" (also known as RPA or ROPA) with detailed information on your data flow. We explain how to meet the GDPR standards.

Which companies and organizations must maintain RPA documentation?

The obligation to maintain “records of processing activities” applies to any company or organization which processes personal data within the scope of the GDPR. From an international perspective, the GDPR’s extraterritorial applicability does not require that the company is established in one of the EU member states – it is sufficient that a company is somehow doing business with the EU.

Exception for SMEs

In principle, businesses with less than 250 employees do not have to have an RPA, however, this limitation appears to be a red herring, as the law provides for broad “exceptions from the exception”. In fact, an SME still needs to maintain RPA documentation if only one of the following 3 scenarios applies:

  • The company processes sensitive data (“special categories” of personal data in the meaning of the GDPR, e.g. health or biometric data, information relating to political opinions, criminal convictions, sexual orientation, racial or ethnic origin, etc.).
  • The company processes personal data more often than just “occasionally”, i.e. if it has a structured and systematic approach on collecting personal information, either as a part of its products, or of its other business processes such as customer relations or accounting.
  • The company’s business operations are somehow causing data privacy risks (e.g. identity theft, blackmailing, manipulation).

This means in fact that any enterprise needs to comply with the requirement, irrespective of the number of employees. Whether or not a company is exempted from the RPA requirement should be subject to a legal assessment in the individual case. In case of doubt, if the GDPR applies to your business in general, you should rather assume that your company must have it.

Scope of the RPA

The scope of an RPA includes one legal entity. From a legal point of view, it is not necessary to maintain separate documentation for dependent branch offices. It may, however, be advisable to include in the RPA which internal user groups (e.g. departments, branch offices) are authorized to access or alter the data set in question, particularly for medium and large enterprises. Such approach enables the responsible compliance professional to determine who will be the primary internal contact for a particular business process, and also to oversee compliance with further organizational requirements under the GDPR, such as the application of the “need to know” principle for personal information.

What do we need to document in the RPA?

Basically, the RPA is a spreadsheet that provides certain information on all of the company’s business processes falling within the scope of the GDPR. The documentation can be maintained electronically such as an Excel file or any other commonly used format.

Talking about its content, it is crucial to understand the distinction between the role of a company as a "data controller" and as a "data processor" (we further explain these key GDPR terms in our article on the GDPR’s extraterritorial scope). Depending on which role the company takes, different content requirements apply. It is important to keep in mind that the same company may, with regard to different business processes, both act as a data controller (e.g. when collecting personal information for its own marketing purposes) as well as a data processor for its customers (e.g. in the context of its SaaS cloud product for its customers).

You will better understand the content described below if you also have a look at some examples. The following links will lead you to templates that have been issued by the British Information Commissioner's Office (ICO), the data protection authority of the UK:

General content requirements

First of all, the RPA needs to include the company’s full legal name and contact details of the main establishment, and, if applicable, of the company’s Data Protection Officer as well as its EU representative.

With regard to any other information provided in the RPA, it is advisable to structure the table of information by referencing certain business processes (for data controllers) or business customers (for data processors), respectively. The ICO emphasizes that the RPA must be structured in a way that allows to meaningfully relate the categories of information to each other. It provides the following example:

“For instance, you may have several separate retention periods, each specifically relating to different categories of personal data. Equally it is likely that the organisations you share personal data with differ depending on the type of people you hold information on and your purposes for processing the data. The record of your processing activities needs to reflect these differences. A generic list of pieces of information with no meaningful links between them will not meet the GDPR’s documentation requirements.”

Based on such structure, the RPA documentation must further include:

  • In case of data transfers to countries outside the European Economic Area, the name of the receiving country, and, in certain exceptional settings, further information on the legal justification of the transfer;
  • Where possible, a general description of technical and organizational measures for data security. In this regard, the RPA may also refer to secondary documents (e.g. IT security concepts, audits, and penetration tests).

Further requirements for data controllers

In addition to the contents mentioned above, the RPA of data controllers must include the following information:

  • A description of the purpose of the particular data processing operation (e.g. delivery of purchased items);
  • A description of the categories of data subjects concerned (e.g. customers) and of the categories of personal data (e.g. name, postal address);
  • The categories of recipients to whom the personal data is disclosed (e.g. parcel service provider);
  • Where possible, the envisaged time limits for erasure of the different categories of data (e.g. 3 months after delivery, unless the customer has created a permanent user account);
  • If applicable, contact details of other legal entities acting as joint data controllers together with the company (e.g. different resellers in one group share a database in an order management platform).

Further requirements for data processors

The scope of the RPA for data processors is limited. In addition to the general content requirements mentioned above, the RPA of data processors must contain the following information only:

  • The name and contact details of each controller on behalf of which the processor is acting (a complete customer list);
  • The categories of processing carried out on behalf of each controller, i.e. a list of products and services, including a description of what the company is doing with the personal data processed on behalf of the controller (e.g. cloud storage of HR master data).

Which strategical aspects should we consider when drafting the RPA?

Leverage your GDPR compliance program

First, drafting RPA documentation may leverage the whole data protection compliance program, as a well-prepared RPA includes a lot of information that is relevant for other tasks (e.g. assessing whether a particular business operation is legitimate under the GDPR, or whether it is necessary to enter into data processing contracts with customers and vendors). Hence, the RPA drafting process can be a bracket for the whole GDPR compliance program and may serve both as an operational point of entry to gather information from various departments, as well as a basis for a legal plausibility check at the end of the implementation process.

Keep your RPA documentation up to date

Second, the RPA should be considered as a living document. Companies are advised to implement regular update processes, e.g. on a periodic basis, when new business processes are implemented, and as a part of product development loops. If a company is acting as a data processor for others, it should be ensured that the details of new customers are forwarded to the internal department which is responsible for maintaining the RPA in the course of the onboarding procedure.

Consider what you want to disclose to authorities

Third, one should bear in mind that companies are required to disclose the RPA documentation to the competent EU data protection supervisory authority upon request. A business without any establishment in the EU, which has therefore appointed an EU representative pursuant to Article 27 GDPR, must provide a copy to its representative, who is then also obliged to disclose it if a competent supervisory authorities asks it to do so.

The impact of this requirement is twofold: First, shortcomings of the RPA documentation may be easily visible (and subject to high administrative fines). Second, the RPA may reveal non-compliance with other GDPR requirements. When deciding on what information is included in the RPA documentation, you should thoroughly balance between comprehensive compliance with the content requirements as defined by law, and the aim to disclose unnecessary details which may trigger additional investigations. Companies may also decide to maintain an internal version of the RPA documentation as well as one for potential disclosure.

Ring Binder with inscription Compliance on Background of Working Table with Office Supplies, Glasses, Reports. Toned Illustration. Business Concept on Blurred Background.
© tashatuvango / stock.adobe.com | #104774398

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.

In this overview you can select and deselect individual cookies of a category or entire categories. You will also receive more information about the cookies available.
Group essential
Name Matomo
Technical name
Provider
Expire in days 72
Privacy policy
Use Use without cookies
Allowed
Group external media
Name Calendly
Technical name __cf_bm,__cfruid,OptanonConsent
Provider Calendly LLC
Expire in days 365
Privacy policy
Use To arrange appointments via the provider Calendly
Allowed
Name Contao CSRF Token
Technical name csrf_contao_csrf_token
Provider Contao
Expire in days 0
Privacy policy
Use Serves to protect the website from cross-site request forgery attacks. After closing the browser, the cookie is deleted again.
Allowed
Name Contao HTTPS CSRF Token
Technical name csrf_https_contao_csrf_token
Provider Contao
Expire in days 0
Privacy policy
Use Serves to protect the encrypted website (HTTPS) against falsification of cross-site requests. After closing the browser the cookie is deleted again
Allowed
Name PHP SESSION ID
Technical name PHPSESSID
Provider Contao
Expire in days 0
Privacy policy
Use PHP cookie (programming language), PHP data identifier. Contains only a reference to the current session. There is no information in the user's browser saved and this cookie can only be used by the current website. This cookie is used all used in forms to increase usability. Data entered in forms will be e.g. B. briefly saved when there is an input error by the user and the user receives an error message receives. Otherwise all data would have to be entered again
Allowed