Record of Processing Activities (RoPA): what it is and how to do it

Q: My company has fewer than 250 employees — am I exempt from the RoPA?

In most cases, no. Art. 30(5) GDPR provides an exemption for organisations with fewer than 250 employees, but that exemption falls away if the processing is likely to result in a risk to the rights and freedoms of data subjects, if it is not occasional, or if it includes special categories of data (art. 9) or criminal data (art. 10). A company that manages employee payroll or a recurring customer base carries out non-occasional processing, so the exemption does not apply to it and it must keep the RoPA anyway.

The Record of Processing Activities is one of the most cited and least understood documents in the GDPR. Many companies believe it does not concern them because they have few employees, and they are almost always wrong. This guide explains what the RoPA is, who is really required to keep it, what information it must contain and what a real entry looks like, with an example row ready to adapt to your organisation.

In 15 seconds

The RoPA is the document required by art. 30 GDPR that inventories all of an organisation's data processing activities.
It binds both the controller (art. 30(1)) and the processor (art. 30(2)).
The exemption for companies with fewer than 250 employees (art. 30(5)) almost never applies: it falls away with employee data or recurring customers.
It must be kept up to date: a frozen RoPA stops describing the real company.

What is the Record of Processing Activities?

The Record of Processing Activities is the document, provided for in art. 30 GDPR, that inventories all the personal data processing activities an organisation carries out. For each processing activity it describes what data it handles, for what purpose, about which people, for how long and with what security measures. It is internal and is not published.

It is best understood as the map of your company's data. It is not a registration procedure before any authority, nor is it posted on your website. It is your own record that you keep available and that the supervisory authority may request. Its real value lies not in having it filed away, but in the fact that it forces the organisation to know precisely what it does with each piece of data.

Before 2018 there was a system for notifying data files to the Agency. The GDPR replaced it with this model of accountability: nothing is notified in advance any more, but the company must be able to demonstrate at any time that its activity is documented and under control. The RoPA is the central piece of that demonstration.

Who is required to keep the RoPA?

The RoPA binds both the controller and the processor (art. 30 GDPR). The exemption in art. 30(5) for organisations with fewer than 250 employees is far narrower than it looks: it does not apply if the processing is likely to result in a risk to the rights of data subjects, if it is not occasional, or if it includes special categories or criminal data. In practice, almost any company with employees or recurring customers is required to keep it.

Here lies the most widespread misunderstanding. It is common to hear "I have fewer than 250 employees, I don't need a RoPA". That reading is incorrect in most cases, because it ignores the three conditions that switch off the exemption in art. 30(5):

Risk to the rights and freedoms of data subjects. Many everyday processing activities entail this to a greater or lesser degree.
Non-occasional processing. This is the key. Managing employee payroll month after month, or a customer base you invoice continuously, is not occasional: it is the ordinary activity of the business.
Special categories (art. 9 GDPR) or criminal data (art. 10). Health data, trade union membership, data relating to offences, etc.

It is enough for just one of these conditions to be met for the exemption to fall away. A company that pays payroll processes its employees' data on a permanent basis; one that sells to regular customers maintains ongoing processing. In both cases the activity is not occasional and the RoPA becomes mandatory again, regardless of the number of employees. That is why, in the vast majority of real organisations, the question is not whether the RoPA is needed, but how to build it well.

What information the RoPA must include

The minimum content of the record depends on whether you act as controller or as processor. Art. 30(1) GDPR sets the content of the controller's RoPA; art. 30(2), that of the processor, which is more limited. It is not a rigid format: it is a list of fields the record must cover for each processing activity.

For the controller, art. 30(1) requires documenting, for each processing activity:

Name and contact details of the controller, of any joint controller, of the representative and of the data protection officer (DPO) where one exists.
Purposes of the processing: what the data is used for.
Categories of data subjects (customers, employees, suppliers, candidates…) and categories of personal data processed.
Categories of recipients to whom the data is or will be disclosed, including those in other countries.
International transfers to third countries or organisations, with identification of the country and of the safeguards applied.
Envisaged erasure deadlines for the different categories of data.
General description of the technical and organisational security measures under art. 32 GDPR.

The processor's RoPA (art. 30(2)) is shorter. It documents, for each controller on whose behalf it acts, the categories of processing it carries out, any international transfers and the general description of the security measures. It does not go into the purposes, because those are decided by the controller, not the processor.

Practical example: a RoPA row

The theory is easier to grasp with a concrete case. This is a RoPA entry of a controller for the most common processing activity of any company with staff: HR management. Each column corresponds to one of the fields in art. 30(1) GDPR.

