Recording your Processing Activities . . . Bottom Up or Top Down ?

…Or why Castlebridge take an Enterprise Ontology approach to ROPAs.

One of the documentation requirements that organisations have been getting their heads around since GDPR came in is the “Register of Processing Activities” or “ROPA” required in Article 30.

Back in 2017 when some of our clients were first looking into making sure they had this new “register of processing activities”, one of the first things we did was look at the documentation they already had to see if it fit the requirements. A very common first response was to take detailed retention policies and data inventories already in place and ask, “can make a ROPA from this”?

The answer, we quickly found out, was “that’s a really good way to get bogged down in the detail of all the data and documents you have and still not know what your processing activities are”. If you try to create a ROPA from the bottom up, starting with a list of all the data elements you have and trying to put a structure on it, it’s very easy to get lost in the weeds.

Essentially, you are starting from the bottom-up with the following approach:

Taking an inventory of all your data . . .

• Lets scan all our databases . . . (what about personal computers?) to see what data sits where… “Here’s all the data we have”
• What is it?
• Okay, we have a whole lot of data in all of these places… now we have to classify it and create a classification schema.
• Who should be accessing it? (You can’t answer this if you don’t know what business processes it is collected and used for.)
• What are the legal bases for processing it? (You can’t answer this if you don’t know what business processes the data is collected for.)
• What security controls are required? (You can determine some rules for storage, but what about security controls for access and disclosure? Have you determined who should be using the data for what purposes yet? )
• What retention? (You can’t answer this question if you don’t know what business proceses the data is required for.)
• …
• But . . . Which business processes use this?”

You may see how trying to answer these questions without a clear understanding of the activities – the business processes – the data elements you’ve inventoried are collected and used for might get a bit frustrating.

The key thing to remember is, what GDPR requires is a Register of Processing Activities.

GDPR requires that Data Controllers maintain a record of processing activities under their responsibility, with information as to the “W” questions or “communication questions” around that data: Who the controller is (and how to contact them and their DPO), the purposes for processing (Why), categories of data and data subject (What and Who), categories of recipient (Who), details as to any transfers to third countries (Where), retention periods (When), and a general description of how they are keeping it secure.

“ Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility…”

The key word to “focus on here is “activities. GDPR requires a register of “processing activities” – the things the organization does with the data, not just a register of the data itself. Activities, are the organisation’s business processes.

Compiling a ROPA from scratch can be a formidable effort, and there are a number of vendors out there offering tools to help automate the process. I just sat in on a webinar from a vendor describing one of these tools recently. Like a number of other tools advertised as helping you to “automate your ROPA”, it started with data discovery. Data Discovery gives you a data inventory.

“Here’s all the data you have. We can classify it for you….”

You can infer some of your activities from seeing what data you have (the string of numbers that conforms to a credit card number and attached to billing address information is most likely used for processing payments), but with all this data identified and classified, you will still need to identify and record the business processes that the data is used for.

To be clear, I’m not denigrating the value of having a data inventory. It’s extremely important for compliance to know what personal data you actually have. It’s extremely valuable to your organization to know what organizational data you have, where it sits, how much of it is duplicated, and how much of it is “stale” sitting there unused and costing your organization in storage, deteriorating in timeliness and other quality dimensions, and becoming an increasing organizational risk.

Data Discovery can be a very useful and powerful tool to help you know what data you have in your system. Knowing where the data sits is very important to make sure you can put your hands on it when you need to respond to a subject access request, when you are auditing your security controls to make sure the data is appropriately protected. When you have identified where data is, you can identify what data is somewhere that it shouldn’t be . . . if you know that it shouldn’t be there. This kind of tool will likely be very good to identify “orphaned” data, that is being stored on systems without a clear purpose or owner.

You may find one of the tools that scan your systems to help create and maintain a data inventory extremely useful. But, no matter what tool you are using, it’s important to understand its purposes, its strengths, and its limits. A data inventory is a comprehensive and structured catalogue of all the data you have in your systems. It is not a register of processing activities.

So what’s the best way to quickly build up a Register of Processing Activities?

At Castlebridge, we take an Enterprise Ontology approach. We recommend looking from the top down. Start from a strategic understanding of the organization’s main goals and main process areas. From there, you can determine key business processes using personal data, and drill down into more detail as you go. Castlebridge use the Zachman Framework to help focus information gathering at different levels.

To take a “top-down” approach, you start with your purpose for having and using data, build out a broad understanding of the organization’s process areas, and identify the activities or business processes using personal data for each area. This frames the questions that you then need to ask for each process.

• Here our main business areas.
• What are the main things we do with personal data in that business area? (What are our core business processes involving personal data? . . . what activities are done?)
• Take a process and build it out the “W” questions for it…
  • What is the purpose for processing? (Why does this process exist? What is the legal basis for this processing activity?)
  • Who is data being processed on? (Categories of Data Subject)
  • What data do you use for this? (What categories of data are you processing? Do you have special category data? Data relating to criminal offenses?)
  • Where is it processed and stored? (What security controls do you have? Does the data get sent to any recipients?)
  • Who do you share the data with?
  • How long do you keep the data? (When must we dispose of it? What is our retention policy for this data?)

The Zachman Framework is an Enterprise Architecture framework which provides a formal and highly structured way of viewing and defining an enterprise. It sets out a matrix of the communications questions at six levels of perspective in the organization from a high “executive” level that helps you to determine scope and context, down through the actual stakeholder experience of the thing as it exists. If your organization has clear and effective communication around data and you have built your enterprise architecture out in a sustainable way, you should have the artifacts described at each of these levels.

Looking at the Zachman Framework, bottom-up discovery and classification of data then trying to create a ROPA from that inventory by trying to figure out what process it belongs to would be working from the “Enterprise” or “actual instance” level of the “What” real world thing as it exists, to try to determine the Executive and Business Manager levels of the “How”, the process identification and Definition.

If you adapt the Zachman Framework as a focus for populating your ROPA, you to start at a high “Executive” level and drill down into the detail as necessary. As you build this out iteratively, you will have documented the key information required for a Register of Processing Activities. When you identify higher risk processes, you will want to go into greater detail.

You will want to make sure that the Enterprise levels “real world thing as it is used” and the “real world process as it is run” match the enterprise level strategic goals, rules, and relational models . . . that your understanding and documentation of what the organization does with data meets reality. Data Discovery and Inventory tools that identify all the data you have in your systems can be very helpful for this. Automation tools can help you enforce retention periods, identifying and scoring “stale data” which is still stored by the organization but doesn’t have related process and is costing the organization in storage costs and compliance risks.

But automation tools are less helpful when it comes to understanding processing purpose and what the help you to determine the rules that require enforcing.

How Can We Help?

Castlebridge helps organisations not just by creating documents for compliance (like a ROPA) but to think about their data as a critical asset that has to be governed well to mitigate and manage data-related risks. This goes beyond just putting in the frameworks,  tick-box templates and a shiny software, and it includes education and training of staff at all levels in fundamentals of data and data management.

If you aren’t sure about your needs, you can book an Advisory Clinic call with our team for a 1 hour quick consultation and diagnosis.

Upcoming Courses

Register of Processing Activities Theory and Practice (2 half-days remote workshop) – 29th March & 5th April