Beyond Legal #14: Does your RoPA really show how your company processes personal data? (Why you need business analysis skills)

If you have spent the last few years building a Record of Processing Activities (RoPA), you know it is a monumental task. Gathering information from across your company, categorising it, and getting it signed off is a significant achievement in governance. It creates a necessary inventory of obligations.

But as we look at the "Processing activities" box on the left side of my data protection ecosystem diagram below, ask yourself: does your RoPA show how the business actually processes personal data?

A legal lens sees that box as a list of liabilities to be managed. A data protection leader with Business Analysis skills, or with access to business analysis competences in the company, sees it differently: they see a dynamic, complex system of user journeys and value streams.

To move from "compliant on paper" to "living and breathing in practice," a logical add-on for a Data Protection Leader is to embrace the tools and techniques of a Business Analyst.

The standard approach to the RoPA is the questionnaire. It is an efficient way to cast a wide net, asking stakeholders about "Legal Basis," "Retention Periods," and "Data Subjects."

But, as we well know, most business stakeholders are not legal experts. When they fill out these spreadsheets, they aren't trying to hide things - they are simply trying to interpret legal terminology through the lens of their daily grind. They may share information with you about the official process, but they often leave out the small, necessary workarounds they use to get the job done because they don't realise those workarounds are data processing activities.

This is a gap in translation. And it's where Business Analysis comes in.

Business Analysis is underrated

I often say that among the best courses I have ever done in my career was my Business Systems Analysis Diploma from the BCS (British Computer Society) in the UK over 20 years ago. It included attending a series of certification courses in Edinburgh, Manchester, Bristol and London and studying for a long series of exams, and then finally some interviews at BCS, but boy did I learn a lot, coming away with a huge backpack of tools and techniques that I use to this day.

While it wasn't a data protection course, it gave me the foundation for my understanding of how businesses actually work. It taught me that a business isn't just a collection of contracts and policies, it is a living ecosystem of processes designed to deliver value.

In the SFIA 9 framework, Business Analysis falls under Business Situation Analysis (BUSA) and is described as the ability to:

"Investigating business situations to define recommendations for improvement action."

SFIA suggest the tasks include:

Activities may include, but are not limited to:

• Planning for business situation analysis

• Establishing the investigative approach

• Engaging with relevant stakeholders

• Reviewing the strategic context, including the organisation’s vision, mission, objectives, strategy and tactics and external business environment

• Defining problems and analysing root causes

• Identifying potential changes to address problems or to take advantage of opportunities

• Gaining agreement to conclusions and recommendations.

Incidentally, if you have been reading this "Beyond Legal" series of blog posts you may remember this skill was also highlighted in an early post covering Why every data protection and AI governance leader needs SIRA competences in their toolkit.

This skill is the missing link in the centre of my ecosystem diagram - the red text labeled "Aligned." It is the bridge between the Data Protection Strategy and the Business Purpose.

Here is how I see that by applying a business analysis mindset to your work elevates your data protection programme:

1. Elicitation

Legal professionals often have to interrogate to establish facts. Business Analysts, use elicitation to understand flows. It is a subtle but powerful shift in tone.

Instead of asking, "List all data categories used in the event registration system," a business analyst may ask "Walk me through the delegate's experience. When they sign up, what happens next? Oh, you ask about dietary needs? That’s great service. How do we make sure the catering team gets that info without seeing everyone's home addresses or potential religious beliefs?"

By being curious about the business purpose, you uncover the data protection risks (such as special categories of personal data) naturally. You become a valued colleague in solving a business problem (catering logistics) rather than a "necessary evil" asking for a form to be filled in.

2. "As-Is" and "To-Be"

Documenting the journey from "As-is" to "To-be" is a core domain of the Business Analyst.

Employees often create workarounds (just look at the contributing factors in some personal data breaches), using personal emails, local spreadsheets, or unsanctioned tools, not because they want to be non-compliant, but because they are trying to be efficient.

A Business Analyst doesn't just ban these practices. They map the "As-Is" reality, acknowledge the friction the employee is trying to solve, and design a "To-Be" process that is both compliant and efficient.

You don't just close a gap - you improve the employee experience. That is how you help establish the "Motivated management & employees" shown at the bottom of my ecosystem diagram.

3. Requirements Definition (REQM)

Once you understand the flow, you need to help the technical teams build the controls. This brings us to another key skill: Requirements Definition and Management (REQM).

Engineers and Product Owners demand clear requirements. They struggle with vague principles. When we tell them to "implement Data Protection by Design and by Default," we aren't giving them a spec.

Using REQM skills, you act as the translator:

• Data Protection Principle: "Data Minimisation."

• Functional Requirement: "The 'Export to CSV' function must default to 'Summary View' (5 fields). The 'Full Data Dump' option must be disabled for all users except System Admins."

Call to action

You have already built the foundation with your policies and your RoPA. Now, consider upgrading your toolkit to bring your data protection work to life.

• Host "Discovery Sessions": Instead of sending a reminder to update the RoPA, ask a department head for a 30-minute "process walkthrough" of their critical revenue stream.

• Learn the basics of diagramming: Learning to draw a simple data flow diagram is one of the highest ROI skills a data protection leader can acquire. It turns text-heavy policies into visual logic.

• Validate, don't just verify: Use your skills to validate that the process delivers value and compliance.

When you understand the business process as well as the business owner does, you are no longer just protecting the data; you are protecting the value it creates.

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.