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

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 basis for every supervisory enquiry.

"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 are processed for which purpose, on which legal basis, by whom and for how long?

The record must be made available to the supervisory authority on request (Art. 30(4) GDPR) — so it has to reflect the current status at all times. That makes it the first document to carry a review, and at the same time the entry point to the three documents that hang off it:

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

A record is maintained by every controller (Art. 30(1) GDPR) and every data processor (Art. 30(2) GDPR). The 250-employee exemption (Art. 30(5)) only applies cumulatively:

1. fewer than 250 employees AND
2. no risk to the rights and freedoms of data subjects AND
3. no regular processing AND
4. no special categories (Art. 9) OR criminal-offence data

Important: the official wording of Art. 30(5) GDPR refers to 'a risk to the rights and freedoms of data subjects' — not to a high risk. The 'high risk' threshold only applies to the data protection impact assessment under Art. 35(1) GDPR.

In practice: HR data (payroll) is regular processing. CRM is regular processing. Newsletters are regular processing. This means the exemption falls away for every company with at least 1 employee and customers.

The four conditions have to be read together: if a single one falls away, the relief no longer applies — the exemption is therefore not a size-based exclusion but a narrow special case. Anyone relying on it should record the assessment of the four points in writing; that is a practitioner recommendation, not a statutorily prescribed form of documentation (the same exemption applies in Austria, section 9).

3. What must the ROPA contain?

Art. 30(1) GDPR lists seven mandatory items (points (a)–(g)); two of them are required only 'where possible': the erasure periods (point (f)) and the general description of the technical and organisational measures (point (g)). Because point (c) bundles two items (categories of data subjects and categories of personal data), practice derives eight mandatory fields per processing activity from it — supplemented by the legal basis as a ninth field:

Set up these nine fields as the columns of your ROPA table — then each processing activity is a row, and you fill in fields 1 and 8 consistently across the company. The entries in the right-hand column are samples: which recipients, safeguards and periods you have to enter depends on your actual service provider and system landscape.

A separate, shorter catalogue applies to data processors: Art. 30(2) GDPR names four mandatory items (points (a)–(d)) — (a) the name and contact details of the data processor and of each controller on whose behalf it acts (where applicable the representative, where applicable the data protection officer), (b) the categories of processing carried out on behalf of each controller, (c) where applicable Third Country transfers including documentation of suitable safeguards, (d) where possible a general description of the technical and organisational measures under Art. 32(1).

Anyone who is both — controller for their own processing, data processor for that of others — maintains the two catalogues separately: the items under paragraph 2 must be maintained for each controller on whose behalf you act.

Austria: the same mandatory items; the differing national provisions are set out in section 9.

4. ROPA in Excel or as a tool?

For most SMEs a spreadsheet is enough: experience shows that a tool only pays off from around 50 processing activities, with multi-site or group structures, and wherever version control can no longer be managed manually.

Form: the GDPR does not prescribe a particular tool — what counts is content, currency and legibility. Art. 30(3) GDPR requires the record to be in writing, including in electronic form; an Excel spreadsheet meets this. Which supervisory authority is competent for you is set out in section 9. What remains decisive in every variant is an editable format and a recognisable version status — both recurring review points (section 7).

5. 8 steps to a ROPA ready to be produced

Eight steps lead from the empty table to a record ready to be produced: first gather, then clarify role and legal basis, then fill in data, recipients and periods, and finally link the technical and organisational measures and set the review. Each step states what to do, why it holds up and what it depends on.

