Article 30 (RoPA) Template

An Article 30 template is the structured set of fields a Record of Processing Activities (RoPA) must contain under the EU and UK GDPR. Article 30(1) sets out the mandatory content for a controller record and Article 30(2) a parallel set for a processor record — so a usable template is really two field lists, one for each role, not a single generic form. Getting the fields right is the easy half. A template is only useful if it stays current: the record a supervisory authority reads has to match what the business actually does today, not what someone typed at the last annual review. This guide enumerates both field lists in full, explains the controller-versus-processor split, and covers how to fill the template and keep it true.

What fields must an Article 30 template include?

The fields are fixed by the text of Article 30, so a correct template starts from the Regulation rather than from a vendor's form. A controller recordunder Article 30(1) must contain the following eight content elements:

1. Name and contact details of the controller and, where applicable, the joint controller, the controller's representative, and the data protection officer.
2. The purposes of the processing.
3. The categories of data subjects.
4. The categories of personal data.
5. The categories of recipients to whom the personal data has been or will be disclosed, including processors and recipients in third countries or international organisations.
6. International transfers: transfers of personal data to a third country or an international organisation, identifying that country or organisation and, for transfers under Article 49(1) second subparagraph, the documentation of suitable safeguards (the Chapter V safeguards relied on).
7. The envisaged retention periods (time limits for erasure) for the different categories of data, where possible.
8. A general description of the Article 32 technical and organisational security measures, where possible.

A processor recordunder Article 30(2) is a parallel but shorter list. A processor maintains, for each controller it acts on behalf of:

1. Name and contact details of the processor (and each processor), of each controller on whose behalf the processor acts, of the controller's or processor's representative where applicable, and of the data protection officer.
2. The categories of processing carried out on behalf of each controller.
3. International transfers to a third country or international organisation, identifying that country or organisation and, for Article 49(1) second-subparagraph transfers, the documentation of suitable safeguards.
4. A general description of the Article 32 technical and organisational security measures, where possible.

The two lists are deliberately kept separate above rather than bundled into one table, because the difference between them is the most common place a template goes wrong — the processor list is not a trimmed copy of the controller list, and an organisation that plays both roles needs both records.

What is the difference between a controller and processor RoPA template?

The split follows the legal role. A controllerdecides why and how personal data is processed, so the Article 30(1) template documents the reasons: the purposes, the categories of data subjects and personal data, the recipients, transfers, retention and security. A processoracts only on a controller's instructions, so the Article 30(2) template documents the service: who it processes for, the categories of processing it performs for each controller, any transfers and safeguards, and its security measures.

That is why the processor list omits purposes, data-subject categories and retention periods — those are the controller's determinations, not the processor's. Many organisations are controllers for some activities (their own employees and customers) and processors for others (services they run on behalf of clients), and they need both record types. The RoPA requirements guide for Ireland and the UK sets out how the DPC and ICO treat each role.

Is a spreadsheet template enough?

A spreadsheet template is a reasonable way to capture the fields, and for a very small, stable organisation it can be the whole record. Its limit is not the fields but the provenance: a spreadsheet stores only what someone last typed, and it cannot show where a value came from, who approved it, or what changed since the last review. Those are the first questions a Data Protection Commission (DPC) or Information Commissioner's Office (ICO) audit asks, and a register that has drifted out of date reads as weak Article 5(2) accountability rather than compliance.

The practical move is to keep the same Article 30 fields but manage them as a governed registerrather than a static file — one that keeps each field's source, approval chain and version history, and surfaces records for review when the business changes. That is what the Acompli RoPA management module does: it maintains the controller and processor records as a living register so the template stays true between reviews, not just on the day it was filled in.

How do you fill and maintain an Article 30 template?

Filling the template once is straightforward; keeping it accurate is the real work. A workable approach runs in four steps:

• Scope by entity and role: decide whether each legal entity is a controller, joint controller or processor for the activity, because that determines which field list applies.
• Map each field to its source: complete every mandatory field from the assessment, contract or system that produced it — a DPIA, a legitimate-interests assessment, a vendor review — rather than from memory, so each value can be substantiated.
• Assign an owner and approve: attribute each record to a named owner and route it through a human review before it is treated as the record of truth.
• Maintain between reviews: re-open the affected records when an upstream fact changes — a new supplier, a retired system, an updated transfer safeguard — so the register tracks the business rather than drifting until the next annual review.

This is where software earns its place over a file. In Acompli, approved assessments feed an AI extraction step that drafts and classifies the Article 30 fields with a link back to the source response, and a named reviewer approves, edits or rejects each draft before it reaches the register — the AI drafts and surfaces; a person approves, and nothing publishes itself. For a step-by-step walkthrough of building the first record, see how to create a RoPA, and see RoPA software: what it is and what to look for for how a tool should hold these fields.

Common questions about the Article 30 template

Primary sources

1. GDPR Article 30 (EUR-Lex, Regulation (EU) 2016/679)
2. DPC — Records of Processing (Article 30) Guidance
3. ICO — What do we need to document under Article 30?

Related research