Creating Records of Processing 2026: Template for Art. 30 GDPR

· · Category: GDPR
Practitioner note: This article is practice-oriented compliance documentation, not legal advice. We are compliance specialists, not a law firm. For legally binding advice, please consult a licensed attorney.

TL;DR

  • Mandatory from 1 employee — the 250-employee threshold in Art. 30(5) is virtually worthless in practice
  • 9 mandatory fields for controllers, 9 additional for processors
  • Excel is sufficient — tools only make sense from approximately 50 processing activities upwards
  • Audit sequence used by supervisory authorities: ROPA → DPA → TOMs → DPIA
  • Most common mistake: outdated recipient lists and missing retention periods

1. What is a record of processing activities?

A record of processing activities (ROPA) under Art. 30 GDPR systematically lists all processing of personal data carried out by a company. Purpose: evidence of accountability (Art. 5(2) GDPR) and the foundation of every supervisory authority inquiry.

"Each controller and, where applicable, the controller's representative, shall maintain a record of processing activities under its responsibility." — Art. 30(1) GDPR

The ROPA is not a technical database. It is a process-level overview: which data is processed for which purpose, on which legal basis, by whom, and for how long?

Anyone who does not want to build the complete document set from scratch will find in the GDPR Kit a ready-to-use ROPA Excel with 14 SME-typical processing activities, DPA cross-reference and TOM annex.

2. Who needs a ROPA — and who really does not?

Under Art. 30(1): all controllers. Under Art. 30(2): all processors. The 250-employee exemption (Art. 30(5)) only applies cumulatively:

  1. fewer than 250 employees AND
  2. no likely high risks AND
  3. no regular processing AND
  4. no special categories (Art. 9) OR criminal-law-related data

In practice: HR data (payroll) is regular processing. CRM is regular processing. Newsletters are regular processing. This means the exemption is voided for every company from 1 employee upwards that has customers.

3. What content must the ROPA contain?

9 mandatory fields per processing activity (controller, Art. 30(1)):

Mandatory fieldExample
1. Name + contact details of controller (+ DPO)Mustermann GmbH, info@..., DPO: ext-dpo@...
2. Purposes of processingCustomer relationship management, order processing
3. Description of categories of data subjectsCustomers, prospects
4. Description of categories of personal dataMaster data, communication data, contract data
5. Categories of recipientsTax advisor (processor), shipping service provider (processor), authorities
6. Third-country transfers + safeguardsMailchimp (USA, DPF), Google Workspace (USA, DPF)
7. Planned retention periodsCustomer data 10 years (HGB), applicants 6 months (AGG)
8. General description of TOMsReference to TOM concept (Art. 32)
9. Legal basisArt. 6(1)(b) (contract), Art. 6(1)(f) (legitimate interest)

4. ROPA in Excel or as a tool?

CriterionExcelTool
Number of processing activities < 50✓ optimaloverkill
Number of processing activities > 50unwieldy✓ useful
Multi-site / corporate groupdifficult✓ added value
Version controlmanual✓ automatic
CostsEUR 0EUR 2,000–15,000/year
DPO acceptance✓ full✓ full
Audit acceptance by supervisory authority✓✓

Supervisory authority position: Form is irrelevant — as long as content, currency and readability are correct. The BfDI and the state DPAs explicitly accept Excel-based ROPAs.

5. 8 steps to an audit-ready ROPA

  1. Identify processing activities: workshop with all departments (HR, sales, marketing, IT, accounting, management). 14-station method: 1 processing activity per employee lifecycle, 1 per customer lifecycle.
  2. Clarify responsibility: are we the controller (Art. 4 No. 7), the processor (Art. 4 No. 8) or joint controllers (Art. 26)?
  3. Determine legal basis: Art. 6(1)(a)-(f). For employee data, usually Section 26 BDSG. For special categories (Art. 9): additional legal basis required.
  4. Systematically document data categories: master data, contract data, communication data, usage data, location data — one row per category.
  5. Recipients including third countries: EU recipients usually require itemised listing. Third countries require a safeguard (SCC, DPF, BCR) — separate column.
  6. Retention periods per category: retention obligations under HGB/AO (10 years), SGB (5 years), employment-law retention. Document any conflict with Art. 17 (erasure).
  7. TOM reference: no ROPA without TOM annex. No separate TOM per processing activity — but a reference to the central TOM concept (Art. 32).
  8. Define review cycle: annually + upon changes. Quarterly recommended for continuously growing companies.

