Records of processing activities: Article 30 fields in plain terms
The register looks complicated only until you see it as a table with two dozen fields. Once you see it as a list of questions about one process, it becomes an afternoon's work.
In this article
The legal text — original source
The General Data Protection Regulation applies directly and identically in every member state. That is why we do not paraphrase its articles here: read the official text in your own language.
What the register actually is
The records of processing activities is an inventory of an organisation's data processes. It answers one question: what do we actually do with people's data. Not which documents we hold or which policies we approved, but what really happens day to day — what is collected, for what, where it is stored and to whom it is passed on.
The register is therefore not a legal text. It is a table whose rows are processes and whose columns are the same set of questions asked of each process.
All other documentation — internal policies, privacy notices, the contracts list — is written from it. Starting from the policies instead means writing about things you have not yet counted.
The example we will carry through the article
Take a process every organisation has: employee administration and payroll. It contains everything — a legal obligation, a contract, external service providers, long retention periods and more sensitive categories of data.
We now go field by field and fill each one in for this process. The same questions repeat for other processes: customer contracts, video surveillance, marketing, candidate screening.
Controller and contacts
The first fields are simple: who the data controller is, its contact details, its representative's details if one has been appointed, and the contact details of the data protection officer if the organisation has one. These fields are the same throughout the register, so they are filled in once.
It is worth listing a functional contact rather than a specific employee's personal address. Staff change, and the register must stay correct a year from now.
Purpose: the most important field in the whole table
The purpose explains why the data is collected. In our example there are actually several: performing the employment contract, calculating and paying salaries, meeting tax and social security obligations, and administering leave and working time.
A purpose must be narrow enough that a retention period and a legal basis can be derived from it. "Human resources management" is too broad: you cannot derive a retention period or a legal basis from it. If a single purpose covers both a tax obligation and staff performance appraisal, that is really two processes.
Legal basis
Each purpose is assigned a basis. In our example, calculating pay and reporting to authorities rest on a legal obligation, performing the employment contract rests on the contract itself, and, say, an employee's photo in an internal directory usually rests on consent or legitimate interest, depending on the situation.
The basis is not a decorative field. It determines what rights a person has: an objection can be raised against legitimate interest, consent can be withdrawn, and neither path is open for a legal obligation.
If the wrong basis is chosen, the privacy notice built on it is wrong too. See the list of bases at [TO CHECK: legal reference].
Data subjects and categories of data
In our example the subjects are employees and, in some cases, their family members — for instance when data is processed for extra leave or benefits. Categories are listed in groups rather than field by field: identity data, contact details, employment contract data, working time and pay data, bank account.
Special categories of data, if any, are flagged separately: health data from mandatory checks, disability information, trade union membership. This data later drives both stricter access controls and a more frequent need for impact assessments.
Recipients: who the data leaves the organisation for
Recipients are everyone who sees the data outside your organisation. In our example that means the accounting service or software provider, the bank, public authorities, the insurer, the medical organisation carrying out mandatory employee health checks, and sometimes an audit firm.
Every recipient prompts a second question: are they an independent controller or a processor. Processors require a contract, so the recipients list is in practice also a contract-checking list. This is usually where it turns out that one or two systems have no contract in place.
Transfers outside the European Economic Area
This field is often filled in wrongly, because people answer based on the supplier's registered office rather than where the data is actually kept. A cloud service with a European region can still have technical support on another continent, and that already counts as access.
If a transfer takes place, its basis and the safeguards applied must be recorded. If there is no transfer, that is also worth noting explicitly — a blank field does not distinguish "none" from "not checked".
Retention periods
A retention period is set not for the whole process but for each group of data. In our example, the employment contract and personnel file are kept for a long time under archiving requirements, working-time records for a shorter period, and everyday correspondence about schedules shorter still.
Every period should carry a reason: a legal requirement, the risk of a dispute, or an organisational decision. A period without a reason is just a number that can be neither defended nor reviewed.
Security measures
The last field asks for a general description of technical and organisational measures. There is no need to rewrite a security policy here: it is enough to name what is actually in place — role-based access rights, individual logins, two-factor authentication, encryption on portable devices, backups, confidentiality undertakings, training.
It helps to write down only what works today. A measure that is described but not implemented is worse than admitting it does not exist when an inspection happens.
How to know the register is finished
The register is finished when you can print it and explain every row to colleagues without extra questions. Every process has a purpose, a basis, categories, recipients, a retention period and measures, and open questions are marked as open rather than smoothed over with generic phrases.
After that, ordinary maintenance begins: a review whenever a system, supplier or process changes. Organisations that treat the register as a working tool spend a few dozen minutes on it each quarter. Organisations that forget it start almost from scratch again after two years.
How to split processes so there are not too many
A common question is whether payroll and personnel administration are one process or two. A practical test: if the purpose, basis, recipients and retention period coincide, it is one row; if at least two of these differ, it is worth splitting.
Splitting too finely also causes harm. A forty-row register in a small organisation is almost never more accurate — it is simply harder to maintain and therefore goes stale faster. Eight to fifteen well-described rows is a realistic target.
It helps to agree once on what counts as a row and stick to it. A register where one section is described by process and another by system stops being comparable with itself.
Where to gather the information
The fastest route is three conversations: with accounting, with administration, and with whoever runs the systems. In an hour each of them will tell you more than any document, because they know where the data actually sits.
A second source is the contracts list and invoices. These reveal every service provider, including the ones nobody remembered: the archiving service, document destruction, the marketing platform, the survey tool.
A third source is the systems themselves. A list of logins shows who has access, and often also that access is still held by people who changed roles or left the organisation long ago.
The most common mistakes in the register
First: a purpose copied straight from a statute. "Processing necessary for the performance of a contract" is a basis, not a purpose; the purpose is "issuing invoices and administering payments".
Second: a recipients field listing only public authorities while suppliers are forgotten. Third: a retention period of "as required by law" with no actual figure — such an entry allows neither deletion nor verification of the data.
Fourth: a register with no open questions at all. That almost always means not that everything is in order, but that awkward questions were papered over with generic phrases.
Using the register day to day
The register is a source of answers when something happens. A person asks for a copy of their data — the register shows which systems to search.
An incident occurs — the register shows its scope and the recipients affected. An inquiry arrives — the register is the first attachment.
It is also a procurement tool. Before rolling out a new system, it is enough to put the register's questions to the supplier: what data they will see, where it will be, who will have access, what happens once the contract ends. That is the best time to get answers.
Finally, the register is training material for new staff. Instead of twenty pages of policy, a person sees one table that makes clear what the organisation does with data and why.
National-law specifics
Some questions — employee data, the age of consent, national identification numbers — are left to individual member states to regulate. These rules differ, so get local legal advice on them.