ROPA Template: Records of Processing Activities (GDPR Article 30)

Definition. A Record of Processing Activities (ROPA) is the central inventory required by GDPR Article 30. It documents the processing activities covered by the obligation: purposes, data categories, recipients, transfers, retention, security. Both controllers (Article 30(1)) and processors (Article 30(2)) must maintain a ROPA. Article 30(4) requires the record to be available to the supervisory authority on request.

Use this guide to structure your first entries, assign a reviewer and plan how the register will stay current. It includes controller and processor templates, examples for common activities and a maintenance workflow. Work through one activity with its business owner before copying the structure across the organisation.

For the broader compliance framework, see our data privacy compliance guide. For audit methodology, GDPR audit methodology. For the related vendor audit, Article 28 audit checklist.

Key takeaways

• Article 30 sets separate controller and processor records, subject to the limited Article 30(5) derogation.
• Companies under 250 employees are exempt only if processing is occasional, doesn’t involve special categories, and doesn’t pose a risk to data subjects (rare in practice).
• Use the controller or processor field set for the role actually performed.

1. When is a ROPA mandatory?

Article 30(1) requires a controller ROPA. Article 30(2) requires a processor ROPA. Article 30(5) provides an exemption for organizations under 250 employees — but only if all three conditions are met:

• Processing is occasional
• Does not include special categories of data (Article 9) or criminal data
• Is unlikely to result in a risk to the rights and freedoms of data subjects

For organisations below the threshold, assess the processing activities against the exceptions rather than treating employee count as sufficient. Regular HR and customer processing commonly remain within the record obligation. Document the basis of any limited exemption relied on.

2. Controller ROPA — mandatory fields (Article 30(1))

For each processing activity, document:

3. Processor ROPA — mandatory fields (Article 30(2))

4. Worked HR entry: separate purposes and access

The following example is hypothetical. A company uses a payroll provider and an internal personnel system. Its business owner records payroll administration separately from recruitment and performance assessment because their data, recipients and retention triggers differ. It does not describe every HR use as necessary to perform the employment contract.

Ask the owner which payroll outputs are copied elsewhere. A downloaded spreadsheet on a manager’s laptop can create a recipient or retention gap even when the payroll platform is correctly configured. Record open questions and the person who will resolve them. The example is a drafting exercise, not a national retention schedule.

5. Worked marketing entry: preserve the consent boundary

A hypothetical newsletter activity records the consent purpose, the signup interface and the system holding proof. Its minimum data might include an address, the choice timestamp and the relevant information version. Tracking opens or clicks is a separate design question: do not add behavioural data to the record merely because an email tool offers it.

When a person unsubscribes, distinguish stopping the campaign, retaining limited proof where justified and maintaining an appropriately minimised suppression entry. None of these implies a universal twenty-four-month retention period. Specify the reason and access restrictions for any data retained after withdrawal.

List the actual sending provider and determine the processing locations, including support access and subprocessors. Verify the receiving entity and the applicable transfer mechanism before completing that field. A familiar brand name or an old certification entry is not enough. Link the processor contract and the evidence showing that the unsubscribe reaches scheduled campaigns and imported contact lists.

6. Worked analytics entry: record the actual configuration

For a hypothetical website, start with the events actually collected and the purposes of their use. State whether identifiers, account links, device information or location data are involved. Pseudonymised information can remain personal data; do not describe it as anonymous solely because a name is absent.

Record the consent or exemption analysis for trackers where relevant, the GDPR basis for subsequent processing and the chosen retention settings. Enter the receiving entities and countries without assuming that one vendor certification covers every product or transfer. If the team relies on an adequacy decision, check the relevant destination and scope; if it uses contractual safeguards, retain the supporting assessment.

Before approval, compare the draft with a sample of actual events and the current settings. Record discrepancies such as an identifier sent unexpectedly or a retention setting longer than the documented rule. An owner should correct the system or revise the record with a justified decision. Completing a field does not itself make the underlying processing lawful.

7. Maintenance workflow

A ROPA is not a one-time document. Maintenance:

