GDPR Article 30: Complete Guide to Records of Processing Activities
Article 30 of the GDPR is five paragraphs long, and it generates more standing documentation than almost any other provision in the Regulation. It is the article that obliges controllers and processors to keep records of processing activities, in a prescribed structure, available to the supervisory authority on demand.
For the one-page definition of the obligation and how it fits the wider framework, start with our Article 30 framework page.
This guide is the legal reference: what each paragraph says, what each required field means in practice, and how the article is enforced. If you are starting from "what is this register and why do we keep one", read our plain-language explainer on Records of Processing Activities first and come back for the detail.
Five paragraphs, one obligation
The structure of Article 30 is worth holding in your head, because each paragraph does a distinct job:
| Paragraph | What it does |
|---|---|
| 30(1) | Lists the seven categories of information controllers must record |
| 30(2) | Lists the four categories processors must record, per controller |
| 30(3) | Requires the record to be in writing, including electronic form |
| 30(4) | Requires the record to be made available to the supervisory authority on request |
| 30(5) | Exempts some organisations with fewer than 250 employees, narrowly |
The UK GDPR carries Article 30 over unchanged, so the analysis below applies whether your supervisory authority is the ICO, the CNIL, the Irish DPC or any other EU authority.
Article 30(1): what controllers must record
For each processing activity, the controller's record must contain:
(a) Identity and contacts. The name and contact details of the controller and, where applicable, any joint controller, the controller's Article 27 representative and the Data Protection Officer. If two group companies jointly determine why customer data is processed, both belong in the record.
(b) The purposes of the processing. Purpose is the unit of the whole register. "Payroll administration", "candidate screening" and "marketing to prospects" are three activities with three entries, even if they share systems. An entry that reads "HR" fails at this field before an auditor reaches any other.
(c) Categories of data subjects and of personal data. Both categories, described specifically enough to trigger the right downstream obligations. "Employees: salary, bank details, National Insurance numbers, sickness records" tells you Article 9 special category data is present. "Employee data" hides it.
(d) Categories of recipients. Everyone the data has been or will be disclosed to, internal and external, including recipients in third countries. This is the field that catches your payroll bureau, your pension provider, your background screening vendor and the analytics platform your product team switched on last quarter.
(e) Third-country transfers. Where data goes to a third country or international organisation, the record must identify the destination, and for transfers relying on the second subparagraph of Article 49(1), document the suitable safeguards. In practice you should record the transfer mechanism for every listed transfer: adequacy decision, SCCs, or binding corporate rules. Transfers are also where a written register benefits most from a visual check; our data flow mapping guide shows how unrecorded transfers surface when flows are drawn rather than tabulated.
(f) Erasure time limits, where possible. The envisaged retention period for each category of data. "Where possible" softens the wording, not the expectation: regulators read a blank retention field as an Article 5(1)(e) storage limitation problem waiting to be found.
(g) Security measures, where possible. A general description of the technical and organisational measures under Article 32(1): encryption, access controls, MFA, audit logging. General means a genuine summary, not a copy of your entire security policy.
Article 30(2): what processors must record
Processors keep a leaner record, organised per controller they act for:
(a) The processor's own name and contact details, and those of each controller it processes for, plus any representative and DPO.
(b) The categories of processing carried out on behalf of each controller.
(c) Third-country transfers, with the same destination and safeguard documentation as for controllers.
(d) Where possible, a general description of Article 32(1) security measures.
The per-controller structure matters. An email agency serving ten clients maintains records against all ten, and the same firm almost always also holds controller records under 30(1) for its own staff, billing and marketing. Most businesses are both controller and processor, and need both records.
Article 30(3): in writing includes electronic
The record must be in writing, and electronic form counts. A spreadsheet satisfies Article 30(3). So does a database, or purpose-built software.
The paragraph sets a floor, not a recommendation. What it does not address is whether the format can be kept accurate, version-controlled and reviewable, which is where format choices actually succeed or fail. The legal form question and the maintainability question are different questions.
Article 30(4): available to the supervisory authority on request
There is no filing obligation and no submission deadline. You do not send your RoPA to anyone in advance. But when the supervisory authority asks, the controller, the processor or their representative must produce it.
In practice "on request" means "at the worst possible moment". The request typically arrives at the start of an investigation, an audit or a breach inquiry, when the authority uses the register to scope everything else it will ask for. A register you cannot produce quickly, or that contradicts what the investigation then finds, sets the tone for the whole engagement. The same register is also your scoping tool when a data subject access request lands, which is the more frequent test in practice.
Article 30(5): the exemption almost nobody qualifies for
Organisations with fewer than 250 employees are exempt, unless the processing:
- is likely to result in a risk to the rights and freedoms of data subjects, or
- is not occasional, or
- includes Article 9 special category data or Article 10 criminal offence data.
Any single trigger removes the exemption for that processing. And the second trigger does almost all the work: the Article 29 Working Party's 2018 position paper confirmed that regular activities such as payroll, HR administration and customer relationship management are not occasional, so records are required for them regardless of headcount. Sickness records alone put most employers into the third trigger too.
The honest reading is that Article 30(5) exempts specific activities, not organisations, and for any business that employs people or maintains customer accounts, the exempt activities are the trivial ones. Small firms that skip the register entirely on the strength of 30(5) are relying on a reading the regulators have already rejected.
Enforcement: a small fine tier that opens the big one
Article 30 breaches fall under Article 83(4)(a): fines up to 10 million euros or 2 percent of total worldwide annual turnover, whichever is higher. That is the lower of the GDPR's two fine tiers.
Standalone Article 30 fines are rare and mostly modest, with the Spanish AEPD responsible for much of what exists on the public enforcement trackers. The realistic cost sits elsewhere. Because the register is the first document requested under 30(4), a missing or fictional RoPA converts directly into accountability findings under Article 5(2), and the principles sit in the upper tier: 20 million euros or 4 percent. An absent register also lengthens investigations, weakens your breach notifications and undermines every DPIA you claim to have based on it. For how the register underpins those assessments, see when a DPIA is required and the wider RoPA vs DPIA vs DSAR comparison.
Jersey: the DPJL 2018 runs the same obligation in parallel
Jersey businesses are not subject to the UK GDPR. The Data Protection (Jersey) Law 2018 (DPJL 2018) applies, imposing an equivalent record-keeping duty on controllers and processors, enforced by the Jersey Office of the Information Commissioner, with the added Jersey-specific step of registering with JOIC directly.
The alignment is deliberate. Jersey has held EU adequacy since 8 May 2008 under Directive 95/46/EC, reaffirmed on 15 January 2024, and Jersey firms serving EU clients are frequently within EU GDPR scope as well under Article 3. Keeping the record to the full Article 30 standard satisfies both regimes at once, which is why it is the sensible default for any Island business with off-Island clients.
The article assumes maintenance; most registers assume completion
Read the five paragraphs together and a design intent emerges. The prescribed fields make the record comparable across organisations. The written-form rule makes it producible. The on-request rule makes it a standing obligation rather than a filing exercise. Article 30 describes a register that is always current, because the authority can ask for it on any given Tuesday.
That is the gap most compliance programmes fall into: they treat Article 30 as a document to finish rather than a record to keep. Clarium closes it by making the register the working system instead of the annual project. Processing activities are captured against the Article 30(1) and 30(2) fields, AI extraction turns plain-text process descriptions into structured entries with confidence scores, transfers are flagged on a visual map, and the formal record exports to PDF, CSV or UROPA JSON the day someone asks under 30(4). Plans start at £39 a month. See pricing.