How to Create a Record of Processing Activities (RoPA)

You create a Record of Processing Activities (RoPA) by working through a short, repeatable sequence: identify your systems and data sources, identify each processing activity and its purpose, map the data, document the lawful basis, retention and security measures, record the controller or processor role, have a named person review and approve each record, and then maintain it as the business changes. That is the whole method in one sentence — the rest of this guide walks each of the seven steps in turn, with the GDPR Article 30 fields each one produces. The first draft is the work; keeping the register current is the discipline that makes it audit-ready.

How to create a RoPA: the seven steps

A RoPA is the register that Article 30 of the GDPR requires every controller, and most processors, to keep. Creating one is a procedure rather than a single document edit: you locate the data, describe what you do with it, record the legally required detail, and then keep the record true over time. The seven steps below are the generic method — they apply to any organisation regardless of the tools used, and they are mirrored in the structured guidance from the RoPA requirements guide for Ireland and the UK.

Before you start, a point that saves rework later: a RoPA is a legal obligation, not a documentation nicety. Article 30 of the EU GDPR (applied in Ireland through the Data Protection Act 2018) and of the UK GDPR requires the record, and Article 5(2) accountability means you must be able to produce it — current and complete — on request from the Data Protection Commission (DPC) or the Information Commissioner's Office (ICO). The often-assumed exemption for organisations under 250 employees (Article 30(5)) rarely applies in full: it falls away the moment processing is non-occasional — which payroll, customer management and marketing all are — or touches special-category or criminal-offence data. In practice, almost every organisation has to build one, which is why a repeatable method matters more than a one-off effort.

1. Identify your systems and data sources.List every system, application, database and manual file where personal data lives — HR and payroll, the CRM, marketing platforms, finance tools, shared drives and paper records. You cannot record a processing activity you have not located, so this inventory is the foundation of everything that follows.
2. Identify each processing activity and its purpose.Group the data into distinct activities — recruitment, payroll, customer support, direct marketing — and state the specific purpose of each. Article 30 is organised by activity and purpose, not by system: one system can feed several activities, and one activity can span several systems.
3. Map the data — categories, data subjects, recipients and transfers. For each activity, record the categories of personal data and of data subjects, the recipients (or categories of recipient) who receive the data, and any transfers to third countries with the safeguard relied on. Flag special-category and criminal-offence data explicitly, because it carries extra obligations.
4. Document lawful basis, retention and Article 32 security measures.Record the Article 6 lawful basis (and the Article 9 condition for special-category data), the envisaged retention period or the criteria used to set it, and a general description of the technical and organisational security measures under Article 32. This is what turns an inventory into an accountability record.
5. Record the controller vs processor role and legal entity.For each activity, state whether you act as controller, joint controller or processor, and which legal entity is responsible. Article 30(1) requires a controller record and Article 30(2) a parallel processor record with its own fields, so the role decides which fields apply.
6. Review and approve — a named person signs off. A named accountable person, typically the Data Protection Officer or privacy lead, reviews each record for completeness and accuracy and formally approves it before it becomes part of the register. This human approval step is not optional: software may draft or extract the content, but a person must check it and sign off, and nothing publishes itself.
7. Maintain — re-review when systems, suppliers or transfers change. Treat the RoPA as a living record. Re-review the affected entries whenever a system, supplier, purpose or international transfer changes, and run a periodic review of the whole register so it stays current and audit-ready rather than drifting out of date between annual checks.

What information goes in each step?

Each completed Article 30 entry carries a defined set of fields, and the seven steps populate them in order. By the time you reach approval, a single record should hold: the name and purpose of the activity; the categories of data subjects and of personal data; the recipients, including any in third countries, with the transfer safeguard; the lawful basis and any special-category condition; the envisaged retention period; a general description of the Article 32 security measures; and the controller or processor role with the responsible legal entity.

A common mistake is to treat the register as a system inventory — one row per application — rather than as an activity inventory. The GDPR is interested in what you do with the data and why, so the unit of the record is the processing activity and its purpose. The same CRM might appear in a “customer support” activity, a “direct marketing” activity and a “contract administration” activity, each with a different purpose, lawful basis and retention period. Mapping by activity in step 2 keeps those distinctions clean and stops a single broad row from hiding three different legal positions.

Article 30(1) lists the mandatory fields for controllers and Article 30(2) the parallel set for processors, so the role you recorded in step 5 determines which fields the record must contain. For a ready-made field layout you can copy, see the Article 30 (RoPA) template, which sets out both the controller and processor fields as a usable structure.

How long does it take to create a RoPA?

There is no fixed answer — it scales with the size and complexity of the organisation. A small business with a handful of systems can produce a first RoPA in a few days, mostly spent in steps 1 and 2 mapping where data lives and what it is used for. A multi-entity group with many systems and international transfers takes weeks, because the data mapping in step 3 and the legal-entity scoping in step 5 are far more involved.

The larger cost, though, is not the first draft — it is keeping the register current afterwards. An organisation that builds the RoPA once in a spreadsheet and revisits it annually spends little up front and pays for it later, when the register no longer matches reality. One that derives entries from approved assessments and re-reviews them as the business changes spreads the effort and keeps the record true. The Acompli RoPA software guide covers how that maintenance model works in practice.

How do you keep a RoPA up to date?

Step 7 is where most registers fail. A RoPA is accurate the day it is written and drifts from then on; a stale register reads to a supervisory authority as weak accountability under Article 5(2), not as compliance. Keeping it current means re-reviewing the affected entries whenever a system, supplier, purpose, lawful basis or international transfer changes, and running a periodic review of the whole register on a set cadence.

This is also where software earns its place. Rather than a separate data-entry chore, the strongest approach makes the register a downstream output of work you already do: approved assessments and supplier reviews feed it, AI drafts and extracts the Article 30 fields, and the affected records surface for review when an upstream fact changes. The human approval from step 6 still applies to every change — the automation reduces the typing and the chasing, not the accountability. See the Acompli RoPA management module for how the register is maintained in the platform.

A practical cadence works best alongside the event-driven re-reviews: a full review of the register at least annually, a check after any significant project that introduces new processing, and an immediate update whenever a new system goes live, a supplier is onboarded or retired, or a transfer mechanism changes. The goal is that, on any given day, the register a supervisory authority would inspect matches the processing the business actually carries out — which is the difference between a record that demonstrates accountability and one that merely existed once.

Common questions about creating a RoPA

Primary sources

1. GDPR Article 30 (EUR-Lex, Regulation (EU) 2016/679)
2. DPC — Records of Processing (Article 30) Guidance
3. ICO — What do we need to document under Article 30?

Related research