1. Identify processing activities: workshop with all departments (HR, sales, marketing, IT, accounting, management). 14-station method: one processing activity per employee lifecycle stage, one per customer lifecycle stage. The result is the baseline set required by Art. 30(1) GDPR — a record of all processing activities. The departmental workshop is the practitioner method here; what is prescribed is the result, not the route to it.
2. Clarify the role: are we controller (Art. 4 no. 7) or data processor (Art. 4 no. 8) or joint controllers (Art. 26)? This classification determines whether the catalogue from paragraph 1 or from paragraph 2 has to be filled in, and which contract is needed alongside it.
3. Determine the legal basis: Art. 6(1)(a)-(f). Processing is only lawful if at least one of these six grounds is met. If an entry relies on consent, two further burdens arise: the demonstration of consent (Art. 7(1)) and withdrawal at any time, which must be as easy as giving consent (Art. 7(3)). For employee data in Germany, usually § 26 German Federal Data Protection Act (BDSG) (on the Austrian position, see section 9). For special categories (Art. 9): an additional legal basis — Art. 9(1) places these data under a general prohibition on processing that only the narrow exceptions in paragraph 2 can open.
4. Document data categories systematically: master data, contract data, communication data, usage data, location data — one row per category. Keep field 3 (data subjects) and field 4 (types of data) separate: both items come from point (c) but answer different questions — whose data as opposed to which data.
5. Recipients including Third Countries: for EU recipients a list of names is usually sufficient. Third Countries require a safeguard (SCC, DPF, BCR) — separate column. Note the provider, the country and the safeguard, not merely 'Third Country yes'. For every recipient that processes on your behalf, Art. 28 GDPR applies in addition: selection only from data processors providing sufficient guarantees (paragraph 1) and a contract with the minimum content of paragraph 3.
6. Erasure periods per category: retention obligations under the German Commercial Code (HGB)/German Fiscal Code (AO) (10 years), the German Social Code (SGB) (5 years), employment-law retention. Document any conflict with Art. 17 (erasure). A period belongs in the entry per data category, not as a blanket figure for the whole row; HGB, AO and SGB are German law; on the Austrian position, see section 9.
7. Reference to the technical and organisational measures: every entry refers to the measures concept (practitioner recommendation). No separate set of measures per processing activity — instead a reference to the central measures concept (Art. 32). Art. 30(1)(g) requires only a general description of the measures under Art. 32(1), and only 'where possible'; the reference to the central concept satisfies this and avoids duplicate maintenance.
8. Set the review cycle: annually + whenever something changes. Quarterly is recommended for continuously growing companies. Both intervals are practitioner recommendations, not statutory deadlines — the statutory anchor is the obligation to make the record available under Art. 30(4) GDPR (section 1). Triggers for an immediate update are new processing activities, new IT systems and new data processors.

6. 14 typical SME ROPA entries

These 14 entries cover the routine operations of an SME — from the payroll office to the work-equipment inventory. Behind each entry is a short note on what matters in it — with a source wherever a provision hangs off it; which entries you actually need depends on your systems.

Three of these entries are filled in here as sample rows — this is what a row looks like in the processing-specific fields from section 3; fields 1 and 8 apply consistently across the company:

