Money for old ROPA

The Data Protection Commission recently announced they were commencing a sweep of Registers of Processing Activities across a range of organisation sectors. This is a welcome action, as students of mine in UCD School of Law will know, because the ROPA is the fulcrum for much of the regulatory controls and governance that an organisation needs to have in place under GDPR (and the Law Enforcement Directive).

Back in late 2019/early 2020, Castlebridge did a sweep of our own, using ROPAs that had been acquired through FOI requests. The ROPAs we obtained were in a variety of formats, at various levels of detail and granularity. We developed a simple scoring rubric to assess them against the requirements of Article 30 and their “usability” as a navigation tool for data. We documented our findings in a “ROPA State of the Nation Report” that we published in November 2020.

What is a ROPA?

A Register of Processing Activities (aka ROPA) is a governance and control artefact that is required under Article 30 of GDPR. It requires organisations to document certain things about their processing of personal data. Specifically, it focuses on the activities that are using data. the categories of data, the categories of stakeholder (data subject, recipient etc.), and the legal basis relied on for processing. The information documented in the Article 30 Register of Processing Activities should inform the information that is disclosed to data subjects in Data Protection Notices under Article 13 or Article 14. If the latter does not map to the former, then what you are disclosing as your processing doesn’t align with what you have documented as your processing.

Ultimately, the ROPA captures the Who, What, When, Where, How, and Why of the processing activities in your organisation for which data about people is processed. These primary interrogatives are fundamental metadata that describes how data is used in your organisation.

When is a ROPA needed?

There is sometimes confusion as to whether smaller organisations need to document their Register of Processing Activities. This arises, in part, from the text of Article 30(5) which seems, at first glance, to suggest that organisations with less than 250 employees don’t need to do a ROPA. However, a closer reading of this sub-clause shows that this “exemption” is limited as some form of documentation will be required if the processing will result in a risk to the rights and freedoms of data subjects (so, if there is a risk of their data protection rights being impacted, their right to privacy being impacted, or any other rights under the Charter of Fundamental Rights), or if the processing is “not occasional”, or if the processing relates to special categories of personal data or data relating to criminal convictions or offences.

So, that means that a sports club that processes personal data about the fitness levels of players and data relating to Garda vetting of coaches and support staff who might be in contact with children or vulnerable people (for example) needs to have a ROPA. It means that a small business that regularly (as part of its operations) processes data about staff or customers needs to have a ROPA for those processing activities.

Of course, it’s important to bear in mind that the EDPB (in its former guise as the Article 29 Working Party) has issued guidance that makes clear that a ROPA is a foundation on which other compliance obligations, such as the Accountability Principle, is grounded.

The WP29 highlights that the record of processing activities is a very useful means to support an analysis of the implications of any processing whether existing or planned. The record facilitates the factual assessment of the risk of the processing activities performed by a controller or processor on individuals’ rights, and the identification and implementation of appropriate security measures to safeguard personal data – both key components of the principle of accountability contained in the GDPR.

So… no ROPA, no basis for asserting your risk-based approach to data protection, no basis for determining the appropriateness of technical and organisational controls, and generally no roadmap for how you are meeting your obligations under the GDPR.

Common Pitfalls when developing a ROPA

Documenting a ROPA can often result in organisations falling into some common pitfalls. In our reviews of ROPAs over the past few years, we have seen a number of common issues:

1. Going too granular

Organisations often start with the minutiae of their processing. This can result in the effort to compile the ROPA getting bogged down in details and not progressing. A lot of organisations made this same mistake over 20 years ago when they were trying to build compliance programmes for things like the Sarbane-Oxley Act. A key lesson learned was that it is easier to start at a level of abstraction of your processing activities and then drill down into the detail to the level you need to do commensurate with the level of risk in the processing. So, you could start your ROPA by asking “What are the 6 (high level) things we do in this organisation, and what data about people do we need to process to do those things?”. Then you can drill down. Remember: it’s easier to drill down than to dig up!

2. Confusing Processing Activity with Document/Record/Data Inventory

A ROPA is a register of Processing Activity. It’s not a list of forms or application screens or systems. It’s a register of “things that are being done with data”. Some of those things may then feed into other things (e.g. sales processes feeds to invoicing and customer management processes). This gives us our “data flow” across the organisation. We don’t get that by looking at our toes and listing all the databases we have (but that’s important too).

So, what is a “Processing Activity”? It’s a thing that is done. A thing (process) that is done to some thing (asset/data) using something (tool/technology/method) to achieve an outcome (goal/objective). The best way to identify a processing activity is to look at the “grammar”. If we are doing a VERB to a NOUN, it’s probably a processing activity. For example “REGISTER (verb) CUSTOMER (noun)”.

3. Not assigning ownership and accountability

The ROPA needs to be a living document. And there needs to be accountability in the organisation for keeping it accurate and up-to-date. That means there needs to be organisation design for data governance to ensure that the ROPA is properly resourced and maintained. That accountability and responsibility needs to be aligned with the organisations internal governance model. This is where considering the process view is important… who is ACCOUNTABLE for the process and its outcomes? Then they should be accountable for the ROPA and the metadata surrounding their processes!

4. Not thinking in terms of categories and meta-data

Often ROPAs are documented at a detailed level that makes them unwieldy and difficult to maintain. One factor that contributes to this is where organisations ‘get into the weeds’ and record the specific fields or data items that are being processed. It is far better to take a meta-data approach and recognise the importance of the word “CATEGORIES”. Organisations that define a robust Business Data Glossary that allows for the categorisation and aggregation of data into CATEGORIES in a taxonomy can simplify their ROPAs and make them much more navigable. Rather than listing “postal address, phone number, contact name” against a processing activity for a customer, you could record “Customer Contact Details” as the category and then define that category (and map the locations of that data) in a Business Glossary. That way, if the data changes or the classification changes, your maintenance overhead on the ROPA is much less.

Likewise,

An Enterprise Architecture Approach to ROPA development

For many years we’ve used an Enterprise Architecture approach to developing and documenting ROPAs. This approach allows us to apply a proven framework for Enterprise Ontology, the Zachman Framework, to documenting the Who, What, When, Where, How, and Why of data in the organisation. By adopting this approach, we can start documenting at an “Executive Management” level and describe the organisation’s processing activities at that level of abstraction, and then drill down into the detail as needed, from the perspective of the “Business Manager” down to the specifics of the actual instance of a process (a form, an application screen, or code).

Basically, it’s a structured approach to asking the key questions at different levels of detail and then having a structured way to record them. And it works. And it can be developed out using post-it notes before being documented formally!

The ROPA as a starting point

Of course, smart organisations will take the discipline of the ROPA and move it out of the pure “Data Protection” world as they mature their data management practices. With a little bit of modification, a good ROPA can be extended to encompass other categories of data, not just personal data. Organisations that make this leap can build on the strong foundation of a good ROPA to deliver improvements in data governance and data quality in other areas of the organisation. This can help your Data Protection investment deliver further value in the organisation.

How we can help

Castlebridge has worked with countless organisations to develop, review, and improve Registers of Processing Activities. We help organisations to understand them as a strategic tool for the organisation, regardless of its size.

You can find our ROPA State of the Nation Report here. And you can check out our elearning short course on ROPAs here.

If you’d like help taming your ROPA, please get in touch!

Related Content

• Recording your Processing Activities… Bottom Up or Top Down?
• How good is the Public Sector at recording its Processing Activities?
•