GDPR Records of Processing Activities (ROPA) Builder

Build a GDPR Article 30 processing record

A Record of Processing Activities (ROPA) is the backbone of accountability under the GDPR. Article 30 requires controllers (and processors) to keep a written inventory of every processing activity so a supervisory authority — or your own team — can see at a glance what personal data flows through the organisation. This builder turns a handful of inputs into a clean, structured ROPA entry you can drop into your processing register.

How it works

The tool maps your inputs onto the mandatory fields Article 30(1) lists for controllers: the name and contact of the controller (and any data protection officer), the purposes of the processing, the categories of data subjects and personal data, the categories of recipients, any transfers to third countries, the envisaged retention periods, and a general description of the technical and organisational security measures under Article 32.

The legal basis selector covers all six Article 6 lawful bases. When you pick “legitimate interests” the record adds a reminder that a documented Legitimate Interests Assessment (balancing test) is required. A separate flag marks whether special category data under Article 9 is involved, which would require an additional condition beyond your Article 6 basis.

What counts as a processing activity

One of the most common ROPA mistakes is treating every data field as a separate entry. A processing activity is a coherent operation or set of operations with a specific purpose. Think of it as answering the question: “What are we doing with personal data, and why?”

Common examples of distinct processing activities for a typical business:

• Customer order management — processing contact, payment, and delivery data to fulfil orders
• Payroll and HR records — processing employee data to calculate and pay salaries, meet tax obligations
• Marketing emails — processing contact data and preferences to send promotional communications
• CCTV surveillance — processing visual data for security monitoring
• Website analytics — processing behavioural data to understand visitor patterns
• Supplier contact management — processing contact data for business relationship management

Each of these would have its own ROPA entry with its own purpose, lawful basis, retention period, and recipients.

The six Article 6 lawful bases explained briefly

Every processing activity needs a lawful basis, and you must document which one applies:

You cannot pick the basis that is most convenient; the basis must genuinely apply. Consent is often chosen when it does not need to be — if you process employee data for payroll, the basis is legal obligation and contract, not consent (which would not be freely given in an employment context anyway).

Retention: write rules, not dates

A ROPA entry that says data is deleted on “31 December 2025” becomes stale immediately. Instead, express retention as a rule tied to a triggering event:

• "Employee personal data: 6 years after end of employment"
• "Customer order data: 7 years from invoice date (UK tax records)"
• "CCTV footage: 30 days from recording date unless subject to a retention hold"

This way the register remains accurate indefinitely without requiring annual updates to every entry.

Tips and notes

• Keep one ROPA entry per distinct processing activity, not one per data field or per system.
• Review the register at least annually and whenever you add a new tool, vendor, or data flow that changes the processing.
• If you transfer personal data to countries outside the UK or EEA, document the transfer mechanism (adequacy decision, Standard Contractual Clauses, etc.) in the transfers field.
• This is a template generator, not legal advice — have a qualified adviser review the output before it becomes your official record.