1. Payroll (with the tax adviser) — filled in as a sample row above; the tax adviser is an independent controller, not a data processor: they appear as a recipient in field 5, and no data processing agreement under Art. 28 GDPR is needed for them.
2. Applicant management (own server or e-recruiting SaaS) — the 6-month period in field 7 is a practitioner figure from the first version. The statutory anchor behind it is the period for asserting claims: in Germany claims under § 15(1) or (2) AGG must be asserted in writing within two months, unless the parties to the collective agreement have agreed otherwise (§ 15(4) AGG); in Austria claims for refusal to establish an employment relationship must be asserted before the courts within six months of the rejection (§ 15 GlBG for Part I, § 29 GlBG for the remaining grounds of discrimination).
3. Newsletter distribution (Mailchimp/CleverReach/Brevo) — filled in as a sample row above; in Austria § 174 Austrian Telecommunications Act 2021 (TKG 2021) (unsolicited messages) applies in addition (section 9).
4. CRM customer master data (Salesforce/HubSpot/own database) — ongoing customer data management is regular processing and therefore uses up the exemption in Art. 30(5) GDPR (section 2).
5. Web analytics (Pirsch cookieless / Matomo / GA4) — where information is stored on or read from terminal equipment, § 25(1) German Telecommunications-Digital-Services Data Protection Act (TDDDG) requires consent in Germany on the basis of clear and comprehensive information; it is dispensable only in the two cases in paragraph 2 (sole purpose of transmitting a message, strict necessity for the service expressly requested). In Austria, § 165 TKG 2021 applies instead.
6. Video surveillance of the production hall / outdoor areas — where there is systematic large-scale monitoring of publicly accessible areas, a DPIA has to be examined (Art. 35(3) GDPR); in Austria the special image-recording rules in §§ 12, 13 DSG apply in addition (section 9).
7. Customer communication (email, telephone, chat) — separate by purpose instead of keeping it as a catch-all item; unspecific catch-all entries are on the list of errors (section 7).
8. Processing on behalf (data processed on our behalf by IT service providers) — here you are the controller (step 5). Conversely, if you process for others, the separate record under Art. 30(2) GDPR is added (section 3).
9. Supplier management (master data, contracts) — the data subjects here are contact persons on the supplier side; fill in field 3 and field 4 separately accordingly.
10. Complaint management (customers + internal reporting channel) — the internal reporting channel is mandatory in Germany from, as a rule, 50 employees (§ 12(1) sentence 1 and (2) German Whistleblower Protection Act (HinSchG)), in Austria from 50 employees (§ 3(1), § 11(1) Austrian Whistleblower Protection Act (HSchG)). In Germany the identity of reporting persons, of persons concerned and of other persons named in the report must be treated confidentially (§ 8(1) HinSchG); in Austria the identity of reporting persons and any information from which it can be derived must be protected, and disclosing the content or the identity to unauthorised persons is prohibited (§ 7(1) and (2) HSchG). Practitioner recommendation: a separate entry with a tightly limited group of recipients.
11. Cases of illness / occupational integration management (special categories Art. 9, § 167 SGB IX) — health data require the additional legal basis under Art. 9(2) GDPR (step 3); where the processing is large-scale, the DPIA threshold in Art. 35(3) GDPR has to be examined as well.
12. Time recording (employees, Federal Labour Court (BAG) mandatory ruling 2022) — in Austria it also has to be examined as a monitoring measure under § 96(1) no. 3 Austrian Labour Constitution Act (ArbVG) (section 9).
13. Vehicle fleet + GPS tracking (where used) — there is no dedicated DSG provision in Austria for employee tracking; what governs are Art. 6 and Art. 88 GDPR together with the Austrian provisions in section 9.
14. Work-equipment inventory (laptop, mobile, where personal data are involved) — the entry only arises once devices can be attributed to individual persons; record that attribution in the purpose field.

For online retail, eight typical shop processing activities have been worked out separately — each entry with purpose, legal basis and storage period, plus types of data and recipients where relevant: ROPA for e-commerce.

7. Avoiding 9 common errors

These nine errors come up again and again in audits — from the outdated recipient field to the document without a version status. Each point names the error and the correction:

1. Outdated recipient lists (old newsletter tools not removed) — field 5 must reflect the actual set of service providers; when a tool is replaced, the change belongs in the record and in the data processing agreement overview in the same move.
2. Missing erasure periods ('no specific details') — a specific period per data category, see step 6.
3. No Third Country note for US tools (Mailchimp, Google, Zoom) — field 6 needs provider, country and safeguard (step 5).
4. Processing on behalf confused with what is actually joint controllership — the role determines the contract (step 2).
5. No ROPA for the subsidiary GmbH — every company that is an independent controller maintains its own record.
6. 'Collective communication processing' — too unspecific; separate purposes can each be justified individually in a supervisory enquiry, a catch-all item cannot.
7. No reference to the measures concept, but the content of the measures in the ROPA (duplication) — the reference to the central measures concept is sufficient (step 7).
8. Format problems: PDF instead of an editable format (Excel/CSV) — the record has to be made available on request (Art. 30(4) GDPR); the editable format is a practitioner expectation of the authorities, not a formal requirement of the GDPR (section 4).
9. No versioning (which version is valid?) — record every update with a date and version status; otherwise, when an enquiry comes in, there is no way to show which version applies.

8. The ROPA in supervisory enquiries

In practical experience, the authority starts with the record and works its way from there to the follow-on documents. Order of review in practice:

