Beyond legal #7: You can't protect what you are not aware of

This is the 7th post in my "Beyond Legal," series where I challenge the view held by many that data protection is solely the domain of legal professionals. So far, I've explored the need to upgrade competences, understand why a data protection leader's role is complex, why some leaders need to elevated their risk game, and importantly, why engaging with your data management and data governance colleagues will be highly beneficial. In the last post I covered the 'great governance misunderstanding'.

If these posts have resonated with you, you may share my viewpoint that to really lead data protection in a company, you need to move beyond theoretical compliance. It means getting your hands dirty, understanding the operational realities of data within your company. And the absolute first, non-negotiable step on that path? Knowing what data you have, where it lives, how it moves, and who touches it. Yes, we are talking Records of Processing Activities (RoPA). And this is seen from a GDPR perspective but if you're a global player you'll need something more extensive than what Article 30 dictates, and it will make good sense to do so. Many companies have seen benefits in investing in data maps that are more dynamic and have a wider footprint across the organisation. Typically these companies have greater maturity in both data protection and data management.

But hang on, before you, or your external law firm advises you to start making that RoPA, how do you know whether something similar doesn't already exist in your company, or has key processing information residing in different repositories.

I think you should ask this question no matter what kind of tool you are thinking of investing in, and the question will be answered by following the structured approach further down this post.

The perception of RoPAs

For too long, the RoPA has been viewed as a necessary evil, or necessary burden type 'document' mandated by GDPR Article 30, often drafted in a spreadsheet and then quickly forgotten about. Or you may have invested in a automated solution that offers lots of other features. This more fancy RoPA still gets forgotten about or reluctantly updated a few times a year, or even just once a year. This perception profoundly limits its strategic value and, worse, relegates data protection to a siloed (often legal) function.

I think there's a huge opportunity to change things for the better because there is so much potential if you just involve the right competences. Your RoPA should be the nerve centre of your data protection function or office, informing so many other aspects of your work.

As I always do in these posts, I want to align competences with the SFIA skills framework. The competencies required here are less about interpreting GDPR articles and more about detailed Data Management (DATM), Business Situation Analysis (BUSA), Records Management (RMGT), Supplier Management (SUPP) and there's a fair amount of planning, follow-up and reporting so I also suggest Project Management (PRMG) competences are needed.

The symptoms of a troubled RoPA

The state of your RoPA is a good indicator of how structured and controlled you were in establishing it in the first place. If corners were cut, and the right people weren't involved at the beginning, the symptoms are usually quite obvious:

• Your RoPA is not regularly maintained and is out of date

• Responsibility for its maintenance falls solely on you and your department, reinforcing the idea that it's "just a privacy thing."

• Information within your RoPA is sometimes duplicated, often in slightly different forms, in other repositories across your company

• Governance for your RoPA is non-existent

• You do not have an operational budget allocated for the RoPA's maintenance, improvement, or integration.

• You are only using a fraction of its functionality, probably just the bare minimum for compliance.

• It is not fully integrated with key data systems in your company, making it difficult to pull real-time, accurate information.

• You can't locate the original business case because there probably wasn't one in the first place.

If any of these symptoms sound familiar, you are far from being alone, but as I wrote above, it is possible to rescue the situation. That begins with you acknowledging how things are. Yes, these are hard truths.

Foundations of a RoPA that is fit for purpose

To ensure your RoPA is fit for purpose in your company, in your business context, don't be tempted to purchase the latest tool on the market, or the tool someone in your network recommends you. Just because a tool works in company A or B, it does not mean it will work well in yours. I suggest working through these steps to avoid making costly mistakes and being stuck with the wrong tool for the years to come:

1. Gather the right competences to conduct the following steps, and gather the key stakeholders across the company. Be sure to include, as a minimum:

   • Data management

   • Records management

   • Sourcing/procurement

   • Compliance

   • Risk

   • Infosec

   • Finance

   • Enterprise architecture

   • Legal

2. Conduct a feasibility study including functional and non-functional requirements elicitation

   • If you don't have the necessary competences, get a Business Analyst onboard to help you

