GDPR Records of Processing: Article 30 Template

The Article 30 record of processing activities (often abbreviated ROPA) is the single document that turns "we comply with GDPR" into "we can prove we comply with GDPR". It is the inventory of every processing activity an organisation carries out, with enough detail to allow the supervisory authority to verify accountability without having to dig through individual systems.

This guide covers when the register is required, the differences between the controller and processor versions, the content each must contain, and a ready-to-fill template for a small organisation that does not yet have one.

The Article 30(5) exemption: read it carefully

A common misreading of GDPR is that businesses with fewer than 250 employees are exempt from the register obligation. The text of Article 30(5) is narrower: the exemption applies only when all three of the following are true:

1. The processing is occasional
2. The processing does not include special category data (Article 9) or criminal-offence data (Article 10)
3. The processing is unlikely to result in a risk to the rights and freedoms of data subjects

The conditions are cumulative, not alternatives. Any business with regular customer interactions, regular employee data, regular newsletter subscribers or regular website analytics fails the first condition (occasional). Most fail at least one of the others as well.

In practice, the small-business exemption applies to vanishingly few real organisations. The European Data Protection Board has consistently read the exemption strictly. Plan to maintain the register; treat the exemption as an edge case rather than the rule.

Controller vs processor register

Article 30(1) sets out the content of the controller register. Article 30(2) sets out the shorter content of the processor register. An organisation that acts as controller for some activities (its own customers, employees, marketing) and as processor for others (handling data on behalf of a client) must keep both.

Controller register (Art. 30(1))

For each processing activity, the controller register must contain:

• Name and contact details of the controller (and, where applicable, of the joint controller, the controller's representative and the data protection officer)
• Purposes of the processing
• Description of the categories of data subjects
• Description of the categories of personal data
• Categories of recipients to whom the personal data have been or will be disclosed
• Transfers of personal data to a third country or international organisation, including identification of the country and, for transfers under Article 49(1) second subparagraph, the documentation of suitable safeguards
• Envisaged time limits for erasure of the different categories of data, where possible
• General description of the technical and organisational security measures, where possible

Processor register (Art. 30(2))

For each processing carried out on behalf of a controller, the processor register must contain:

• Name and contact details of the processor and each controller on behalf of which the processor is acting (and, where applicable, of the controller's or processor's representative and the data protection officer)
• Categories of processing carried out on behalf of each controller
• Transfers of personal data to a third country or international organisation, including identification of the country and, for transfers under Article 49(1) second subparagraph, the documentation of suitable safeguards
• General description of the technical and organisational security measures, where possible

The processor register is shorter because the purposes, data subject categories and data categories are the controller's responsibility to document, not the processor's.

What a "processing activity" actually means

The GDPR does not define "processing activity" with surgical precision. The EDPB's working interpretation is that each distinct purpose-based grouping of operations is one activity. Examples for a small online shop:

• Customer purchase fulfilment
• Customer support enquiries
• Newsletter and direct marketing
• Employee payroll and HR
• Website analytics
• Server logs and security monitoring

Six processing activities, each with its own purpose, data categories, recipients and retention period. A larger organisation will have more; a sole trader with no employees will have fewer.

The mistake to avoid is collapsing distinct purposes into one row ("customers") or exploding one activity into dozens of micro-rows ("customer name", "customer email", "customer phone"). One row per purpose is the right grain.

Template: controller record

For each processing activity, fill in the following fields. A spreadsheet with one row per activity is sufficient.

Repeat the row for every distinct processing activity.

Sample second row: newsletter

Template: processor record

For each engagement where the organisation processes data on behalf of another organisation.

Common mistakes

Treating "Article 30 exempt" as the default. The exemption is narrow; most organisations are not in scope.

Mixing controller and processor activities in one register. The fields are different. Keep two sheets.

Listing systems instead of purposes. "Mailchimp", "Stripe", "Google Analytics" are not processing activities; they are recipients of data within an activity. The activity is "send newsletter", with Mailchimp as a recipient.

Retention periods missing. A retention period that says "as long as necessary" fails Article 13(2)(a) and surfaces in the register as well. Specific timeframes per category.

No update process. The register is correct at creation and stale six months later. Schedule a quarterly review and an update workflow whenever a new tool or supplier is added.

Special category data not flagged. Health, biometric, political opinion data require additional grounds under Article 9 and additional measures. Flag them explicitly in the register.

No transfer mechanism documented. A row that says "data goes to a US service" without naming the transfer mechanism (DPF, SCCs, BCRs) is incomplete. Document the mechanism, not just the destination.

How the register fits the wider GDPR programme

The register is the index that everything else points to:

• The privacy notice draws its content from the register (purposes, recipients, retention)
• The data processing agreement with each processor maps to a row in the register
• The data breach notification workflow uses the register to identify affected activities
• A data subject access request is fulfilled by walking the register and pulling data from each system mentioned
• A DPIA under Article 35 starts from the register entry for the activity being assessed

If the register is missing or stale, every downstream obligation becomes harder to perform. If the register is current and accurate, every downstream obligation becomes mostly mechanical.

For the broader compliance baseline, the GDPR compliance checklist covers the controls that surround the register.

Final checklist

• You have decided the exemption does not apply and you are maintaining a register
• You have separate sheets for controller and processor activities
• Each row represents one distinct purpose, not one tool
• Every required Article 30(1) field is populated for each controller row
• Every required Article 30(2) field is populated for each processor row
• Retention periods are specific timeframes per category
• International transfer mechanisms are named (DPF, SCCs, BCRs)
• Technical and organisational measures are described
• The register has a review owner and a quarterly review schedule
• The register can be produced in writing to the supervisory authority within the timeframe specified in any request

---

This is technical analysis, not legal advice. For complex group structures, joint controllership arrangements or active supervisory authority investigations, consult a lawyer who specialises in data protection.