How to Build a ROPA Under GDPR: A Practical Guide

The Record of Processing Activities (ROPA) is one of the foundational accountability documents required by GDPR. Article 30 makes it mandatory for controllers and processors to maintain a written record of all personal data processing activities they carry out. Despite its importance, the ROPA is frequently under-built, out of date, or simply missing.

This guide covers who is required to maintain a ROPA, what it must contain, and how to build and keep one current.

What a ROPA Is

A ROPA is a documented inventory of every processing activity your organisation carries out involving personal data. It is not a public document — it is an internal accountability record, maintained for the benefit of your organisation and to be made available to supervisory authorities on request.

Article 30 distinguishes between the obligations of controllers (organisations that determine the purposes and means of processing) and processors (organisations that process data on behalf of a controller). Most businesses are controllers for their own data processing and processors for data they handle on behalf of clients.

Who Is Exempt

Article 30(5) provides an exemption for organisations with fewer than 250 employees, unless the processing:

• Is likely to result in a risk to the rights and freedoms of data subjects;
• Is not occasional; or
• Includes special category data (Article 9) or data relating to criminal convictions (Article 10).

In practice, this exemption is narrower than it appears. "Not occasional" means any processing that occurs on a regular or ongoing basis — which includes employee data, customer data, marketing lists, and vendor management. Any organisation that maintains customer records, runs payroll, or sends regular marketing emails does not qualify for the exemption on the "not occasional" ground alone.

The practical implication: most businesses — regardless of headcount — need a ROPA. If you process personal data regularly, you should have one.

What the Controller ROPA Must Contain (Article 30(1))

| Element | What to Record | |---------|---------------| | Name and contact details | Controller's name, address, and where applicable the DPO | | Purposes of processing | Why you process this data | | Categories of data subjects | Who the data is about (employees, customers, website visitors) | | Categories of personal data | What data you hold (name, email, health data, financial data) | | Categories of recipients | Who you share the data with (third parties, processors) | | Third country transfers | Transfers outside the EEA and the safeguards in place | | Retention periods | How long you keep the data (or criteria to determine this) | | Security measures | Description of technical and organisational measures (Article 32) |

All eight elements are required. The most commonly incomplete sections are retention periods and security measures.

What the Processor ROPA Must Contain (Article 30(2))

If your organisation acts as a processor for others' data (e.g., a SaaS company processing client data, a payroll provider, a cloud storage provider), your processor ROPA must contain:

• Name and contact details of the processor and each controller on whose behalf you act
• Categories of processing carried out on behalf of each controller
• Third country transfers and safeguards
• Description of security measures

Practical Structure: Organise by Processing Activity

The most workable format is a table with one row per processing activity. Group activities by business function:

HR: recruitment, employee records, payroll, performance management, offboarding Marketing: email campaigns, lead capture, CRM, advertising targeting Customer support: support tickets, call recordings, account management Finance: invoicing, accounts payable, financial reporting IT and systems: access logs, system monitoring, vendor management Legal and compliance: contract management, incident records, regulatory reporting

Each row in your table should capture all eight Article 30(1) elements for that activity. A single row might look like:

| Activity | Purpose | Data Subjects | Personal Data | Recipients | Retention | Transfers | Security | |----------|---------|--------------|--------------|------------|-----------|----------|---------| | Employee payroll | Process salary payments | Employees | Name, bank account, salary, tax code | Payroll processor, HMRC/tax authority | Duration of employment + 7 years | None | Encrypted transfer, access controls |

Data Mapping First

You cannot write a ROPA you have not mapped. Before completing the document, conduct a data mapping exercise:

1. Interview department heads — ask each department: what personal data do you collect? Where does it come from? What do you use it for? Who do you share it with? How long do you keep it?
2. Review your systems inventory — list every system that holds personal data: CRM, HRIS, marketing platform, support desk, accounting software, file storage. Each system likely corresponds to one or more processing activities.
3. Check vendor contracts — your data processing agreements (DPAs) with third-party processors will identify what data flows to them and for what purpose.
4. Review privacy notices — your public-facing privacy notices describe processing activities to data subjects. These should map directly to rows in your ROPA (if they do not, your privacy notice may need updating too).

Retention Periods: The Hardest Section

Retention periods are the most frequently incomplete section of any ROPA. The temptation is to write "as required by law" — but this is insufficient. Article 30 requires you to specify actual periods or the criteria used to determine them.

Build a retention schedule alongside your ROPA. For each processing activity, identify:

• The applicable legal retention requirement (if any) — e.g., payroll records: 6 years (UK), 10 years (Germany), 3 years (France)
• The business justification for any retention beyond the legal minimum
• The retention period in concrete terms: "3 years from contract end" not "as long as required"

Where you genuinely cannot specify a period (e.g., records maintained as long as a legal dispute remains possible), document the criteria used to determine when deletion occurs.

Keeping the ROPA Current

A ROPA that was accurate at creation but has not been updated for two years is a liability. Define clear triggers for ROPA updates:

• New system or tool adopted — adds one or more processing activities
• New data category collected — updates an existing activity row
• New third-party processor engaged — updates recipients column and requires a DPA
• Process change — any material change to how, why, or by whom data is processed
• Annual review — a standing review of all activities to catch drift

Maintain a change log alongside the ROPA: when was each row last reviewed, what changed, and who approved the change. This demonstrates ongoing accountability to a supervisory authority.

ROPA Template: Core Columns

A minimal compliant ROPA table for a controller:

| Processing activity | Business function | Purpose | Legal basis | Data subjects | Personal data categories | Special category data? | Recipients | Third country transfers | Retention period | Security measures | Last reviewed | |---------------------|------------------|---------|-------------|--------------|------------------------|----------------------|------------|------------------------|-----------------|------------------|---------------|

Start with this structure and add columns as your organisation's needs become apparent. A spreadsheet is sufficient — no specialist software is required, though purpose-built tools help with ongoing maintenance.

---

Last updated: April 2026. For informational purposes only — not legal advice.