6. 14 typical SME ROPA entries

  1. Payroll (jointly with tax advisor, DPA in place)
  2. Applicant management (own server or e-recruiting SaaS)
  3. Newsletter dispatch (Mailchimp/CleverReach/Brevo)
  4. CRM customer master data (Salesforce/HubSpot/own DB)
  5. Web analytics (Pirsch cookieless / Matomo / GA4)
  6. Video surveillance of factory hall / outdoor area
  7. Customer communication (email, telephone, chat)
  8. Processor activities (data processed on our behalf by IT service providers)
  9. Supplier management (master data, contracts)
  10. Complaints management (customers + internal reporting office)
  11. Illness cases / occupational reintegration (special categories Art. 9, Section 167 SGB IX)
  12. Time tracking (employees, BAG mandatory ruling 2022)
  13. Vehicle fleet + GPS tracking (where used)
  14. Work equipment inventory (laptop, mobile, where personally identifiable)

7. Avoiding 9 common mistakes

  1. Outdated recipient lists (old newsletter tools not removed)
  2. Missing retention periods ('no specific information')
  3. No third-country notice for US tools (Mailchimp, Google, Zoom)
  4. Processor relationship confused with what is actually joint controllership
  5. No ROPA for the subsidiary GmbH
  6. 'Bulk communication processing' — too unspecific
  7. No TOM reference, but TOM content within the ROPA (duplication)
  8. Format issues: PDF instead of editable format (supervisory authority needs Excel/CSV)
  9. No versioning (which version is valid?)

8. ROPA during supervisory authority inquiries

BfDI Activity Report 2024: 85% of all supervisory inquiries begin with the submission of the ROPA. Practical audit sequence:

  1. ROPA — completeness, currency, plausibility
  2. DPA — are all external processors named in the ROPA? Is a DPA in place for each one?
  3. TOM concept — appropriate for the risk profile of the processing activities?
  4. DPIA — carried out for the high-risk processing activities?

Anyone who fails at the ROPA cannot 'surprisingly excel' at the rest. The ROPA is the mandatory foundation exercise.

Frequently Asked Questions

Is an Excel spreadsheet sufficient as a record of processing activities (ROPA)?
Yes, from a practical perspective entirely sufficient. Tools only become worthwhile from approximately 50 processing activities or multi-site structures. Important: version control, consistent categories, clear linkage to data processing agreements (DPAs) and technical and organizational measures (TOMs).
When must the ROPA be updated?
Continuously, with every change. Practical standard: quarterly review + ad hoc for new processing activities, new IT systems or new processors. Document updates with date — otherwise problems will arise upon supervisory authority inquiry.
Does the 250-employee exception in Article 30(5) apply in practice?
Almost never. The exception only applies if the processing involves NO risk, is NOT regular AND does not concern special categories of data — cumulatively. Even personnel data or newsletters meet the 'regular' criterion and eliminate the exception.
Must internal HR processing activities such as sickness cases be included in the ROPA?
Yes. Special categories under Article 9 (health data) must also be listed in the ROPA — with reference to the legal basis (typically Section 26 BDSG (Federal Data Protection Act) for employee data protection). Document retention and deletion periods separately.
What if the supervisory authority requests the ROPA — how quickly must it be available?
Article 30(4) GDPR: 'on request'. In practice, supervisory authorities expect transmission within 1-2 weeks. Those unable to deliver signal serious compliance deficiencies — aggravated fines are likely.
Is a ROPA mandatory for associations?
Yes, as soon as the association processes personal data (always the case — member administration). Associations fall under the same rules as SMEs. Entry prepared in our GDPR Kit for associations.
As a processor: must I also maintain a ROPA?
Yes, under Article 30(2) GDPR with its own mandatory field catalog. Content: name + contact details of the controller, categories of processing activities for each controller, third-country transfers where applicable, general description of TOMs. Not to be confused with the data processing agreement (DPA) itself.
Do I need a separate ROPA per subsidiary?
Yes, if each subsidiary is an independent controller (typical in German corporate group structures). A group-wide solution is possible but legally risky — supervisory authorities expect clean separation of responsibilities.

Sources

Related