Field (art. 30(1))	Content of the row — "HR management"
Controller	Example Company S.L. · Tax ID B00000000 · X Street, Burgos · rgpd@company.es
Purposes of the processing	Employment, contractual, payroll and prevention management of the relationship with employees.
Categories of data subjects	Employees on the payroll and staff in the process of leaving.
Categories of data	Identifying, contact, banking, professional and social security contribution data. Health data limited to the management of sick leave (special category, art. 9).
Categories of recipients	Spanish Social Security Treasury (TGSS), Spanish Tax Agency (AEAT), banking entity, external payroll firm.
International transfers	None envisaged.
Erasure deadline	During the employment relationship and the subsequent labour, tax and social security limitation periods.
Security measures (art. 32)	Role-based access control, device encryption, backups, staff confidentiality.

The full RoPA of a mid-sized company is a table with several rows like this one: one for each real processing activity. Typically there are entries for HR management, customers, suppliers, recruitment, video surveillance if there is any and commercial communications. The most frequent mistake is not a lack of detail, but inventing processing activities that do not exist or, conversely, forgetting one that is actually carried out.

"The RoPA is not a PDF you fill in once and file away. It is the living X-ray of what your company does with data. The day you switch software or add a supplier and the record does not reflect it, it stops being of any use."

Mario P. Talamillo · Managing Partner, Certix®

What happens if you do not keep it up to date?

An outdated RoPA describes a company that no longer exists, and that empties it of usefulness. Art. 30 requires the record to reflect the actual processing activity at all times. If you have changed software, added a supplier or opened a new purpose and the record stays the same, it no longer documents what you actually do with the data.

The practical problem with an obsolete RoPA is that it breaks the principle of accountability on which the whole GDPR rests. If the organisation cannot demonstrate what it processes and how, it loses the foundation on which the rest of its obligations are built: the information clauses, the art. 28 contracts with processors, the retention periods or the response to a rights request.

There is a knock-on effect that is easy to overlook. When a customer exercises their right of access or erasure, the RoPA is the starting point for knowing where their data is and who holds it. If the record does not reflect a piece of software or a supplier taken on months ago, that response comes out incomplete. The RoPA is not an isolated document: it is the one that holds together the coherence of everything else.

How Certix helps you keep it current

Drawing up the RoPA for the first time requires going through the entire organisation and translating its activity into well-defined processing activities. Keeping it afterwards is continuous work: every change of software, supplier or purpose should be reflected in the record. That is where a RoPA ends up becoming obsolete in practice — not out of bad faith, but because nobody reviews it when the business changes.

At Certix we draw up the Record of Processing Activities starting from a real analysis of your activity, not from a generic template. We identify the processing activities you actually carry out, document them with the content of art. 30 GDPR and connect each one to its legal basis, its retention periods and its security measures. It is the foundation on which the rest of the privacy work is built.

And we keep it current. When you take on a new tool, engage a supplier or launch a different purpose, the record is updated so that it continues to reflect the real company. You can start with our data protection self-assessment test or see how the RoPA fits within Certix's data protection services.

Frequently asked questions

My company has fewer than 250 employees — am I exempt from the RoPA?

In most cases, no. The exemption in art. 30(5) GDPR falls away if the processing is likely to result in a risk to the rights of data subjects, if it is not occasional, or if it includes special categories (art. 9) or criminal data (art. 10). A company that manages payroll or a recurring customer base carries out non-occasional processing, so the exemption does not apply and it must keep the RoPA anyway.

What exactly is the Record of Processing Activities?

It is the document required by art. 30 GDPR that inventories, processing activity by processing activity, which personal data an organisation handles, for what purpose, about which people, for how long and with what security measures. It is internal: it is not published or filed in any public register, but the supervisory authority may request it. It works as the map of the company's entire data activity.

Are the controller's RoPA and the processor's RoPA the same?

No. The controller's RoPA (art. 30(1) GDPR) describes the processing activities the company itself decides on: purposes, categories of data subjects and of data, erasure deadlines. The processor's RoPA (art. 30(2)) is shorter: it documents the categories of processing carried out on behalf of each controller that engages it, without going into its own purposes. A single company may have to keep both records.

How often does the RoPA have to be updated?

The GDPR does not set a fixed frequency, but art. 30 requires the record to reflect the actual processing activity at all times. In practice, it is reviewed whenever something relevant changes: new software, a new supplier, a new purpose, an international transfer or a new type of data. A RoPA frozen in time stops fulfilling its function.

In short

The Record of Processing Activities is the map that underpins all of a company's data protection work. The idea that small organisations are exempt is, in most cases, false: it is enough to manage employees or a recurring customer base for the exemption in art. 30(5) to stop applying. The hard part is not creating the RoPA once, but keeping it faithful to reality when the business changes. If you want to review the state of yours, the next step is an individual analysis of your activity.