3. Align with your company's technology strategy, architectural standards, etc

4. Scan the market for possible solutions

5. Formulate a draft business case that sets out the different options you've considered

6. Conduct a structured vendor selection process

7. Update the business case and request approval

By completing these tasks you'll increase the likelihood that you're making the right choice, and you are justifying the needed investment. The first step is extremely important.

Be sure to understand whether the tool allows you to set relationships across various elements. This is highly relevant to how the records of processing activities are recorded and accessed, so let's get the question I hear asked so often out of the way. How detailed should a RoPA be? There is very little guidance from the data protection regulators about this and I personally find their Excel templates a waste of time, and misleading.

Establishing a useful, dynamic, and compliant RoPA requires a delicate balance. Too much detail can make it unmanageable. Too high level, and it becomes meaningless. Here’s my suggestion for how to achieve that balance, and be compliant, and in control.

The principles Purpose Limitation, Data Minimisation and Lawfulness (i.e. applying one of the six lawful bases) are your key references when determining the level of granularity. Define processing activities based on purpose of processing and be aware it's not just a simple copy/paste of your business processes.

To illustrate this, I'll provide a couple of examples.

"Employee Payroll Management" is too high level. This can be broken down as follows:

• Purpose: Calculation and disbursement of salaries and wages

  Description: To accurately calculate and pay employees their regular remuneration, including basic salary, overtime, bonuses, and commissions.

• Purpose: Statutory deductions and contributions

  Description: To accurately deduct and remit mandatory contributions to government bodies, such as income tax, national insurance/social security, and pension contributions as required by law.

There will be a few more purposes - I won't list them here to say time and space.

Another example:

"Recruitment Process" is too high level. This can be broken down applying the principles I mentioned above as follows (just a couple of examples):

• Purpose: Candidate sourcing and application management
  Description: To identify potential candidates, receive and acknowledge applications, and manage the initial pool of applicants for a specific role or general talent pipeline.

• Purpose: Candidate assessment and selection
  Description: To evaluate candidates' suitability for a position through interviews, tests, and background checks, and to make informed hiring decisions.

Also resist the temptation to specify a purpose like "Processing salary data in System A" and "Processing tax data in System B."

Going beyond Article 30

Many would question why going beyond a legal requirement is a good idea. Surely it's a waste of time and resources? As I mentioned earlier there are tremendous opportunities to get greater control of your company's processing by establishing a data map. This certainly should not be the preserve of a legal department because it's an enterprise tool encompassing data management. An effective RoPA should be part of a data map and goes deep, capturing a wealth of operational detail that GDPR only hints at:

• Data classification & categories: Beyond just identifying "personal data," specify whether it's special category data (health, biometric, etc.). Also include data by source – is it provided by the data subject, observed (e.g., website analytics), derived (e.g., credit scores), inferred (e.g., political leaning), or proxy data? This level of detail is vital for understanding risk and obligations.

• Vendors & third parties: This section is expansive, moving beyond mere names:

  • Processing Role: Are they a processor, joint controller, or independent controller?

  • Contact Info: Not just legal, but operational and technical key contacts.

  • Agreements: Links to Data Processing Agreements (DPAs) or other contracts.

  • Breach notification requirements: Specific requirements and thresholds for third parties

  • Services, assets/applications, SLAs: What services do they provide, which of your assets do they touch, and what are the performance expectations?

• Visual data lineage: Moving beyond static spreadsheets, your RoPA becomes a powerful visual tool where data flow diagrams illustrate:

  • Data across the lifecycle: Where data originates, where it goes, and its transformations.

  • Vendors: Clearly showing which third parties are involved at each stage.

  • Data subjects: Who is impacted by each flow.

  • Assets: Which technical systems or databases are used.

  • International transfers: Where data crosses jurisdictional borders.

  • Existing controls: What technical and organisational measures are in place.
    Visualisations are incredibly powerful for spotting gaps, understanding complex relationships, and communicating impact.

• Comprehensive contact information: Extend beyond vendors. Include any internal group or external individual connected with processing, incident response, or external support: third-party forensics firms, external legal services, specialist data protection and privacy experts. When a personal data breach occurs, every second counts, and knowing exactly who to call, and what their role is, is invaluable.

