Resources

What is a ROPA, and who needs one?

A Record of Processing Activities is the written inventory of how your organisation uses personal data, required by Article 30 of the UK GDPR. For each activity (payroll, recruitment, marketing, customer support, CCTV) it records the purpose, the categories of people and data involved, who the data is shared with, any transfers out of the UK, how long the data is kept, and a general description of the security measures protecting it.

Controllers and processors both need one, in their respective forms. There is no prescribed template: a spreadsheet can technically satisfy the article. What the law does prescribe is substance. The record must be in writing, must be made available to the ICO on request, and must reflect your processing as it currently is, not as it was when the document was written.

The ROPA tends to come first among compliance documents for a practical reason: every other assessment (DPIAs, transfer assessments, legitimate interests assessments) starts from the same facts the ROPA captures. An organisation that cannot produce its ROPA usually cannot produce the rest either.

Data mapping and the ROPA: what is the difference?

The two are often treated as interchangeable, and they are not. The cleanest way to separate them: the ROPA is a legal artefact, and the data map is a working method. Article 30 of the UK GDPR requires the ROPA, prescribes its minimum contents, and entitles the ICO to see it on request. Data mapping appears nowhere in the legislation. It is the exercise of tracing how personal data actually moves: where it enters the organisation, which systems hold it, who it is shared with, and where it crosses borders.

They describe the same underlying reality from different angles. The map is the operational view, organised around systems and flows, the view an engineer or an incident responder needs. The ROPA is the regulatory view, organised around processing activities and their purposes, the view a regulator expects. Neither substitutes for the other: a map with no ROPA leaves you without the statutory record, and a ROPA written without mapping is guesswork in a formal layout, usually exposed the first time someone checks a real system against it.

In practice the order is settled: map first, record second. Mapping is how you discover what the organisation actually does with personal data; the ROPA is how you evidence it. Then each earns its keep at different moments. When a regulator, customer, or auditor asks how you handle personal data, you produce the ROPA. When a breach needs scoping, a subject access request needs locating, or a new vendor needs assessing, you reach for the map, because those jobs are about where data physically lives and moves, not about the legal description of why.

The classic failure is maintaining them as two separate documents owned by two different people. They drift, and within a year the map shows a flow the ROPA never mentions, or the ROPA lists an activity no system can account for. A contradiction between them is worse than a gap, because it is written evidence that the organisation's own records cannot agree on what it does. The fix is structural: keep one set of facts and derive both views from it, so a change made once appears in both.

When is a DPIA legally required?

A Data Protection Impact Assessment is required by Article 35 of the UK GDPR before any processing that is likely to result in a high risk to individuals. The law gives examples: systematic and extensive profiling that significantly affects people, large-scale processing of special category data, and systematic monitoring of publicly accessible areas at scale. The ICO publishes a longer list of operations that require one, including uses of innovative technology and large-scale biometric data.

The assessment must describe the processing and its purposes, evaluate its necessity and proportionality, identify the risks to the people whose data is involved, and set out the measures that address those risks. If high risk remains after mitigation, Article 36 requires consulting the ICO before going ahead.

Two things catch organisations out. The DPIA must happen before the processing starts, so it cannot be back-filled cleanly once a project is live. And deciding that no DPIA was needed is itself a judgement you should be able to evidence: concluding the processing was not high risk is an assessment, whether or not it was written down.

The 250-employee exemption, and why it rarely applies

Article 30(5) exempts organisations with fewer than 250 employees from keeping full records, and it is widely misread as a small-business pass. The exemption has three carve-outs: it does not apply where processing is more than occasional, where it includes special category data, or where it is likely to risk people's rights and freedoms.

The first two carve-outs do most of the work. Any employer processes staff data continuously, and HR files routinely contain health information: sick notes, occupational health referrals, accommodation requests. That is regular processing of special category data, which means records are required for those activities regardless of headcount.

The safe reading, and the one the ICO's guidance points to, is that the exemption removes the duty only for genuinely occasional processing, which for a functioning business is a small slice of what it does. Most small organisations are not exempt; they are simply undocumented.

What "kept up to date" actually means

Compliance records describe the present tense. A ROPA is accurate on the day it is finished and starts decaying immediately: a new analytics tool, a switched payroll provider, a marketing campaign using data in a new way, a retention period nobody revisits. None of these feel like compliance events, and none of them prompt anyone to open the document.

That decay matters because documentation is how compliance is demonstrated under the accountability principle. A record that contradicts what the organisation actually does is worse than informal knowledge; it is written evidence that the picture being shown to the regulator is wrong.

The fix is structural rather than heroic: treat each record as a maintained artefact with an owner, link documents to the facts they share so a change in one place surfaces everywhere it matters, and review on a schedule rather than on panic. Organisations that do this find audits become retrieval exercises instead of reconstruction projects.