GDPR ROPA: how to maintain Article 30 records of processing

A practical guide to Article 30 of UK GDPR: what a Record of Processing Activities is, when it is required, what controllers and processors must record and how to maintain useful documentation.

A Record of Processing Activities, or ROPA, describes an organisation's processing. It supports accountability and must be available to the ICO where Article 30 applies. A limited exemption exists for some processing by organisations with fewer than 250 employees.

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.

For an organisation with fewer than 250 employees, apply the exception to the relevant activities. Regular payroll, risky processing and processing special category or criminal offence data must be documented. One such activity does not automatically remove the exemption from all other occasional, low-risk activities.

Assess which activities require records and document the reasoning. Keeping a proportionate inventory more widely can still help with accountability, even where the narrow Article 30 exception applies.

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, international transfers, the destination country or international organisation and, for transfers relying on the exceptional second subparagraph of Article 49(1), documentation of suitable 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 separates the required information into eight practical items. Apply the statutory qualifications, including where applicable and where possible, and maintain enough detail to describe the actual processing.

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, international transfers and their destinations, with documentation of suitable safeguards for transfers relying on the exceptional second subparagraph of Article 49(1).
4. Where possible, a general description of the technical and organisational security measures referred to in Article 32(1).

A processor's Article 30 record covers processing carried out for each controller. Its mandatory fields differ from the controller's, although additional information about purposes, data and retention can help demonstrate and manage the processor's obligations.

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.
• Security policies and supporting records that explain the appropriate measures used to meet Article 32, where suitable for the organisation and risks.
• Records of processing decisions — DPIAs, legitimate interests assessments, breach reports — which sit alongside the ROPA.

Keep the relationship clear: the ROPA summarises relevant processing, while supporting security records explain how controls work and are tested.

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 records can be kept in a spreadsheet, database or dedicated tool. They must be written, kept up to date and contain the fields required for the organisation's controller or processor role and relevant activities.

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).
• Review entries at suitable intervals, with an annual review as one possible practice rather than a statutory frequency.
• Changes to retention periods, recipients, or international transfers trigger an update.
• Assign responsibility for maintaining the records and obtaining updates from operational teams. The controller or processor remains accountable; a DPO may advise and monitor rather than own every operational record.

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?

An organisation with fewer than 250 employees must document processing that is non-occasional, likely to risk people's rights, or includes special category or criminal offence data. The exception can still cover its other qualifying activities.

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 records within scope to be made available to the ICO on request. Keep them current and accessible to those responsible for responding.

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

Article 30 concerns records of processing activities. Article 32 requires security appropriate to the risk, including relevant testing and evaluation. Documentation supports accountability, but Article 32 is not merely a requirement to write a security policy.

Related guides

• GDPR cookie consent in the UK: rules after the DUAA 2025
• GDPR fines and penalties in the UK: how big, who pays, what counts
• GDPR data breach: what to do in the first 72 hours

Sources & references

• ICO: documentation
• ICO: the fewer-than-250-employees exception
• UK GDPR Article 30
• UK GDPR Article 32
• GOV.UK: company records

Mark McShane

Health & Safety Training Specialist, Online CPD Academy

Mark writes about data protection, GDPR compliance and accredited online training for GDPR & Data Protection Course, part of Online CPD Academy.