Records of Processing Activities (ROPAs): Simplifying GDPR Compliance

Expert insight from a data privacy trainer and DPO

“Organisations tend to overcomplicate GDPR [General Data Protection Regulation] compliance.”

That’s what data privacy trainer and DPO (data protection officer) Andy Snow said when I asked him, in honour of the Regulation’s sixth anniversary, what organisations are still struggling with when it comes to GDPR compliance.

This seems a common theme. Louise Brooks, head of consultancy at our sister company DQM GRC, remarked that many organisations tend to see the GDPR as prescriptive, stemming from misunderstandings around how the Regulation actually works: principles-based and risk-based.

Specifically for GDPR compliance, records of processing activities, also known as ‘ROPAs’, are one compliance activity that tends to be overcomplicated.

What’s more, if you create good ROPAs, you make GDPR compliance – and, crucially, demonstrating it – significantly easier to achieve.

Andy explains further in this interview.

About Andrew Snow

Andrew ‘Andy’ Snow is a GDPR DPO with extensive public- and private-sector experience in regulatory compliance, privacy compliance framework development, and other areas relating to data protection.

He’s also an enthusiastic data privacy and cyber security trainer, consistently receiving high praise from course attendees – in particular, for his engaging delivery style and plethora of real-life examples.

Previously, we’ve interviewed him on the UK–US ‘data bridge’
(Data Privacy Framework) and a landmark ECJ (European Court
of Justice) ruling on the EU GDPR.

In this interview

Let’s start with the basics. What is a ROPA?

I see a ROPA as a fundamental tool for organisations to manage their GDPR compliance, whether in the UK or EU.

One of the responsibilities of the DPO or the appointed person [data privacy manager] is to monitor compliance – to understand the risks that the processing activity creates.

Unless you have an Article 30 ROPA, how do you even start to understand the different processing activities? Never mind the risks arising from them?

Using a ROPA – in conjunction with other tools, such as DPIAs [data protection impact assessments] – enables the organisation to have that overall picture.

Well, that answers my next question: why organisations should have ROPAs. What other benefits do ROPAs bring?

First, I want to say that within a GDPR compliance programme, ROPAs should be high up the list because they lead so well into other areas of compliance.

But their specific benefits depend on how you approach ROPAs. Though Article 30 sets out minimum requirements, in practice, these records can look very different for different organisations.

In what way?

Take the ICO template. Over the years, the number of columns [i.e. data points] on there has grown. The ICO [Information Commissioner’s Office] has been adding to it as the regulator increasingly sees a ROPA as a fundamental document within an organisation.

This benefits organisations, too.

Nobody likes spreadsheets, but they like multiple spreadsheets even less.

So, if we can put all information into one location, you’ll have a central register of all information related to data protection and privacy, you’ll make a lot of people happy and you’ll simplify GDPR compliance.

Can you give us an example of that?

Article 5(2) is a good one. That’s the GDPR’s accountability principle – you must be able to demonstrate that you’re meeting the data protection principles [also known as the data ‘processing’ principles].

By simply adding a few columns to your ROPAs for each processing activity, you can then tick off your list:

Have we limited our purposes?
Are we keeping the data up to date?
Are we processing the data securely?
Have we minimised our data collection?
Are we storing the data for no longer than needed?
Are we processing the data lawfully, fairly and transparently?

This extends into other areas too, like checking that you’re specifying these things on your privacy notices.

Note: You can learn more about the data protection principles in our free green paper.

What else can you combine Article 30 ROPAs with?

Definitely data flow maps.

A data flow map tells you what data you’re collecting, while your ROPAs will tell you which departments are using that information.

What you should then be able to see is whether all the data you’re collecting is actually being used by a department. If it turns out you’re collecting data that nobody’s using, then the data minimisation principle demands you get rid of it.

You can even use your ROPAs as a risk register – the risks different processing activities present to the rights and freedoms of data subjects.

It’s whatever you want to bring into it. This document, if used by the organisation in the right way, can cover many other aspects beyond meeting the basic Article 30 requirements.

Note: Unlike ROPAs, data flow maps aren’t an explicit GDPR requirement. However, they’re widely accepted as useful tools for achieving GDPR compliance. (And to simplify your processes, saving you time and money.)

Speaking of which, what are the Article 30 requirements? What must GDPR ROPAs contain?

It depends on whether you’re the controller or processor. Controllers must document:

Name and contact details of the data controller, and the controller’s representative and DPO [if applicable];
Name and contact details of joint controllers [if applicable];
The purposes of processing;
Categories of data subjects;
Categories of personal data;
Categories of recipients of the data;
International data transfers and their safeguards;
Retention periods; and
A general description of technical and organisational security measures [if possible].

I also recommend including a link to contracts with data processors. In turn, data processors must include in their ROPAs:

Name and contact details of the processor and any sub-processors;
Categories of processing;
International transfers and their safeguards; and
A general description of technical and organisational security measures [if possible].

Want to stay in the loop on future interviews like
this? Subscribe to our free weekly newsletter:
the Security Spotlight.

Subscribe now

What’s a practical approach to creating a ROPA?

They’re typically completed by the business line managers or their deputies. Notably, it’s not the DPO or appointed person.

However, the DPO may need to kick-start things by setting up a meeting with all business line managers and the accountable director to make a plan.

Make sure you’re realistic about timelines. The people completing this have day jobs – their revenue-generating responsibilities. So, they’re going to treat their GDPR duties as a side requirement.

