A record of processing activities (RoPA) is the internal inventory an organisation keeps of what it does with personal data: each activity, why it happens, whose data is involved, who receives it, where it goes, how long it is kept, and how it is protected. Article 30 of the General Data Protection Regulation (GDPR) makes maintaining that record an obligation in its own right, independent of whether anything has gone wrong.
It is also, in practice, the first document a supervisory authority asks for. Article 30(4) requires you to make the record available to the authority on request, which means it is not a document you assemble after the letter arrives. This article walks through what Article 30 actually requires field by field, who is genuinely exempt, and which parts of the record decay without anyone touching them.
Where the obligation comes from
Article 30 GDPR sets out two separate record-keeping duties. Article 30(1) applies to controllers, who decide the purposes and means of processing. Article 30(2) applies to processors, who process on a controller's behalf. Most organisations are both: a controller for their own employee and customer data, and a processor for whatever their customers put into their product. If that describes you, you owe two records, not one.
Article 30(3) requires the record to be in writing, including in electronic form. Nothing prescribes a format, which is why a spreadsheet is technically sufficient and why so many registers are spreadsheets. Article 30(4) requires you to make it available to the supervisory authority on request. Taken together, the obligation is not to produce a beautiful document; it is to be able to produce an accurate one on demand.
What a controller record must contain
Article 30(1) lists seven items. Read closely, they are less demanding than most templates suggest, and more demanding in two specific places.
Controller identity and contacts
The name and contact details of the controller and, where applicable, the joint controller, the controller's representative, and the data protection officer. This is the one section that is genuinely static. Set it once and revisit it when your corporate structure or your DPO changes.
Purposes of the processing
Why the activity happens, stated per activity rather than as a general mission statement. "Payroll administration" is a purpose. "Business operations" is not, because it does not let a reader judge whether the data being processed is proportionate to the reason it is being processed.
Categories of data subjects and categories of personal data
Whose data, and what data. Categories, not individual records: employees, job applicants, customers, prospects, on one side; contact details, employment history, usage data, support correspondence, on the other. This is where organisations discover activities nobody had written down, because listing the data forces someone to ask where it came from.
Note the interaction with Article 30(5) below. If an activity involves special categories of personal data under Article 9(1), or criminal-offence data under Article 10, that fact matters twice: it belongs in this section, and it removes any possibility of relying on the small-organisation exemption.
Categories of recipients
The categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries or international organisations. The text says categories, so naming every individual vendor is not strictly required by Article 30(1)(d) itself.
In practice, most privacy teams name the actual recipients anyway, for two reasons. First, a category like "cloud service providers" tells a reviewer almost nothing and tells your own team even less. Second, Article 15(1)(c) gives data subjects the right to know the recipients or categories of recipients of their data, and the Court of Justice has read that right in the data subject's favour, so a register that already holds names makes access requests substantially easier to answer.
Third-country transfers
Where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or organisation, and, for transfers relying on the second subparagraph of Article 49(1), the documentation of suitable safeguards.
This is the asymmetry worth noticing. For recipients, the Regulation accepts categories. For transfers, it asks you to identify the destination. You cannot answer at category level here, and the destinations are frequently determined by parties other than you.
Retention periods
Where possible, the envisaged time limits for erasure of the different categories of data. The qualifier is real: some retention periods depend on external factors such as limitation periods or an ongoing dispute. Where a fixed period genuinely cannot be stated, record the criteria used to determine it instead of leaving the field blank.
Security measures
Where possible, a general description of the technical and organisational security measures referred to in Article 32(1). General is the operative word. This is a summary that lets a reader understand the posture of the activity, not a copy of your security policy.
What a processor record must contain
Article 30(2) is shorter, and it is the record most software companies neglect because they think of themselves only as controllers.
- The name and contact details of the processor, of each controller on behalf of which the processor acts, and where applicable of representatives and the data protection officer.
- The categories of processing carried out on behalf of each controller.
- Where applicable, transfers to a third country or international organisation, with the destination identified, and safeguards documentation for transfers relying on the second subparagraph of Article 49(1).
- Where possible, a general description of the technical and organisational security measures under Article 32(1).
The practical difficulty is the first item. If you have hundreds of customers, each one is a controller you process for. Most processors handle this by recording controllers at the level of the customer register rather than restating every customer inside the RoPA, and by describing categories of processing per product or service line rather than per customer. What matters is that the record can answer, for any given customer, what you do with their data and where it goes.
The exemption almost nobody qualifies for
Article 30(5) is the most misread provision in the Article. It says the record-keeping obligation does not apply to an organisation employing fewer than 250 persons, and then attaches three exceptions. The obligation returns if any one of them applies:
- the processing is likely to result in a risk to the rights and freedoms of data subjects;
- the processing is not occasional; or
- the processing includes special categories of data under Article 9(1), or personal data relating to criminal convictions and offences under Article 10.
The second limb is the one that matters. Paying your own staff is not occasional. Maintaining a customer database is not occasional. Running a support inbox is not occasional. The Article 29 Working Party position paper on the derogation confirmed the narrow reading: what falls outside the duty is the occasional processing, not the organisation. An organisation under the threshold is therefore usually exempt only for its genuinely irregular activities, and still owes a record for everything routine.
The honest conclusion for a small or mid-sized company is that Article 30(5) rarely removes the obligation. It reduces its scope at the margins.
The two fields that go stale on their own
Five of the seven controller fields change only when you change something. You add a purpose, you hire a DPO, you revise a retention schedule. These are self-inflicted updates, and a quarterly review catches them.
Two fields do not behave that way. Categories of recipients under Article 30(1)(d) and third-country transfers under Article 30(1)(e) depend on facts owned by your vendors. When a processor you rely on adds a subprocessor, replaces one, or moves a workload to a different region, your register becomes inaccurate at that moment. Nobody in your organisation made a decision. Nothing in your own systems changed. The record simply stopped describing reality.
This is why registers that are reviewed on a calendar drift anyway. The review interval is set by your process; the change is triggered by someone else's. A quarterly cycle means an inaccurate transfer field can sit in your register for up to three months, and you will not know which weeks were wrong.
The transfer field is the more serious of the two, because it feeds the rest of your transfer framework. A new subprocessor in a country that was not previously in scope changes what Article 30(1)(e) should say, and it may also mean an existing transfer assessment no longer covers the transfer it was written for. Whether a new destination triggers a fresh assessment is a separate question, covered in when a Transfer Impact Assessment is required. What to do when a subprocessor moves data outside the EEA is covered in subprocessors and third-country transfers.
Keeping the register accurate
Three habits separate registers that survive scrutiny from registers that are rewritten in a panic.
Give every activity an owner. Not the privacy team, the business owner who actually runs the activity. The privacy team maintains the register; it does not know when marketing changes an email platform. An unowned record is a record nobody updates.
Record when each activity was last reviewed and when it is next due. A register with no dates cannot be triaged, because everything looks equally current. Dates let you answer the only question that matters under Article 30(4): how confident are you that this reflects today.
Treat vendor changes as review triggers, not as background noise. A new subprocessor on a processor you rely on is an event that should reach whoever owns the affected activities, in the same way a new hire reaches HR. If the only mechanism is somebody remembering to re-read a vendor's subprocessor page, the register is accurate by luck. Which vendor changes force a register update, and which do not, is covered in keeping RoPA records accurate as vendors change.
Common mistakes
- Confusing the register with a data map. A data map traces flows through systems. A RoPA documents activities against the Article 30 fields. The two overlap and are not substitutes, and a diagram does not answer Article 30(4).
- Writing purposes as mission statements. "Improving customer experience" covers everything and specifies nothing. A reviewer reads it as an unwillingness to look closely.
- Skipping the processor record. Article 30(2) is a separate obligation with a separate field list, and a controller register does not discharge it.
- Assuming the under-250 exemption applies. It applies to occasional processing, and almost nothing routine qualifies.
- Leaving the transfer field to a template. "May involve international transfers" identifies no destination and does not satisfy Article 30(1)(e).
- Reviewing on a calendar only. Interval review catches your own changes. It does not catch your vendors'.
Frequently asked questions
Is a spreadsheet good enough?
Formally, yes. Article 30(3) requires writing in electronic form and prescribes nothing further. The difficulty is not the format but the maintenance: a spreadsheet has no owners, no review dates, no history of what changed, and no connection to the vendor facts that make two of its fields go out of date. Many registers stay in spreadsheets successfully; they do it by adding those things around the spreadsheet.
Do we need to name every subprocessor in the register?
Article 30(1)(d) asks for categories of recipients, so naming each one is not compulsory under that provision alone. Naming them is usually the better choice, because it makes Article 15 access requests answerable and because it is the only way the register reflects which destination countries are actually in play under Article 30(1)(e).
How often should the register be reviewed?
The Regulation sets no interval. A common pattern is an annual or semi-annual review of the whole register, a shorter cycle for high-risk activities, and event-driven review whenever an activity's vendors, purposes, or data categories change. The interval is a floor, not the mechanism.
Who owns the register?
The controller does, as a matter of accountability under Article 5(2). Internally, the workable split is a privacy owner who maintains the register and business owners who are accountable for individual activities. A DPO, where one is designated, monitors compliance under Article 39 rather than maintaining the record as a clerical task.
What happens if the register is out of date when an authority asks?
Article 30(4) obliges you to make the record available. An inaccurate register is not automatically a separate infringement, but it undermines the accountability principle in Article 5(2) and it tends to be the document that reveals other gaps, because the fields it gets wrong point directly at processing that was never assessed.
Where DPAFlow fits in
DPAFlow does not make legal determinations and does not provide legal advice. What it addresses is the maintenance problem described above.
The RoPA builder holds Article 30-style records with their purposes, data categories, data subjects, retention, security summary, owner, and review dates in one place, and exports each record, or the whole register, as a review-ready document. Recipients on a record can be linked to the vendors your workspace already monitors, so the Article 30(1)(d) entry points at a live subject rather than a name typed once.
That linkage is what changes the two volatile fields. Because DPAFlow monitors vendor subprocessor and legal pages on a recurring schedule and captures dated evidence of what changed, a detected subprocessor change on a linked vendor flags the affected processing activities for re-review and records which monitored event caused the flag. The register stops depending on somebody remembering to check. The judgement about what the change means stays where it belongs, with your team.