ROPA Example: A Complete 2026 Worked Record of Processing Activities

A ROPA example is the quickest way to see what a finished record of processing activities looks like, because Article 30 of the GDPR lists what the record must contain but never shows one filled in. This guide walks through a complete ROPA example for a fictional delivery company, from the controller’s details and the exemption check to three activities in full, the processor record and the gaps the checks found.

It follows the structure of our guide to records of processing: the controller record in Article 30(1), the processor record in Article 30(2), and the extra fields supervisory authorities recommend. The legal text is in Article 30 of the GDPR, and the same article applies under the UK GDPR.

The Organization in This ROPA Example

Harbour Logistics (a fictional company) employs about 320 people and runs parcel deliveries from three depots. It is a controller for its own staff, customers and suppliers, and a processor for the retailers and the pharmacy group whose parcels it delivers. It has appointed a data protection officer because it monitors drivers’ vehicles on a large scale.

Step 1: Does Article 30 Apply in Full?

The exemption in Article 30(5) covers organizations with fewer than 250 people, and only for processing that is occasional, unlikely to result in a risk and free of special category or criminal offence data. With 320 people, Harbour is outside the exemption altogether. A smaller business would still need a record in almost every case, because payroll and customer records are regular processing, not occasional.

Step 2: The List of Activities

Harbour started from a list of typical activities by department and kept 18: six in HR, two customer activities, two in marketing, three in IT and security, one in finance, three in legal and compliance, and one operational activity that no template had, vehicle telematics. The test for each entry is whether it has one purpose. “Customer data” is not an activity; “customer contracts and deliveries” and “customer support and complaints” are.

Step 3: Three Activities in Full in This ROPA Example

These three entries show the range: an ordinary HR activity, a monitoring activity with a DPIA behind it, and an activity with a transfer outside the EEA.

Harbour wrote one general description of its security measures and reused it for every activity, adding anything specific. Article 30(1)(g) asks only for a general description “where possible”, so this is enough; the detail belongs in the security policy.

Step 4: The Processor Record

As a processor, Harbour keeps a second, shorter record under Article 30(2). It has two entries: one for retail clients under the standard parcel delivery agreement, and one for the pharmacy group, whose deliveries reveal that a patient receives prescriptions and therefore involve health data. For each, the record names the client and its contact, the categories of processing, the sub-processors, transfers and the security measures, and whether the Article 28 contract is in place. Our comparison of controller vs processor ROPA records explains the difference in detail.

Step 5: What the Checks Found

A ROPA example is also useful for what it gets wrong. Running the record through the checks in our free ROPA template gave a record score of 90 out of 100, held at Developing because of one critical finding:

• Critical: a transfer with no safeguard. Customer support data goes to an outsourced centre in India with no standard contractual clauses recorded.
• Major: legitimate interests without an LIA. Staff IT monitoring, security logging and AI tools rely on legitimate interests, but only two of five such activities have a legitimate interests assessment.
• Major: likely high-risk processing without a DPIA. Security logging is large scale and monitors staff, two of the criteria the EDPB uses to flag high-risk processing.
• Major: retention with no real limit. Supplier payment records were marked “indefinitely”.
• Major: missing Article 28 terms. The pharmacy client’s contract lacks some of the terms Article 28(3) requires.
• Minor: an unchecked entry and an activity with no owner.

None of these is visible in a spreadsheet that only lists activities. They show up because each entry records the lawful basis, the transfer tool, the retention period and the assessments behind it, which is why supervisory authorities recommend those fields even though Article 30 does not list them all.

How to Build Your Own From This ROPA Example

1. Name who you are. Record the controller’s details, the DPO and any representative or joint controllers, and decide whether you are also a processor.
2. List activities by department. Walk through HR, customers, marketing, finance, IT and security, legal and operations with each department head. Ask what they do with personal data and why, not which systems they use.
3. Complete each entry with its owner. The owner knows the recipients, the suppliers and how long data is really kept. Library wording is a starting point, not an answer.
4. Add the fields that expose gaps. The lawful basis, the Article 9 condition, the transfer tool and the DPIA or LIA status turn the record from a list into a check.
5. Approve it and set a review date. In this ROPA example the operations director approved the record and the next review is in twelve months, sooner if a process or supplier changes.

Most organizations can reach a first complete draft in a few working sessions this way. The slow part is not the writing but getting accurate answers about recipients, transfers and retention, which is exactly where the findings in this ROPA example came from.

Common Mistakes This ROPA Example Avoids

• One row per system. A ROPA is organized by purpose, not by application; one system can serve several activities.
• “Various” as an answer. Categories of data subjects, data and recipients must be specific enough to answer an access request.
• Forgetting the processor record. Service providers are almost always processors for someone.
• Retention by habit. “Indefinitely” and “to be confirmed” are not time limits for erasure.
• A record nobody owns. Each entry has an owner, and the whole record has an approver and a review date.

Frequently Asked Questions

Can I copy this ROPA example?

Use its structure, not its content. Your activities, bases, recipients and retention periods will differ, and a record copied from someone else describes their processing, not yours.

How many activities should a ROPA have?

Enough that each has one purpose. A small business typically ends up with 15 to 30; a large group with several hundred, often split by business unit.

Does the ROPA have to be in a particular format?

No. Article 30(3) requires it in writing, including in electronic form. A spreadsheet or a tool is fine, provided you can produce it for the supervisory authority on request.

What is the penalty for not keeping a ROPA?

Breaches of Article 30 fall under Article 83(4), with fines of up to 10 million euros or 2% of worldwide annual turnover, whichever is higher. In practice, a missing or out-of-date record is usually found during an investigation into something else.

To build your own in the same order, use our free ROPA template, which checks every entry as you go. The GDPR Toolkit includes an editable Records of Processing Activities register and the procedure for keeping it, and our sample reports include the full Harbour Logistics record.