How to Build an Accurate Record of Processing Activities

A Record of Processing Activities (RoPA) is an important part of privacy management. It helps an organisation understand what personal data it collects, why it uses it, where it is stored, who can access it, and how long it is kept.

The goal is not just to create a document. The goal is to create a record that matches what actually happens inside the organisation.

Why the Usual Approach Often Fails

A common method is to send a template to department heads and ask them to list their processing activities.

The problem is that the information received is often incomplete.

People do not always think about their daily work as "processing personal data."

For example, a marketing manager may think:

"I am sending an email campaign."

They may not immediately think about the personal data involved, the legal basis for using it, where the data came from, or how long it should be retained.

As a result, the final register may include the obvious systems but miss things such as:

• Spreadsheets stored on employees' computers

• Software purchased directly by a department

• Online tools paid for using company cards

• Recruitment information stored in shared or individual inboxes

• Other systems that IT may not know about

Start With Systems and Data

Instead of asking people to remember every activity they perform, start by identifying the systems and data used across the organisation.

Step 1: Identify All Systems

Create an inventory of all:

• Applications

• Databases

• Software platforms

• Cloud services

• File repositories

• Shared drives

• Other tools used by employees

Do not limit this list to systems purchased by IT.

Look at expense records, Single Sign-On logs, procurement records and discussions with employees to identify tools that departments may have adopted independently.

Step 2: Identify Where Personal Data Exists

For each system, determine whether it contains personal data.

This may include:

• Names and contact details

• Identification numbers

• Employee information

• Financial information

• Health information

• Biometric information

• Location information

• Any information that could identify a person when combined with other data

Step 3: Identify the Activities Supported by Each System

Once you know where personal data exists, identify what the organisation does with that data.

For example, a recruitment platform may support:

• Collecting candidate information

• Reviewing applications

• Shortlisting candidates

• Communicating with applicants

• Storing candidate records

This approach works better because you are starting with where the data actually exists, rather than relying entirely on people to remember every processing activity.

Step 4: Speak With the Departments

Once you have identified the systems and activities, speak with the relevant departments.

Instead of giving them a blank template, show them what you have already found and ask:

"Is there anything missing?"

Having a concrete list makes it easier for people to identify gaps.

What Should Be Recorded for Each Activity?

For every processing activity, record key information such as:

• Purpose: Why is the personal data being used?

• Role: Is the organisation acting as a controller or processor?

• Data subjects: Whose data is involved?

• Personal data: What types of personal data are being processed?

• Special categories: Are any sensitive or special categories involved?

• Lawful basis: What is the legal basis for the processing?

• Source: Where does the data come from?

• Recipients: Who receives or has access to the data?

• Processors: Which third parties process the data?

• Transfers: Is data transferred to another country or region?

• Transfer basis: What legal mechanism supports the transfer?

• Retention: How long is the data kept?

• Systems: Where is the data stored or processed?

• Owner: Who is responsible for maintaining the information?

Areas That Are Often Missed

Some processing activities are regularly overlooked when organisations create their RoPA.

Employee and Candidate Data

Organisations often focus heavily on customer data and forget about HR.

Employee and candidate information can contain highly sensitive information and should be included in the register.

CCTV and Access Control

CCTV footage and access-control records contain personal data.

These activities are sometimes overlooked and may not appear in the privacy register or related notices.

Recruitment Data

CVs and candidate information are often stored in email inboxes or shared folders for much longer than necessary.

The organisation should understand why the information is being retained and how long it should be kept.

Marketing Lists

Older marketing databases can be difficult to manage.

Organisations may have lists that were created or purchased years ago without properly documenting the source or legal basis for using the information.

Backups

Deleting information from a live system does not necessarily mean it has disappeared from backups.

The organisation should consider how personal data is retained in backups and document its approach, such as a defined rolling backup cycle.

Test Environments

Production data is sometimes copied into testing environments.

When personal data is used for testing, it is still being processed and should be considered in the privacy register.

Analytics and Tracking

Marketing and analytics tools may collect personal information or tracking data.

These tools are sometimes introduced without privacy teams being involved and may also involve international data transfers.

Tools Purchased by Departments

Software purchased directly by individual departments is one of the common reasons processing activities are missed.

The privacy register should include these tools even if they were not purchased or managed by the IT department.

How to Keep the Register Accurate

A RoPA may be accurate when it is first completed, but it can quickly become outdated as the organisation changes.

The best approach is to connect the RoPA with existing business processes.

For example:

• Procurement: New software should not be approved without checking whether a RoPA entry is required.

• New projects: Project initiation should include a privacy assessment where relevant.

• Employee onboarding and offboarding: Changes in access should be reflected where necessary.

• New vendors: Third-party processing should be reviewed before approval.

• Regular reviews: The register should be reviewed at planned intervals.

Even when there are no changes, record that the review was completed.

A Simple Test for a Good RoPA

Choose one real or hypothetical person from your data subject categories.

For example, choose a customer, employee or candidate.

Then use only the RoPA to identify every place where that person's personal data could exist.

If you can create a complete list, your register is providing a useful foundation for privacy management and data subject rights requests.

If you know that the person's data exists somewhere that is not listed in the register, you have identified a gap.

That same gap could become a problem when the organisation receives an actual data subject request.

Common Weaknesses to Look For

A RoPA may have gaps if:

1. It relies only on department self-reporting.

2. Unregistered systems and tools are missing.

3. Employee and candidate data is not included.

4. The organisation's role is not clearly recorded for each activity.

5. The lawful basis is assumed rather than properly determined.

6. Retention periods are documented but not actually implemented.

7. Processors are listed, but contracts or sub-processors are not properly tracked.

8. No owner is assigned to maintain each entry.

9. The register is never reviewed after the initial exercise.

The Key Takeaway

A good RoPA is more than a compliance spreadsheet.

It should provide a realistic picture of how personal data moves through the organisation.

Starting with systems and data, validating the information with departments, assigning clear ownership, and regularly reviewing the register can help organisations build a RoPA that supports privacy management in practice.