• Privacy notice repository: Maintain an overview of all privacy notices, including version control, linked directly to the relevant processing activities. Ideally, it should also be linked to your consent record management tool for a holistic view of transparency and choice (when consent as a lawful base is applicable).

• Breach notification requirements: Beyond general regulations, detail specific sector requirements, variations across jurisdictions (e.g., GDPR vs. APEC countries, or US states), and requirements to notify other parties (controllers, processors). Document varying data subject thresholds for notification. This proactive planning is key for responding to personal data breaches.

• Assets: For each key asset (database, application, system) involved: state its purpose, what business function it supports, and whether it's in-house or vendor-managed.

• Control catalogue: Document controls deployed for each activity:

  • Responsibilities & ownership: Who owns the control, who is responsible for its operation.

  • Types of controls: Technical, organisational, physical.

  • Status & effectiveness: Is it implemented? How effective is it?

• RoPA service continuity: What if your RoPA itself is compromised or inaccessible? This critical repository needs its own continuity plan. If your internal systems are paralysed, how will you access this information? The same consideration applies to your data breach response plan – it needs to be accessible even in a crisis.

Business benefits of a "Strategic RoPA"

The true value of a fit for purpose RoPA isn't just about avoiding fines. It's about enhancing your business. This is where you, as a data protection leader, must "sell" the value to the rest of the company, moving beyond the perception that it's "only for legal." I believe there are many opportunities that should feature in your benefits case:

• Risk identification: there will be strong visibility into your company's processing operations, enabling proactive identification and mitigation of data protection and security risks.

• Understand impact of change: on a process and technical level see who and what will be affected by a proposed change, simplifying communication to various parties across the company

• Reveal redundancy: Identify redundant elements that could be decommissioned, leading to cost savings in systems, storage, and effort.

• Spot security vulnerabilities: Visual data flows and asset inventories highlight potential security weak points.

• Ensure business alignment: Assess if you have the right elements in place to meet business needs and achieve the right balance for strategic goals and objectives.

• Common language: Establish a common processing language across the company, accommodating jurisdictional variations (e.g., controller/processor in EU, business/service provider in California). This enables clarity and reduces misunderstandings.

Avoid a silo RoPA

The real danger here is when a data protection leader (perhaps inadvertently) downplays the importance of this operational data, reducing data protection to a standalone, siloed function. This can happen by insisting on standalone, often expensive, "privacy management tools" before adequately understanding existing data management capabilities and integrating with them (see my suggested steps outlined above).

This "privacy tool first" approach, without a thorough understanding of your existing data landscape and the capabilities of your data management colleagues, often leads to isolation. Data protection becomes a niche concern, separate from the broader business and IT strategy, resulting in many of the "troubled RoPA" symptoms I mentioned earlier. Data has intrinsic value, and downplaying its importance by siloing its protection is detrimental to the entire business.

Building bridges

Establishing the RoPA, or building its required functionality into existing tools, gives you the opportunity to build and maintain relationships across your company, so it is not just a compliance exercise. It's also a tremendous opportunity for you to educate your colleagues in relevant and contextual data protection concepts and principles.

A few years ago, I worked with a client where their data protection leader had gamified the establishment and population of their RoPA. She had made it into a game with lots of interaction and competition between the different departments that were in scope. This really helped her get the organisation interested and onboard. In my view that's a good example of innovation in data protection when you bring people in with a creative mindset.

By co-creating a visual, and operationally relevant view of data, you'll break down silos. You'll move data protection from a perceived constraint to an enabler of business value and strategic growth.

Without it, you’re driving blind, always on your back foot, and not in control.

Purpose and Means is a niche data protection and GRC consultancy based in Copenhagen but operating globally. We work with global corporations providing services with flexibility and a slightly different approach to the larger consultancies. We have the agility to adjust and change as your plans change. Take a look at some of our client cases to get sense of what we do.

We are experienced in working with data protection leaders and their teams in addressing troubled projects, programmes and functions. Feel free to book a call if you wish to hear more about how we can help you improve your work.