What would the DPO say in this meeting?

The key thing is to give the business line managers an overview of:

What ROPAs are;
What the legal requirements are; and
How they’re going to tackle the ROPAs.

The big mistake people make when they’re new to ROPAs is to complete them by focusing on the columns, rather than the rows [representing a processing activity each]. That risks overwhelming people, because you’re collecting too many new data points at once.

Your priority is to get all your processing activities listed, covering the requirements explicitly listed in Article 30. Only after you’ve done that should you go back and think about adding more columns to have everything in one place, avoiding multiple spreadsheets. I like to think of this as a ‘one-stop shop’.

Also, if you document all your processing activities within a few months, your DPO can quickly understand them, along with the data you’re using and the risks associated with processing. If you came at it from the other direction [prioritising columns], it could take the DPO a year to understand all the risks.

Anyway, back to this meeting. To start with, the DPO should say something like: we’ll first complete columns A–K [or whatever] before we look at the rest. We’ll meet our legal requirements first.

They should then go through a few examples, completing a couple of rows so everyone can see what’s expected of them for each column. If you want consistent, helpful records, everyone needs to follow the same system.

Should the records cover all personal data processing activities within an organisation?

Legally, no. The GDPR doesn’t require you to have ROPAs if you employ fewer than 250 people – unless the processing creates a risk to the rights and freedoms of data subjects. Which can put a lot of activities within scope.

Suppose I make an appointment with a self-employed window cleaner. The window cleaner – representing a one-man business – would put my name and address in their diary. If they then lose that diary, there’s a risk to my rights and freedoms – so, this one-man business may need a ROPA.

Where the processing of PII [personally identifiable information] is involved, if breached, there’s usually a risk, so ROPAs are often required by law.

But even if not mandated, these records are very useful to have because they make the rest of GDPR compliance much easier. You can also combine them with a more general asset or risk register, further reducing the number of spreadsheets [or general documentation] you need to maintain.

How many rows would you expect to see in a ROPA?

It depends. Let’s take recruitment as an example.

Is that just one line – i.e. treated as one processing activity? Or does the organisation treat it as a group of similar processing activities, requiring multiple lines?

There are many different ways to recruit. For instance, you might:

Use an agency;
Recruit internally;
Receive hard-copy CVs; and/or
Use online portals like LinkedIn.

Those may present four processing activities. And that’s just applications!

You’re then looking at the later recruitment stages, like the different ways of contacting applicants for an interview, or the records to keep for outright rejections. Those involve different processes – different retention periods, different data destruction methods, and so on.

As such, just for recruitment, you could be looking at a dozen or more lines in your ROPAs. Equally, it could just be one line.

What’s appropriate for you depends on your needs: to what depth do you need to be tracking this information? That’s the nice thing about Article 30, and the GDPR as a whole: it’s principles-based. It’s flexible.

It’s up to your organisation to decide what level of detail you need. You’re balancing the investment [in terms of time and effort] in creating your records against the ease with which you can conduct DPIAs, risk assessments, etc. further down the line.

Earlier, you highlighted the pitfall of prioritising columns over rows. What other pitfalls are there when it comes to ROPAs?

People tend to leave them until the last minute because they’ve got day jobs.

I’m not saying they should make ROPAs a high priority, but people do need to make early starts on them. You can’t create a good ROPA on your own; you need input from others. Processing activities often involve multiple teams or departments.

Furthermore, the person creating the ROPA isn’t necessarily the expert [process owner]. That’s the person they must talk to for in-depth information on:

Who does what; and
Why, when and how it’s done.

So, make contact early. Set aside time, so you can add those rows gradually across those three months [or whatever the timeline agreed].

Finally, what are the penalties for not meeting the Article 30 ROPA requirements?

As a direct GDPR requirement, organisations can get fined [up to £8.7 million or 2% of global annual turnover] for failing to produce Article 30 records, or not having done them correctly.

But the bigger regulatory risk is not being able to demonstrate compliance with the more fundamental GDPR requirements: the data protection principles in Article 5. Multiple organisations have received fines, under the higher tier, for violating it.

Creating and maintaining your ROPAs is a good way of avoiding that – it doesn’t just demonstrate your accountability as per Article 5(2), but also offers a practical way of checking off the big GDPR requirements:

Relying on valid lawful bases for processing.
Meeting the data protection principles.
Accommodating data subjects’ rights.
And so on.

Want to simplify creating your ROPAs?

CyberComply, our SaaS platform, is designed to support the implementation and maintenance of a wide range of frameworks, including the UK and EU GDPR.

In just one tool, you can:

Effortlessly create essential documents, including GDPR Article 30 ROPAs, with pre-populated documents;
Quickly assess and manage your GDPR compliance gaps;
Easily identify, map and visualise your data flows;
Conduct DPIAs quickly in six simple steps; and
Much more!

Learn more

We hope you enjoyed this edition of our ‘Expert Insight’ series. We’ll be back soon, chatting to another expert within GRC International Group.

In the meantime, why not check out our interview with managing consultant at GRCI Law, our sister company, Loredana Tassone on six years of the GDPR?

If you’d like to get our latest interviews and resources straight to your inbox, subscribe to our free Security Spotlight newsletter. Alternatively, explore our full index of interviews here.

The post Records of Processing Activities (ROPAs): Simplifying GDPR Compliance appeared first on IT Governance UK Blog.