Patroklos PatroklouRecord of Processing Activities: A Practical GDPR Article 30 Guide
If a data protection authority asked to see how your organisation uses personal data, could you show it today? Under the GDPR, the answer should be yes. Article 30 requires most organisations to keep a record of processing activities, often shortened to ROPA, and to hand it over to the supervisory authority on request.
A ROPA is more than a regulatory checkbox. Done well, it is the map that the rest of your privacy programme relies on. It tells you which systems hold personal data, why you process it, who receives it and how long you keep it.
This guide explains who must keep a ROPA, what controllers and processors need to record, how to build and maintain one, and the mistakes that most often weaken it.
What is a record of processing activities?
A ROPA is a written inventory of the ways your organisation processes personal data. Each entry describes one processing activity, such as payroll, customer support or marketing emails, and captures the details set out in Article 30 of the General Data Protection Regulation.
Article 30 sets out a few core rules:
- Controllers must keep records of the processing activities under their responsibility (Article 30(1)).
- Processors must keep records of all categories of processing they carry out on behalf of controllers (Article 30(2)).
- The records must be in writing, which includes electronic form (Article 30(3)).
- They must be made available to the supervisory authority on request (Article 30(4)).
The ROPA also supports the wider accountability principle in Article 5(2), which requires controllers to be able to demonstrate compliance. It is hard to show that processing is lawful, minimised and secure if you cannot first say what that processing is.
Who must keep one? The under-250 exemption and its limits
Every controller and processor starts from the position that it must keep records. Where applicable, a controller’s or processor’s representative in the EU must keep them too.
Article 30(5) offers a derogation for enterprises and organisations employing fewer than 250 persons. However, the exemption does not apply where the processing:
- is likely to result in a risk to the rights and freedoms of data subjects;
- is not occasional; or
- includes special categories of data under Article 9(1), or personal data relating to criminal convictions and offences under Article 10.
Why the exemption is narrower than it looks
The Article 29 Working Party, whose position paper on this derogation was later endorsed by the European Data Protection Board (EDPB), confirmed that these conditions are alternatives. Meeting any one of them is enough to require a record for that processing.
The paper also explained that the obligation applies activity by activity. A small organisation does not need to record everything, but it must record the processing activities that fall within one of the three conditions.
In practice, almost every employer processes some data regularly. The position paper gives employee data as an example: a small organisation will usually process it on an ongoing basis, so that processing is not occasional. Payroll, HR and routine customer records will therefore normally need to be recorded, even in a business with a handful of staff.
A note on proposed changes
The European Commission has proposed simplifying the record-keeping rules. A May 2025 proposal, for example, would extend the derogation to organisations with fewer than 750 employees unless their processing is likely to result in a high risk. As of mid-2026 these changes are proposals still going through the EU legislative process, so the current Article 30(5) wording continues to apply. Check the final text before relying on any new exemption.
What controllers and processors must record
Article 30 sets different minimum contents for controllers and processors. The table below summarises them.
| Controller record (Article 30(1)) | Processor record (Article 30(2)) |
|---|---|
| Name and contact details of the controller and, where applicable, any joint controller, representative and data protection officer (DPO) | Name and contact details of the processor, each controller it acts for, any representatives and the DPO |
| Purposes of the processing | Categories of processing carried out on behalf of each controller |
| Categories of data subjects and categories of personal data | Not required |
| Categories of recipients, including recipients in third countries or international organisations | Not required |
| Transfers to third countries or international organisations, and, for certain transfers under Article 49(1), documentation of suitable safeguards | The same transfer details and documentation |
| Where possible, envisaged time limits for erasure | Not required |
| Where possible, a general description of technical and organisational security measures under Article 32(1) | Where possible, the same general description of security measures |
Many organisations act as both controller and processor. A payroll provider, for instance, is a controller for its own staff data and a processor for its clients’ employee data. In that case you need both types of record.
Recommended ROPA template fields
The legal minimum is a starting point. Most mature ROPAs add fields that make the record useful for day-to-day compliance. A practical template for controllers often includes:
- Activity name and owner. A clear name and the business owner accountable for it.
- Purpose. Why the processing happens, in plain language.
- Lawful basis. The Article 6 basis and, for special category data, the Article 9 condition.
- Data subjects and data categories. For example, customers, employees or website visitors, and the types of data held about them.
- Source of the data. Collected directly, from third parties or generated internally.
- Systems and assets. The applications, databases and locations where the data sits.
- Recipients and processors. Internal teams, vendors and other third parties.
- International transfers. Destination countries and the transfer mechanism relied on.
- Retention. How long each data category is kept, linked to your retention schedule.
- Security measures. A summary or link to the relevant controls.
- DPIA status. Whether a data protection impact assessment is needed and where it is held.
- Review date. When the entry was last checked.
Fields such as lawful basis and DPIA status are not required by Article 30 itself, but they help you meet other GDPR obligations and answer regulator questions quickly.
How to build a ROPA step by step
Building a record of processing activities from scratch is easier when you treat it as a project with clear phases.
- Define scope and ownership. Decide which legal entities are in scope, whether you act as controller, processor or both, and who owns the ROPA overall. The DPO or privacy lead usually coordinates, but business owners provide the detail.
- Identify processing activities. Work department by department: HR, finance, sales, marketing, customer service, IT and operations. Ask each team what personal data it collects, uses, shares or stores.
- Map systems and data flows. Link each activity to the systems and vendors involved. Your IT asset inventory and procurement records are good sources.
- Collect the required details. Use a consistent questionnaire based on your template fields so that entries are comparable.
- Validate and fill gaps. Review answers for vague purposes, missing retention periods or unknown recipients, and follow up with owners.
- Link to related records. Connect entries to processing agreements, transfer assessments, DPIAs and policies.
- Approve and publish internally. Have owners confirm their entries and store the ROPA where the privacy team and auditors can access it.
How to keep your ROPA up to date
A ROPA that was accurate at launch but never updated quickly loses its value. Build maintenance into normal business processes:
- Trigger updates on change. New systems, vendors, products or purposes should prompt a ROPA update as part of privacy by design reviews.
- Connect to procurement. When a new vendor that processes personal data is onboarded, update the recipient and transfer details.
- Run periodic reviews. Ask owners to confirm their entries on a regular cycle, such as annually, and record the review date.
- Keep version history. Being able to show how the record changed over time strengthens your accountability evidence.
Common ROPA mistakes to avoid
- Treating it as a one-off exercise. Spreadsheets created for a GDPR project and then forgotten are one of the most common weaknesses.
- Recording systems instead of activities. A list of applications is not a ROPA. Records should be organised around purposes, with systems linked to them.
- Vague purposes. Entries such as “business operations” or “general administration” do not tell a regulator or your own team anything useful.
- Missing retention periods. Article 30 asks for time limits where possible. Leaving the field blank often reveals that no retention rule exists.
- Over-relying on the under-250 exemption. As explained above, regular processing such as payroll usually needs to be recorded regardless of size.
- Forgetting the processor record. Service providers often document their own processing but overlook the separate record for work done on behalf of clients.
- No clear ownership. Without named owners, updates stall and accuracy declines.
How Enactia helps
Enactia is an AI-powered governance, risk and compliance (GRC) platform. It helps privacy teams move their ROPA out of scattered spreadsheets and keep it connected to the rest of their programme.
- Structured ROPA management. The Record of Processing Activities (ROPA) module gives you a central, structured register of processing activities that business owners can contribute to and maintain.
- Linked DPIAs. The DPIA module lets you assess higher-risk activities identified in your ROPA and keep the assessment connected to the record.
- Vendor oversight. Vendor and third-party management helps you assess the processors and recipients listed in your records.
- AI support. EnactAI, the built-in AI assistant, can help teams work through documentation tasks faster.
Frequently asked questions
Is a ROPA mandatory under GDPR?
For most organisations, yes. Article 30 requires controllers and processors to keep records. The only derogation is for organisations with fewer than 250 employees, and it does not cover processing that is risky, not occasional, or involves special category or criminal offence data.
Does a ROPA have to be in a specific format?
No. Article 30(3) only requires the records to be in writing, including electronic form. Spreadsheets and dedicated software are both acceptable, provided the required content is there and you can produce it on request.
Do we need to send our ROPA to the regulator?
Not proactively. You must make it available to the supervisory authority on request, so it should always be current and easy to export.
Can a small business ignore Article 30?
Rarely. Regular processing such as payroll or customer records is not occasional, so most small businesses still need records for at least those activities.
How often should a ROPA be reviewed?
The GDPR does not set a fixed interval. Update it whenever processing changes, and run a periodic review, for example annually, to confirm entries remain accurate.
Conclusion: make your ROPA a living record
A strong record of processing activities shows regulators that you understand your data, and it gives your own team a reliable foundation for DPIAs, data subject requests, vendor reviews and breach response. Start with the Article 30 minimum, add the fields that make it useful, and build updates into everyday processes so it stays accurate.
Want to see how Enactia can help you build and maintain your ROPA? Contact us or book a demo with our team.