1. ROPA — completeness, currency, plausibility (Art. 30(4) GDPR)
2. Data processing agreement — are all external data processors named in the ROPA? Is there an agreement in place for each of them? The benchmark is Art. 28 GDPR
3. Measures concept — appropriate to the risk profile of the processing? The benchmark is Art. 32(1) GDPR; the checklist on technical and organisational measures sets out the measures in detail
4. DPIA — carried out for the processing operations with a high risk? The triggers are the cases in Art. 35(1) and (3) GDPR

The order of review is at the same time the order of preparation: a complete record allows the data processing agreement list, the link to the measures and the DPIA candidates to be derived — but not the other way round.

In Germany, the competent authority for non-public bodies is the state data protection authority (Landesdatenschutzbehörde), for federal bodies the BfDI, and in Austria the Datenschutzbehörde (sources in section 9). Experience shows that supervisory authorities expect transmission within 1 to 2 weeks — an empirical figure, not a statutory deadline. If the enquiry follows a personal data breach, the notification deadlines in Art. 33(1) GDPR continue to run in parallel; the procedure for that is set out in Personal data breach notification 72h.

9. The legal position in Austria

The content of the record is identical in Austria — Art. 30 GDPR applies there with identical wording: the same mandatory items, no differing thresholds or deadlines. What differs are the national provisions that replace the German rules in individual entries:

• Supervision: under § 18(1) DSG the Datenschutzbehörde is the national supervisory authority pursuant to Art. 51 GDPR — a single central authority instead of the German split between the state authorities for non-public bodies (§ 40(1) BDSG) and the BfDI for federal public bodies as well as certain providers of telecommunications services (§ 9(1) BDSG).
• Employee data: the Austrian DSG has no dedicated employee data protection provision like § 26 BDSG. What governs are Art. 6 and Art. 88 GDPR, supplemented by § 12(4) no. 2 DSG and § 96(1) no. 3 ArbVG (monitoring measures affecting human dignity only with the consent of the works council or a works agreement).
• Image recordings: § 12 DSG governs the admissibility of video surveillance — inadmissible for monitoring employees (§ 12(4) no. 2 DSG, see above). § 13 DSG adds the labelling obligation (paragraph 5); retention lasting longer than 72 hours must be proportionate and has to be logged and justified separately (§ 13(3)).
• Data secrecy: § 6 DSG obliges controllers, data processors and their staff to maintain secrecy — an additional organisational building block; for processing on behalf itself, Art. 28(1) and (3) GDPR apply with no Austrian special rule.
• Cookies and newsletters: instead of § 25 TDDDG (German law), § 165 TKG 2021 applies to the setting of tracking cookies; for advertising emails, § 174 TKG 2021 applies in addition (consent, documented in practice via double opt-in).
• Retention periods: the periods named in field 7 and step 6 from the HGB, AO and SGB follow German law. For Austrian entries, the corresponding retention obligations under Austrian law have to be determined separately and entered per data category.
• Entries typical of Austria: an Austrian record contains processing activities such as the social insurance notification to the ÖGK, which do not appear in a German template.
• Data protection officer: without a ground under Art. 37, there is no obligation to designate one in Austria; the German 20-person threshold in § 38(1) BDSG is expressly worded as being "in addition to Article 37(1)(b) and (c)" GDPR and is therefore a German tightening.

The GDPR complete package for Austria covers the Austrian adaptations beyond the record.

10. Fine range for defects in the record

A defect in the record falls within the lower of the two GDPR fine ranges: Art. 83(4) GDPR covers, among other things, infringements of Art. 25 to 39 — including Art. 30 — with fines of up to EUR 10 million or — in the case of an undertaking — up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher. The national rows of the table apply alongside Art. 83 GDPR and each apply only within the legal area named: the fine and administrative penalty provisions (§ 43(2) and (3) BDSG, § 62(1) DSG) cover subject matter other than the record itself; § 11 DSG, by contrast, concerns the legal-consequences side of Art. 83 GDPR (reprimand instead of a fine):