Article 30 of the GDPR requires a record of processing activities, usually called a RoPA. A supervisory authority can ask for it at any time, and enterprise customers' privacy teams want to know it exists. It is also a document that is easy to build once, in a spreadsheet, and never open again.
A stale record costs more than it looks. The RoPA is the index the rest of your privacy program hangs from. DPIAs, transfer assessments, retention rules, and data subject requests all start from it. If it is wrong, they inherit the error.
This article covers what Article 30 requires, how to structure the record so it stays usable, how to gather the content, and how to keep it current.
Who has to keep one
Article 30 applies to controllers and processors, and to their representatives where they have one. Article 30(5) exempts organizations with fewer than 250 employees, but the exemption is narrow. It does not apply where the processing:
is likely to result in a risk to the rights and freedoms of data subjects,
is not occasional, or
includes special categories of data under Article 9(1), or personal data relating to criminal convictions and offenses under Article 10.
Almost every company processes some personal data regularly: payroll, customer accounts, support tickets. The Article 29 Working Party's position paper on the exemption read it accordingly. A small organization still records its non-occasional processing, even if it can leave genuinely occasional activities out. If you are building a privacy program at all, plan on keeping a record.
What a controller's record must contain
Article 30(1) lists the contents for controllers. In plain terms:
Who you are. The name and contact details of the controller and, where applicable, any joint controller, the controller's representative, and the data protection officer.
Purposes. Why the processing happens.
Who and what. A description of the categories of data subjects and the categories of personal data.
Recipients. The categories of recipients the data has been or will be disclosed to, including recipients in third countries or international organizations.
Transfers. Where applicable, transfers to a third country or international organization, identifying it, and for transfers under the second subparagraph of Article 49(1), documentation of suitable safeguards.
Retention. Where possible, the envisaged time limits for erasure of the different categories of data.
Security. Where possible, a general description of the technical and organizational security measures referred to in Article 32(1).
The record must be in writing, which includes electronic form (Article 30(3)). You must make it available to the supervisory authority on request (Article 30(4)).
What a processor's record must contain
Processors keep a shorter record under Article 30(2):
the name and contact details of the processor, of each controller it acts for, and, where applicable, of their representatives and the DPO,
the categories of processing carried out on behalf of each controller,
transfers to third countries, with the same Article 49 documentation where relevant, and
where possible, a general description of the security measures.
Most B2B SaaS companies need both. You are a processor for the data your customers put into your product, and a controller for your own employees, sales contacts, marketing lists, and billing. Keep the two records separate. They answer different questions, change at different times, and have different owners.
Structure it by purpose, not by system
The most common structural mistake is to build the record as a list of applications. A system inventory is useful, but it is not a record of processing. Article 30 is organized around purposes, and one system usually serves several.
Your CRM, for example, might support sales prospecting, account management, and renewals. Each purpose can have a different lawful basis, different data subjects, and a different retention period. If the row is "CRM", there is nowhere to record those differences.
A workable row is one processing activity: one purpose, carried out for one group of data subjects. Each row then lists the systems involved. A starting set of columns:
| Column | Example content |
|---|---|
| Activity and purpose | Send onboarding and billing emails to customer administrators |
| Business owner | A named role, not a team |
| Data subjects | Customer administrators |
| Data categories | Name, work email, job title |
| Lawful basis | Contract, or legitimate interests with a link to the assessment |
| Systems | Each system the data passes through |
| Recipients | Email delivery provider, payment processor |
| Transfers | Destination country and the transfer mechanism |
| Retention | A period, or the criteria that set it |
| Security measures | A reference to your control set |
| Linked assessments | DPIA or transfer impact assessment, where one exists |
The lawful basis column is not required by Article 30, but you need the answer for your privacy notice and for data subject requests. Choosing it is covered in the six GDPR lawful bases. Holding it in the same row saves maintaining a second document.
For security measures, reference your existing control set rather than writing new prose for every row. If you already run an information security management system, the controls you have selected describe your measures more precisely than a paragraph could. The ISO 27701 framework page explains how a privacy extension builds on that foundation.
How to gather the content
Do not try to write the record from documentation alone. The people who run each process know what actually happens to the data.
List your business functions. Sales, marketing, support, engineering, finance, HR, and security are the usual starting set. Each is a likely source of several activities.
Interview each function owner with the column list in hand. Ask what personal data they handle, why, where it goes, and how long they keep it.
Check against your vendor list. Every vendor that touches personal data is a recipient in at least one row. A vendor with no matching row means a missing activity.
Check against your systems inventory. Same test: a system holding personal data with no row is a gap.
Assign an owner to each row, by role, who confirms it at every review.
Steps 3 and 4 are where missing activities surface. People forget processing they do not think of as "data work": call recordings, applicant tracking, expense receipts, security logs, and the spreadsheet a team lead keeps on the side.
Keeping it accurate after year one
A record is accurate on the day it is finished and decays from there. Three habits keep it current.
Tie it to change. Vendor onboarding, new product features, and new internal tools should each ask, as a required step, whether the change creates or alters a processing activity. That one question catches most drift at the moment it happens.
Review on a cycle. Each row owner confirms or updates their rows at a stated interval. Annual is a common choice. What matters is that the interval is written down and met.
Keep history. Record when each row changed and who approved the change. When a regulator or a customer asks what you were doing at a point in time, a dated version answers it. An overwritten spreadsheet does not.
What people get wrong is treating the record as an artifact with no users. If your data subject request process, your DPIA screening, and your vendor reviews all read from it, errors get noticed and corrected. If nobody reads it, nobody notices.
The effort is also reused. A current record supports the privacy commitments your customers ask about in security reviews, and gives you the starting point for transfer assessments when data leaves the EEA.
How TrustLynce helps
TrustLynce's data privacy workflows keep the record of processing as structured, versioned rows linked to the DPIAs and transfer assessments that depend on them. Third-party risk management keeps the vendor inventory you check the record against.