A record of processing activities (ROPA) is the one piece of data mapping the GDPR spells out field by field. This article lists those fields for controllers and processors, gives you a template you can copy, explains why the small-company exemption rarely helps, and covers what US state laws ask for instead.
For the bigger picture (inventories, flow maps, automated discovery and how a map feeds other work) start with the data mapping and discovery guide. This post stays close to the record itself.
What Article 30 requires
Article 30 of the GDPR has five paragraphs. Paragraph 1 lists what a controller's record must contain. Paragraph 2 lists what a processor's record must contain. Paragraph 3 says the records must be in writing, which includes electronic form. Paragraph 4 says the record must be made available to the supervisory authority on request. Paragraph 5 is the exemption for smaller organizations, covered below.
Two practical consequences follow from paragraphs 3 and 4. First, a spreadsheet is a perfectly lawful format. Second, the audience is a regulator, which means the record should be readable by someone who does not know your internal system names. Write "customer support ticketing (vendor: X)" rather than "the Zen instance".
Missing or deficient records fall under the lower tier of GDPR fines in Article 83(4), up to €10 million or 2% of worldwide annual turnover, whichever is higher. In practice, a missing ROPA tends to appear alongside other findings in an investigation rather than on its own, but it is also one of the first documents an authority asks for.
Controller records, Article 30(1)
| Point | What the record must contain | Notes |
|---|---|---|
| (a) | Name and contact details of the controller and, where applicable, any joint controller, the controller's representative and the data protection officer | Usually the same for every row; put it in a header block. |
| (b) | The purposes of the processing | Specific: "processing payroll and statutory tax filings", not "HR". |
| (c) | A description of the categories of data subjects and of the categories of personal data | Use a controlled list so categories are consistent across rows. |
| (d) | The categories of recipients to whom the data have been or will be disclosed, including recipients in third countries or international organizations | Includes processors (your vendors), not just independent third parties. |
| (e) | Where applicable, transfers to a third country or international organization, including identification of that country or organization and, for transfers under the second subparagraph of Article 49(1), documentation of suitable safeguards | Name the country and the transfer mechanism (adequacy decision, standard contractual clauses, and so on). |
| (f) | Where possible, the envisaged time limits for erasure of the different categories of data | "Where possible" is not a free pass; regulators expect a retention rule or a reason there isn't one. |
| (g) | Where possible, a general description of the technical and organizational security measures referred to in Article 32(1) | A summary or a link to your security documentation is enough; see security controls for personal data. |
Processor records, Article 30(2)
| Point | What the record must contain |
|---|---|
| (a) | Name and contact details of the processor or processors and of each controller on whose behalf the processor is acting, and, where applicable, the controller's or processor's representative and the data protection officer |
| (b) | The categories of processing carried out on behalf of each controller |
| (c) | Where applicable, transfers to a third country or international organization, with the same identification and safeguard documentation as for controllers |
| (d) | Where possible, a general description of the technical and organizational security measures referred to in Article 32(1) |
Processor records are organized by customer (controller), not by purpose. A SaaS company is usually both: a controller for its own HR, sales and marketing, and a processor for the customer data it hosts. It needs both kinds of record. Its processor record often lines up with its data processing agreements and sub-processor list, since many customers sign the same standard terms.
A copyable ROPA template
The template below covers every Article 30(1) item plus a few operational columns (marked "recommended") that make the record useful for day-to-day work. One row per processing activity. Copy the table into a spreadsheet and keep the column order.
| Column | Art. 30(1) | Example entry |
|---|---|---|
| Activity ID | recommended | PA-014 |
| Processing activity | (b) | Recruiting and candidate assessment |
| Business owner | recommended | Head of Talent |
| Purpose(s) | (b) | Assess applicants for open roles; communicate with candidates; keep a talent pool with consent |
| Legal basis | recommended (needed for notices) | Steps prior to a contract, Art. 6(1)(b); consent for talent pool, Art. 6(1)(a) |
| Categories of data subjects | (c) | Job applicants; referees |
| Categories of personal data | (c) | Contact details; CV and employment history; interview notes; right-to-work documents |
| Special-category or criminal data | (c), recommended flag | Disability information where volunteered for adjustments |
| Source of the data | recommended | Applicant; recruitment agencies; referees |
| Systems used | recommended | SYS-031 applicant tracking system; SYS-002 email |
| Recipients | (d) | Hiring managers; ATS vendor (processor); background-check provider (processor) |
| Third-country transfers and safeguards | (e) | United States: ATS vendor, under standard contractual clauses |
| Retention / erasure time limit | (f) | Unsuccessful candidates: 6 months after decision; talent pool: until consent withdrawn or 24 months |
| Security measures | (g) | SSO with MFA; role-based access in ATS; see security policy v4 |
| DPIA required / reference | recommended | No (screening documented in DPIA-REG-07) |
| Last reviewed | recommended | 2026-09-15, by DPO |
The example values are illustrative, not recommended retention periods; set yours from your own legal analysis and local employment rules. Put the controller's name, contact details, representative and DPO (point (a)) in a header above the table rather than repeating them on every row.
The 250-employee exemption, and why it rarely applies
Article 30(5) says paragraphs 1 and 2 do not apply to an enterprise or organization employing fewer than 250 persons, unless 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 (Article 9(1)) or personal data relating to criminal convictions and offences (Article 10).
Any one of those conditions removes the exemption. The Article 29 Working Party's 2018 position paper on the Article 30(5) derogations made three points that matter in practice:
- The three conditions are alternatives. Any one triggers the obligation.
- The trigger is "a risk", not "a high risk".
- When the exemption falls away, a small organization only needs records for the processing activities that triggered it, not necessarily for everything.
The difficulty is the "not occasional" condition. Almost every business processes employee data for payroll and customer data for billing on a regular basis. The position paper itself treats routine employee data processing as not occasional. So a 40-person company typically still needs records for its HR and customer processing, even if it can skip records for genuinely one-off activities. Health data about employees (sick leave, for example) brings in the special-category condition as well.
The proposed change
In May 2025 the European Commission proposed amending Article 30(5) as part of a simplification package for small and mid-cap companies (COM(2025) 501). The proposed text would exempt organizations employing fewer than 750 persons unless their processing "is likely to result in a high risk" within the meaning of Article 35. That drops the "not occasional" and "a risk" triggers, which are the ones that catch most small companies today, along with the stand-alone special-category trigger. The EDPB and EDPS supported the aim but stressed that records remain a compliance tool, in their Joint Opinion 01/2025.
The proposal has moved since. Parliament and Council negotiators reached a provisional agreement in June 2026, and Parliament's lead committee approved the agreed text on July 2, 2026, but as of this writing the plenary vote is still pending (the Legislative Observatory file for 2025/0130(COD) lists an indicative date of November 2026), and nothing has been published in the Official Journal. Press reports suggest the final employee threshold may differ from the Commission's 750; we have not been able to confirm the agreed Article 30(5) wording. Until an amending regulation is published and in force, the current 250-employee text applies. Check the procedure file before relying on any new threshold. A separate, broader "Digital Omnibus" proposal from November 2025 (COM(2025) 837) also touches the GDPR and is being negotiated on its own track.
Even if the threshold rises, a company that has to answer access requests, write an accurate privacy notice and run DPIAs will still need most of the same information. The exemption removes a document, not the work behind it.
US equivalents
No comprehensive US state privacy law requires an Article 30-style ROPA by name. Several require work that is very hard to do without one.
| Law | Requirement | What it needs from your data map |
|---|---|---|
| California (CCPA as amended by CPRA, and CPPA regulations) | Risk assessments for listed processing activities, with compliance required from January 1, 2026 and attestations and summaries due to the CPPA by April 1, 2028; cybersecurity audits for some businesses on a staggered schedule (CPPA) | Categories of personal information, purposes, systems and recipients for each assessed activity; accurate notice-at-collection disclosures |
| Minnesota Consumer Data Privacy Act | Data security practices "including the maintenance of an inventory of the data that must be managed" (Minn. Stat. 325M.16) | An explicit data inventory, the closest US analogue to Article 30 |
| Most other state comprehensive laws (for example Virginia, Colorado, Connecticut, Texas, Oregon) | Data protection assessments before processing for targeted advertising, sale of personal data, certain profiling, or processing of sensitive data | Which activities involve those kinds of processing, and what data they use |
| All of the above | Consumer rights requests (access, deletion, correction, opt-out) | Which systems hold a person's data and how to search them; see DSR automation |
The details of each state's thresholds and assessment triggers differ and have changed since several of these laws were enacted, so check the current statute. For California specifically, see California's CPRA and the 2026 regulations; for Utah, the Utah Consumer Privacy Act in practice.
A practical approach for companies subject to both regimes: maintain one record format that covers the GDPR Article 30 fields and add columns for US categories of personal information and for whether an activity counts as a sale, sharing, targeted advertising or sensitive-data processing. One register, several views.
Techniques for building one
Start from purposes, then attach systems
Begin with a list of business processes (hire, pay, sell, support, market, secure, analyze) and break each into processing activities. Then ask which systems each activity uses. Starting from systems instead tends to produce a ROPA that reads like an IT asset register and misses purposes that span many tools.
Pre-fill before you interview
Pull a list of candidate systems from your SSO catalog, expense reports and cloud accounts before you meet each team. Interviews go faster when people correct a draft than when they recall from memory, and you catch tools they would have forgotten.
Use controlled vocabularies
Decide on a fixed list of data categories, data subject types, legal bases and transfer mechanisms, and use dropdowns. Free text produces "email", "e-mail address", "contact info" and "PII" in the same column, which defeats filtering and reporting.
Separate the inventory from the ROPA
Keep systems in one table and processing activities in another, linked by IDs. A relational structure (even two tabs in a spreadsheet) keeps vendor details, hosting regions and security measures in one place.
Assign owners and review dates
Every row gets a named owner and a "last reviewed" date. Hook updates into procurement (new vendor) and engineering (new data store) so the record changes when the business does.
Decide when to automate
Tools can generate a system list, scan for personal data, and keep ROPA entries linked to live inventory records. They cannot decide purposes or legal bases for you. If you are weighing the cost of doing it by hand, the data map cost calculator and What a manual data map really costs will give you a number to compare against vendor quotes. The privacy tech stack shows where ROPA tools fit alongside the rest.
FAQ
Does the ROPA have to be in a particular format?
No. Article 30(3) only requires writing, including electronic form. Some supervisory authorities publish their own templates, which are a good starting point if you operate mainly in one country.
Do we have to publish our ROPA?
No. It is an internal record that must be made available to the supervisory authority on request (Article 30(4)). Much of the same information appears in your privacy notice, but the ROPA itself is not public.
Is legal basis a required ROPA field?
Not under Article 30(1), but you need it for your privacy notice under Articles 13 and 14, and most templates, including the one above, include it.
Does the UK have the same rule?
The UK GDPR retains an Article 30 records obligation. Check the ICO for current UK guidance, as UK data protection law has been amended since Brexit.