Example periodic review

• Review changes in vendor list (new sub-processors)
• Confirm retention periods still applied
• Check transfer mechanisms still valid (DPF certifications, SCCs)

Example full review

• Full review of every entry
• Check activity descriptions and recorded data volumes against current systems
• Re-confirm lawful basis and DPIA status
• Add new processing activities introduced during the year
• Archive obsolete entries

Triggered review (when…)

• New processing activity introduced
• New vendor added
• Major regulation update (e.g., new EDPB guidelines)
• DPA inspection notification

8. Common ROPA failures (from CNIL inspections)

1. Missing entries for marketing tools (analytics, A/B testing, heatmaps) added without privacy review
2. Generic security descriptions (“appropriate technical measures”) without specifics
3. Incorrect lawful basis (consent invoked when contract or legitimate interest applies)
4. Out-of-date retention periods not aligned with actual deletion
5. Sub-processors not listed — only top-level vendor named
6. No documented review process — entries not updated for 18+ months
7. No DPIA cross-reference for high-risk processing
8. Missing international transfer details — country named but not safeguard mechanism

9. ROPA in spreadsheet vs. dedicated tool

A spreadsheet can be a useful starting point. Review whether it still works for your team when you encounter these limitations:

• Spreadsheets become unwieldy for cross-referencing (sub-processors, DPIAs, lawful bases)
• No automation of vendor data refresh
• No alerts on stale entries
• No multi-language support if FR + EN ROPA needed
• No audit trail of changes

Compare ROPA software and its review workflows using one of your existing entries. Check how an owner records a change, how a reviewer approves it and what appears in the export. If you book a demo, bring an anonymised example and the questions your current spreadsheet leaves unanswered.

10. Prepare an evidence trace for an authority request

Article 30 requires the record to be available on request; it does not prescribe a universal inspection order or sample size. Prepare to explain an entry by opening the linked contract, notice, retention rule and security evidence. Keep unresolved issues visible rather than presenting an incomplete entry as approved.

Ask someone outside the drafting team to follow one activity from purpose to systems and recipients. If they cannot find the deletion rule or identify the owner of an export, assign a correction. This review checks whether the record can guide work and support an explanation; it does not certify the whole organisation.

Conclusion

The ROPA is not paperwork — it is the operational nerve center of a privacy program. Every other compliance artifact (DPIA, DPA, breach response, data subject request handling) traces back to entries in the ROPA. Investing in a complete, well-maintained ROPA pays back the first time a regulator asks for it.

FAQ

Is a ROPA mandatory for small businesses?

Article 30(5) provides a narrow exemption for organizations under 250 employees, but only if processing is occasional, doesn’t include special-category or criminal-offence data, and is unlikely to result in a risk to rights and freedoms. Assess the actual activities and document the limited exemption where it applies.

What’s the difference between a controller ROPA and a processor ROPA?

Controllers maintain a ROPA listing all their processing activities (Article 30(1), controller fields). Processors maintain a ROPA listing the categories of processing they perform on behalf of each controller (Article 30(2), processor fields).

How often should the ROPA be updated?

Choose a periodic review appropriate to your change rate; the GDPR sets no universal quarterly or annual calendar. Immediately when a new processing activity is introduced or when a major regulation update affects an existing entry.

Does the ROPA need to be in a specific format?

GDPR doesn’t mandate a format. Article 30(3) requires it to be in writing, including electronic form, and made available to the supervisory authority on request. Spreadsheets work for small operations; the choice of a dedicated tool depends on coordination, traceability and maintenance needs, not a legal threshold of activities or vendors.

Can I delegate ROPA maintenance to my DPO?

The DPO can coordinate ROPA maintenance but the controller remains responsible (Article 24). Best practice: business unit owners populate entries for their processing, the DPO reviews for completeness and quality, and the controller approves quarterly.

Legal source: Article 30 du RGPD.

When completing retention fields, use the data-retention policy workflow to connect the purpose, deletion trigger and restricted archive. The register should reference that decision so its owner can explain which rule the system is meant to execute.