The record of processing activities is the least glamorous document in privacy, and the one everything else depends on.
You cannot answer a data subject access request without knowing which systems hold that person's data. You cannot set a retention schedule without knowing what you hold. You cannot assess a risk you have not inventoried. Every privacy programme that stalls, stalls here.
What Article 30 actually requires
A ROPA is a written record of each processing activity. For a controller it must include:
- the name and contact details of the controller (and DPO, where one exists)
- the purposes of the processing
- a description of the categories of data subject and categories of personal data
- the categories of recipient the data is disclosed to, including recipients in third countries
- transfers to third countries, and the safeguards relied on
- the retention period, where possible
- a general description of the technical and organisational security measures
In practice most organisations also record the legal basis for each activity — which Article 30 does not strictly demand, but which you must be able to demonstrate under Article 5, and which is the first thing a regulator asks about.
The 250-employee threshold is not the exemption people think it is
Article 30(5) says the obligation does not apply to organisations with fewer than 250 employees — unless the processing:
- is likely to result in a risk to the rights and freedoms of data subjects, or
- is not occasional, or
- includes special-category data or criminal conviction data
Read that second condition again. Not occasional.
If you process customer data as a routine part of running your business — which is to say, if you have customers — your processing is not occasional. The exemption is designed for the corner shop that keeps a supplier list, not for a 40-person SaaS company with a CRM.
Most companies that believe they are exempt are not.
Why spreadsheets fail
Almost every ROPA starts life as a spreadsheet, and almost every one of them is wrong within six months.
Not because spreadsheets are bad, but because a ROPA is a living record of reality, and a spreadsheet is a snapshot of one afternoon. The moment someone buys a new analytics tool, adds a pixel through the tag manager, signs a new processor, or launches a feature that collects a new field, the spreadsheet is out of date — and nobody updates it, because updating it is nobody's job at the moment the change happens.
The gap widens quietly until the day it matters: an audit, a breach, a security review, or a DSAR you cannot fulfil because the data is in a system that is not on the list.
A stale ROPA is worse than no ROPA. It gives you false confidence, and it demonstrates to a regulator that you had a process and did not follow it.
What good looks like
A ROPA that survives contact with reality has three properties.
It is tied to the systems, not just to a document. When a new processor is added, the record is updated as part of that change — not in an annual review six months later.
Every activity has a named owner. Not "the compliance team." The person in the business who actually understands why that processing happens and can tell you when it stops.
It maps to controls and to risk. A record that says what you do without linking to how it is protected and what could go wrong is an inventory, not a compliance artefact.
Where to start
Start with the systems, not the processes. Ask what tools the company pays for, what data goes into each, and who owns them. Finance's vendor list is usually a more honest inventory of your data flows than anything the compliance team has.
Then, for each one: what personal data, whose, why, on what basis, shared with whom, kept how long.
It is tedious the first time. It is the foundation for everything after it — which is why keeping the ROPA live, rather than rebuilding it annually, is the highest-leverage thing a small privacy programme can do.