A Record of Processing Activities (ROPA) should be more than the written record required by Article 30 of the General Data Protection Regulation (GDPR). Done well, it is the authoritative map of how an organisation uses personal data. For a controller, it records why personal data is used, whose data and which categories are involved, who receives it, whether it leaves the European Economic Area (EEA), how long it is kept and, in general terms, how it is protected. A processor’s record is narrower, describing the processing carried out on behalf of each controller it serves. Both records must be available to the relevant supervisory authority on request, but a well-designed ROPA also supports breach response, due diligence, transparency, and day-to-day privacy governance.
Most organisations have a ROPA in some form, with many built in 2018 when the GDPR came into effect. Far fewer have one that is up to date and readily available for an inspection by a supervisory authority, useful when scoping a data breach, or suitable for sharing with a client conducting vendor due diligence. The difference between a merely compliant ROPA and a practical one rarely lies in the collection template; it lies in whether the record is current and whether the activities described reflect processing in practice. Maintaining a complete and accurate ROPA is therefore not only a statutory requirement but a critical part of an effective data-processing ecosystem. In June 2026, following an inquiry into a ransomware attack detected at Midlands Regional Hospital Tullamore in November 20181, the Irish DPC found that the HSE had infringed Article 30 by failing to maintain a complete and compliant ROPA at the time of the breach. The decision illustrates that supervisory authorities may scrutinise a ROPA as part of a wider inquiry into an incident or other compliance failure. When that happens, the record must reflect the processing actually taking place and not merely the organisation’s documented or theoretical processing activities.
Creating a ROPA and maintaining its accuracy are vastly different undertakings. Creation is a defined project with a scope, timetable, and end date. Accuracy is an ongoing operating discipline, tested whenever a system is procured, a contract is renewed, a product is launched or a team is reorganised. Organisations that treat the ROPA solely as a one-off project may produce an accurate record at approval, but it will become outdated as systems, suppliers, processes, and organisational responsibilities change unless updates are embedded in ongoing business workflows.
Pembroke Privacy recommends a nested structure that mirrors how the organisation is run, moving from department to business process to processing activity, with named owners at each level. The initial build should draw on existing documentation and be validated by the people who perform the work. Maintenance should then be embedded in workflows the organisation already operates such as procurement, change management, project initiation, DPIA screening, strategy changes, team reorganisations, and contract renewals so that updates are small, frequent, and evidenced as a by-product of decisions already being made. Risk-tiered owner attestation and independent assurance complete the model, providing confidence that the record reflects reality rather than merely showing that every field has been completed.
The practical challenge is not simply to create a ROPA, but to keep it proportionate, accurate and useful. That requires a clear distinction between Article 30 requirements, obligations arising elsewhere under the GDPR, regulatory guidance and recommended governance practice. Our white paper examines those distinctions in detail, compares controller and processor obligations, explains how to choose an appropriate level of detail, and provides practical approaches to structure, maintenance and quality assurance, including the principal differences under the UK GDPR.