GDPR Article 30 ROPA: Data Model and Fields Template

In one sentence. GDPR Article 30 ROPA requires a structured register with 8 mandatory fields for controllers (Article 30(1)) and 6 for processors (Article 30(2)), expandable to 14 fields total under EDPB Guidelines and good practice. The data model must be queryable per activity, per data category, per recipient, and per retention class — which is why a spreadsheet rarely survives a serious audit and a database schema is the de facto standard. See what moving off spreadsheets to automated compliance changes in practice.

The official template published by CNIL, ICO and most EU DPAs maps directly to these fields. The EUR-Lex reference is Regulation (EU) 2016/679, Article 30. For the full methodology around building and maintaining the register, see our complete GDPR ROPA guide.

Key takeaways

• 8 mandatory controller fields under Article 30(1)(a)-(g).
• 6 mandatory processor fields under Article 30(2)(a)-(d).
• Article 30 applies to every organisation except those under 250 employees with no risky or regular processing.
• ROPA must be made available to the supervisory authority on request (Article 30(4)).
• EDPB recommends additional fields for accountability (lawful basis, DPIA reference, breach log link).

1. Article 30(1) text — controller obligations

“Each controller and, where applicable, the controller’s representative, shall maintain a record of processing activities under its responsibility. That record shall contain all of the following information: (a) the name and contact details of the controller… (b) the purposes of the processing; © a description of the categories of data subjects and of the categories of personal data; (d) the categories of recipients to whom the personal data have been or will be disclosed including recipients in third countries or international organisations; (e) where applicable, transfers of personal data to a third country or an international organisation… and the documentation of suitable safeguards; (f) where possible, the envisaged time limits for erasure of the different categories of data; (g) where possible, a general description of the technical and organisational security measures referred to in Article 32(1).”

2. Mandatory controller fields (8)

What each field must actually contain

Field names are easy; the failure mode is filling them with abstractions. The table below gives, for each Article 30(1) requirement, the level of specificity a supervisory authority expects and a worked example taken from a single processing activity — “customer support ticketing” in a B2B SaaS company.

Two of these deserve emphasis because they are where registers most often become untrue. Free-text fields — ticket bodies, CRM notes, incident descriptions — routinely carry special category data that nobody planned to collect; a register that ignores them describes a system you do not operate. And retention expressed as a single figure for the whole activity is almost always wrong: different categories inside one activity age at different rates, which is why the field is drafted per category. Our GDPR data retention policy guide sets out how to derive those periods defensibly.

3. Mandatory processor fields (6)

Article 30(2) imposes a lighter register on processors, built around a different axis: not “what am I doing and why”, but “for whom am I doing it, and what kind of processing”.

1. Processor identity + DPO
2. Each controller for whom processing is performed
3. Categories of processing per controller
4. Third country transfers + safeguards
5. Security measures
6. Sub-processor list

Note what is absent. A processor does not record purposes, categories of data subjects, or retention periods — those belong to the controller, who determines them. This is not a drafting oversight; it reflects the allocation of responsibility that runs through the whole regulation and is worth understanding before you fill in either register. See controller vs processor for the test that decides which side you are on.

The practical difficulty is that most organisations are both, on different activities. A SaaS vendor is a controller for its own marketing, hiring, billing and product analytics, and a processor for the customer data inside its platform. The register must therefore be split into two sections, and a single row must never straddle both. A worked processor row looks like this:

The sub-processor list is the field auditors read first, because Article 28(2) requires the controller’s authorisation for each one. A register naming a sub-processor absent from your published list, or absent from the Article 28 contract chain, is a documented contractual breach.

4. EDPB-recommended additional fields

Beyond mandatory, EDPB Guidelines and accountability practice add:

• Lawful basis (Article 6) per activity
• Special category basis (Article 9(2)) if applicable
• DPIA reference (Article 35)
• LIA reference (legitimate interest assessment)
• Breach log link (Article 33)
• Consent management mechanism
• Data source (collected from subject, obtained from third party)
• Automated decision-making flag (Article 22)

5. Recommended database schema

processing_activity
  id, name, purpose, lawful_basis, special_category_basis,
  controller_id, joint_controller_ids[], processor_ids[],
  data_subject_categories[], personal_data_categories[],
  recipient_categories[], third_country_transfers[],
  retention_rules[], security_measures_ref,
  dpia_id, lia_id, automated_decision boolean,
  created_at, updated_at, owner_id

This schema satisfies Article 30 + EDPB recommendations and is what serious tools deploy.

6. Article 30(5) exemption

The under-250-employees exemption is not a blanket exemption. It excludes:

• Processing that is regular (i.e. not occasional)
• Processing likely to result in a risk to rights and freedoms
• Processing of special categories (Article 9)
• Processing of criminal data (Article 10)

