GDPR ROPA: how to maintain Article 30 records of processing

A practical guide to Article 30 of the UK GDPR: what a Record of Processing Activities is, who must keep one, what it must contain, and how to build a ROPA the ICO will accept.

A Record of Processing Activities — almost always called a ROPA — is the central document of GDPR compliance. It's the inventory that shows what personal data your organisation processes, why, who's involved, and how the data flows. The ICO uses it as a starting point in audits, and an organisation without one is in immediate breach of Article 30.

This guide covers what Article 30 actually requires, who is obliged to keep a ROPA, what controllers and processors must each include, and how to build a usable document rather than a shelf-warmer.

What ROPA is and why it exists

A ROPA is a written register of an organisation's processing activities. Each entry describes one activity — for example, "processing customer order data" — and records the purpose, the categories of data and people involved, who the data is shared with, how long it's kept, and the security measures in place.

The obligation comes from Article 30 of the UK GDPR, which is part of the accountability principle in Article 5(2). Without documentation of what you're processing, you cannot demonstrate compliance with the other principles — you can't show you have a lawful basis if you don't know what activities you're running, and you can't apply data minimisation if you haven't documented what you collect.

ROPA is also the foundation document for several other compliance activities. Data protection impact assessments, breach assessments, subject access request responses, and retention schedules all draw on what the ROPA contains.

Who must keep a ROPA

Article 30 applies to controllers and processors alike. The default position is that every organisation acting as a controller or processor must maintain a ROPA.

There is a narrow exemption for organisations with fewer than 250 employees, but it is much narrower than its headline suggests. The carve-out under Article 30(5) only applies if all of the following are true:

• The processing is not likely to result in a risk to the rights and freedoms of data subjects.
• The processing is occasional.
• The processing does not include special category data or criminal offence data.

In practice, almost every modern business fails at least one of these tests. Payroll is regular. Customer marketing is regular. Anyone collecting health information, religious affiliation, or any other special category data falls outside the carve-out immediately. So while the exemption looks generous, very few organisations can rely on it.

The safer working assumption is that you need a ROPA regardless of size. If you genuinely think your processing is so narrow that the exemption applies, document the reasoning — the ICO will ask.

Required fields for controllers

Article 30(1) lists what a controller's ROPA must contain. Each entry must include:

1. The name and contact details of the controller, any joint controller, the controller's representative (if applicable), and the Data Protection Officer (if appointed).
2. The purposes of the processing — what you are using the data for, in specific terms.
3. A description of the categories of data subjects — for example, customers, employees, website visitors.
4. A description of the categories of personal data — names and contact details, financial information, health information, and so on.
5. The categories of recipients to whom the personal data has been or will be disclosed, including recipients in third countries or international organisations.
6. Where applicable, transfers of personal data to a third country or international organisation, including the identification of that country and (for transfers under Article 49(1)) the safeguards.
7. Where possible, the envisaged time limits for erasure of the different categories of data.
8. Where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

The list has eight items, and missing any of them is a documentation failure. The "where possible" qualifier on retention and security gives some flexibility, but the expectation is that you'll describe both unless there's a genuine reason you can't.

A common error is treating the ROPA as an inventory of data rather than an inventory of processing activities. The right level of granularity is the activity — for example, "customer order fulfilment" rather than "customer name". Within each activity entry, you describe the data categories involved.

Required fields for processors

Article 30(2) sets a shorter list for processors. A processor's ROPA must contain:

1. The name and contact details of the processor or processors and of each controller on whose behalf the processor is acting, and (where applicable) of the controller's or processor's representative, and the DPO.
2. The categories of processing carried out on behalf of each controller.
3. Where applicable, transfers of personal data to a third country or international organisation, including the identification of that country and (for Article 49(1) transfers) the safeguards.
4. Where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

The processor's ROPA is structured around the controllers it serves, not around its own processing decisions — because a processor only acts on the controller's instructions. The categories of data, purposes, and retention periods sit in the controller's ROPA, not the processor's.

This matters because many organisations are both controllers and processors. A payroll bureau is a processor for its clients' employee data and a controller for its own staff records. The ROPA has to reflect both roles, typically with separate sections.

ROPA vs Article 32 security records

The ROPA includes a description of the security measures in place, but it is not the complete security record. Article 32 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk — and that requires its own documentation.

In practice, organisations keep:

• The ROPA — Article 30 — which describes processing activities and includes a summary of the security measures relevant to each.
• An information security policy — Article 32 — which sets out the controls in detail (access management, encryption, backup, incident response, supplier assurance, and so on).
• Records of processing decisions — DPIAs, legitimate interests assessments, breach reports — which sit alongside the ROPA.

Conflating these is a common audit finding. The ROPA is a high-level inventory; Article 32 documentation is the underlying detail.

A practical ROPA template

A workable ROPA entry has a single row per processing activity and the columns below. The first time you build one, the work is in identifying and naming the activities — the columns themselves are straightforward once the activities are listed.

The ROPA itself is a spreadsheet, a database table, or a dedicated compliance tool. The format doesn't matter; what matters is that the eight Article 30(1) items are covered for every activity, and that the document is genuinely maintained.

A workable maintenance cycle is:

• New processing activities are added to the ROPA as part of the launch process (a sign-off before go-live).
• Existing entries are reviewed at least annually.
• Changes to retention periods, recipients, or international transfers trigger an update.
• The DPO or data protection lead owns the document and the review schedule.

For wider context on where the ROPA sits in a compliance programme, see our seven principles guide (accountability), controller vs processor guide, and retention guide.

Frequently asked questions

Do I need a ROPA if I have fewer than 250 employees?

Almost certainly yes. The Article 30(5) exemption applies only if your processing is not likely to result in a risk, is occasional, and excludes special category data. Most modern businesses fail at least one of those tests.

What's the difference between ROPA and DPIA?

A ROPA is an inventory of all processing activities. A Data Protection Impact Assessment is a deeper analysis required where a specific processing activity is likely to result in high risk to individuals. The ROPA identifies which activities need a DPIA; the DPIA is a separate document.

Does the ROPA need to be written?

Yes. Article 30(3) requires the records to be in writing, "including in electronic form". A spreadsheet, database, or compliance tool entry counts; a verbal understanding does not.

Can the ICO ask to see my ROPA?

Yes. Article 30(4) requires controllers and processors to make the records available to the supervisory authority on request. ROPA gaps are a frequent ICO audit finding.

What's the difference between Article 30 and Article 32?

Article 30 covers documentation of processing activities. Article 32 covers documentation of security measures. The ROPA includes a description of security at a high level; the detailed security controls sit in a separate information security policy.