Read the provision carefully: the headcount threshold is a gate, not the test. Once you are under 250 employees you still lose the exemption if any one of those four conditions is met — and the conditions are drafted disjunctively, so a single risky activity pulls the whole organisation back into scope for that activity.

The decisive word is “occasional”. The EDPB’s predecessor, the Article 29 Working Party, took the position that processing which forms part of the ordinary, repeated activity of the organisation is not occasional, whatever its volume. Apply that to a ten-person company and the exemption collapses almost immediately:

That is why the honest answer to “does my 12-person startup need a ROPA?” is yes, for payroll alone. The realistic reading of Article 30(5) is that it exempts specific activities that are genuinely one-off and low-risk, not organisations. Recital 13 explains the intent — reduce administrative burden on small entities — but the operative text never turns that intent into a size-based waiver. Where the exemption does bite, it bites narrowly, and the effort saved by invoking it is smaller than the effort of proving you were entitled to.

7. Format, retention and availability

Article 30(3) requires the record to be in writing, including in electronic form. Nothing more: there is no prescribed schema, no filing obligation, no template you must adopt. That freedom is the trap — the format is your problem, and the authority judges the result, not the tool.

Article 30(4) requires the record to be made available to the supervisory authority on request. In a French or UK inspection this means during the visit, in a readable form, without a week of preparation. Practical consequences worth designing for:

• Export on demand. Whatever system holds the register must produce a complete, dated PDF or spreadsheet in minutes. A register that only exists inside a tool nobody but the DPO can operate fails the availability test in substance.
• Versioning. Keep dated snapshots. The question in an investigation is rarely “what does your register say today” but “what did it say when the breach happened”. Without version history you cannot answer, and the burden under Article 5(2) is yours.
• Retention of the record itself. The GDPR sets no period. Keep it for the life of each processing activity and then for the limitation period applicable to enforcement and civil claims — five years is a defensible floor, longer where the activity touched health or employment data.
• Language. The authority may require the record in the national language. A group-wide English register is fine, provided a translated extract can be produced for the local entity.

There is no separate fine for a missing register; it is sanctioned under Article 83(4) alongside the other accountability obligations, at up to 10 million euros or 2% of global turnover. In practice its absence functions less as a standalone offence than as an aggravating factor and an investigative lever: an organisation that cannot produce its register invites the authority to verify everything else by hand. If you want a ready-made starting structure rather than building the schema yourself, use our ROPA template.

8. Worked example: SaaS billing activity

9. Common compliance failures

• Using a static Excel file that no one updates
• Missing the third-country transfer column
• Generic “appropriate security” instead of measurable controls
• No link between ROPA and DPIA register
• Failure to separate controller vs processor activities

10. Update cadence

EDPB recommends review at least annually, plus on:

• New processing activity launch
• New processor onboarding
• Material change in data flows
• Post-breach review

11. How a DPA actually reads your ROPA

Regulators do not grade a ROPA on how polished it looks; they test whether it is true and current. Both the CNIL and the ICO publish official Article 30 templates, and in an inspection they cross-check the register against reality: they pick one processing activity, ask to see the actual data flow, and compare it to what the ROPA claims. Three questions expose most weak registers.

The register is a living accountability artefact under Art. 5(2), not a one-off deliverable. Treat it as the index to your entire compliance programme: every DPIA, every processor contract, every retention rule should be reachable from a row in the ROPA. A register that a reviewer can trust on a single spot-check is worth more than an exhaustive one that quietly contradicts your production systems, so prioritise accuracy and freshness over cosmetic completeness when the two compete.

12. Tooling

Whichever route you take, the register is the entry point to the rest of the programme rather than a deliverable in itself — it is the artefact every other obligation hangs off, which is why our GDPR compliance guide for 2026 treats it as step one rather than a documentation chore.

FAQ

What fields are mandatory in a GDPR Article 30 ROPA?

8 fields for controllers (Article 30(1)(a)-(g)): identity, DPO, purposes, data subject categories, personal data categories, recipient categories, third-country transfers, retention periods, security measures. 6 fields for processors (Article 30(2)).

What’s the difference between Article 30(1) and Article 30(2)?

30(1) covers controllers (8 fields, including purposes and lawful basis context). 30(2) covers processors (6 fields, focused on which controllers and what categories of processing).

Is a spreadsheet enough for Article 30?

Legally yes, practically no. Once you have more than 20 activities, multiple processors, and DPIA cross-references, a database schema is the only sustainable model.

Do small businesses need a ROPA?

Article 30(5) exempts organisations under 250 employees only if processing is occasional, low-risk, and excludes special categories. Almost no SaaS/e-commerce qualifies.

Where can I find an official ROPA template?

CNIL, ICO, and Garante publish official templates. The EUR-Lex source is Regulation (EU) 2016/679, Article 30.