What Is a RoPA, and Does a Small Company Have to Keep One?

A record of processing activities, usually shortened to RoPA, is the register that Article 30 GDPR requires each controller and each processor to maintain, in writing, and to "make the record available to the supervisory authority on request". Recital 82 explains what it is for: "in order to demonstrate compliance with this Regulation, the controller or processor should maintain records of processing activities under its responsibility", so that a supervisory authority "might serve for monitoring those processing operations". Here is the part most content gets wrong. Article 30(5) exempts organisations "employing fewer than 250 persons", and that reads like a small-company pass. It is not one. The exemption falls away if the processing "is likely to result in a risk to the rights and freedoms of data subjects", if it "is not occasional", or if it includes special categories of data, and the Article 29 Working Party's position paper on the derogation, endorsed by the European Data Protection Board on 19 April 2018, states that those three conditions "are alternative ('or') and the occurrence of any one of them alone triggers the obligation". Its worked example is the one that catches nearly everyone: "a small organisation is likely to regularly process data regarding its employees. As a result, such processing cannot be considered 'occasional'".

This article covers what the record must contain for a controller and for a processor, the form it takes, what the derogation actually exempts, the proposal that would change the threshold, how a RoPA differs from a data map, and the maintenance failure that turns a compliant record into a false one.

Key takeaways

• Article 30 prescribes seven items for a controller's record and four for a processor's, and a company that is both keeps both.
• The record must be in writing, electronic form included, and produced to a supervisory authority on request. It is the first document an investigation asks for.
• The under-250 derogation is lost by any one of three conditions on its own. Regular processing of employee data is enough, per the WP29 paper the EDPB endorsed.
• A Commission proposal of May 2025 would raise the threshold to 750 persons and replace the three conditions with a single high-risk test. In every primary document fetched for this article it remains a proposal.
• A RoPA is not a data map. The map is the working inventory; the record is the regulator-facing register in the fields the Regulation names.

What a controller's record must contain

Article 30(1) lists the contents. In the words of the Regulation, each controller's record "shall contain all of the following information":

• the name and contact details of the controller and, where applicable, the joint controller, the controller's representative and the data protection officer;
• the purposes of the processing;
• a description of the categories of data subjects and of the categories of personal data;
• the categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries or international organisations;
• where applicable, transfers of personal data to a third country, including the identification of that country and, for certain transfers, the documentation of suitable safeguards;
• "where possible, the envisaged time limits for erasure of the different categories of data";
• "where possible, a general description of the technical and organisational security measures".

Two of those are qualified by "where possible", and that qualification is where records go wrong in opposite directions. Some teams read it as optional and leave the retention and security columns blank. Others treat it as a requirement to reproduce the entire retention schedule and the entire security programme inside the record. The workable reading is the plain one: state the retention period where you have one, and describe the security measures in general terms with a pointer to where the detail lives. A record that cannot state a retention period for a category of data is telling you something about the retention schedule, not about the record.

What a processor's record must contain

Article 30(2) gives the processor a shorter list: the name and contact details of the processor and of each controller on whose behalf it acts, and of the controller's or processor's representative and DPO where applicable; the categories of processing carried out on behalf of each controller; transfers to third countries with the same safeguard documentation as above; and, where possible, a general description of the security measures.

The comparison matters because most business-to-business software companies are both. They are a controller for their own employees, prospects and customers' contact details, and a processor for the personal data inside the customer accounts they host. Article 30 requires both records, and a single spreadsheet that mixes them is the most common structural defect we see.

Form, and who can demand it

Article 30(3) says the records "shall be in writing, including in electronic form", so a spreadsheet, a database or a GRC platform all qualify and a shared understanding does not. Article 30(4) is the provision that gives the record its weight: the controller or processor "and, where applicable, the controller's or the processor's representative, shall make the record available to the supervisory authority on request".

Note the representative in that sentence. If you are a US company with no EU establishment and an Article 27 representative, that representative can be asked for your record directly, which is why the EDPB expects representatives to hold it and why the appointment is a records question as much as a mailbox question. EU representative vs DPO covers what the representative is for and what it costs; the point for this page is that your record has to exist in a form you would be content to have produced by someone else, without you in the room.

Article 30 sits in the lower of the two fine tiers. Article 83(4) covers Articles 25 to 39 and caps at 10,000,000 euros or 2 percent of total worldwide annual turnover, whichever is higher. The practical exposure is different from the ceiling: because the record is the first thing an investigation asks for, its absence or falsity is the frame through which everything else you have done gets read.

The derogation, read narrowly

Article 30(5) is short enough to quote in full: the obligations "shall not apply to an enterprise or an organisation employing fewer than 250 persons unless the processing it carries out 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 as referred to in Article 9(1) or personal data relating to criminal convictions and offences referred to in Article 10". Recital 13 confirms the intent: a derogation "for organisations with fewer than 250 employees with regard to record-keeping", to take account of "the specific situation of micro, small and medium-sized enterprises".

The WP29 paper, written because of "the high number of requests coming from companies and received in the last few months by national Supervisory Authorities", closes the three doors people try to walk through.

The conditions are alternatives. The paper says the wording "is clear in providing that the three types of processing to which the derogation does not apply are alternative ('or') and the occurrence of any one of them alone triggers the obligation to maintain the record". You do not need all three.

"Risk" means risk, not high risk. The paper spells out that organisations "carrying out processing likely to result in a risk (not just a high risk) to the rights of the data subjects" are obliged to keep the record. This is a lower bar than the Article 35 DPIA trigger, and the two should not be confused.

"Occasional" is defined, and narrowly. In the paper's footnote, "a processing activity can only be considered as 'occasional' if it is not carried out regularly, and occurs outside the regular course of business or activity of the controller or processor". Payroll is inside the regular course of business. So is a CRM. So is a product that stores user accounts.

There is one genuine concession, and it is the useful part. Organisations under the threshold that are caught by one of the conditions "need only maintain records of processing activities for the types of processing mentioned by Article 30(5)". Processing that really is occasional, unlikely to result in a risk, and free of special-category data can be left out of a small organisation's record. In practice that leaves a small company with a full record for everything routine and permission to omit the one-off, which is a modest saving. The paper's own view is that "for many micro, small and medium-sized organisations, maintaining a record of processing activities is unlikely to constitute a particularly heavy burden".

The proposal that would change the threshold

In May 2025 the European Commission published COM(2025) 501, a proposal that would replace Article 30(5) with new text: the obligations "shall not apply to an enterprise or an organisation employing fewer than 750 persons unless the processing it carries out is likely to result in a high risk to the rights and freedoms of data subjects, within the meaning of Article 35". The explanatory memorandum describes the aim as "making the record-keeping mandatory only when the processing activities are likely to result in a 'high risk'", and says a recital would clarify that processing special categories of data under Article 9(2)(b), the employment-law condition, "does not, as such, trigger the obligation to maintain records".

That is a real change in both directions: a higher headcount threshold, and a single high-risk test in place of the three conditions the WP29 paper reads so strictly. On 9 July 2025 the EDPB and EDPS published a joint opinion supporting "the general objective of the Proposal to reduce the administrative burden for SMEs and SMCs as long as this does not lower the protection of individuals' fundamental rights", while asking why 750 rather than the 500 first considered, asking that the exemption reference the formal SME and small mid-cap definitions rather than headcount alone, and asking for confirmation that "organisation" excludes public authorities.

In every primary document fetched for this article the 750-person text is a proposal, and this page does not say whether it has been adopted, because nothing we read says so. Two consequences follow for planning. First, the law in force is the 250-person text with the three alternative conditions, and a record built to it is right today. Second, even under the proposed text, a record is the evidence you would use to show that your processing is not high risk, so building one is the safer bet under either version.

A RoPA is not a data map

The two get conflated because one is built from the other. A data map is the working inventory: every system, every field, every flow, every vendor, at whatever granularity your engineers need. It is internal, it is messy, and it is where the truth lives. The RoPA is the register in the fields Article 30 names, organised by processing activity rather than by system, written for a reader who was not there. You cannot write a good record without a map underneath it, and a record kept without a map decays into a form.

That is also why the WP29 paper calls the record "a very useful means to support an analysis of the implications of any processing whether existing or planned" and says it "facilitates the factual assessment of the risk of the processing activities". The record is the input to your DPIA screening, to your lawful basis register and to your transfer analysis, all of which are organised by purpose. The map is the input to the record. Build them in that order and the record is mostly transcription; build the record first and it will describe an organisation that does not exist.

The hours involved in building the map and the record are sized, for a small software company, in our GDPR cost article, which owns that figure and is not restated here.

The honest caveat: a record generated once is a record that is wrong

Recital 82 ties the record to demonstrating compliance. A record that describes systems you have retired, omits the tool marketing adopted last quarter, and lists a retention period nobody applies does the opposite: it demonstrates that your documentation and your business have parted company, and it does so in the first document a supervisory authority reads.

The failure mode is not building the record. It is building it from a one-off survey and never touching it again. The mitigation is a change trigger, not a calendar: a new vendor, a new data category, a new purpose or a new market each open the record. If your procurement process cannot tell the record owner that a new tool now holds personal data, you do not have a maintenance process, whatever the review cadence says.

Against our own interest: a ten-person company with one product, a payroll provider and a CRM can build and keep this record in a spreadsheet without help. The value we add is at the seams, where a company is both controller and processor, where the transfer column is a chain of subprocessors, or where nobody can say what the retention period is because there is not one.

Where Top Floor fits

We build the map and then the record, in that order, and we write the record for the reader Article 30(4) has in mind. That is GDPR work. Where the same processing falls under EU and US regimes at once, global privacy keeps one inventory with jurisdiction-specific views rather than parallel documents that drift. Where the record needs an owner who will still be maintaining it next year, that is what compliance as a service is for.

How to decide this week

Answer three questions in writing. Do you process any personal data regularly, including your own staff's? If yes, the derogation is not available for that processing, whatever your headcount, and you owe a record for it. Are you a processor for anyone? If yes, you owe the Article 30(2) record for each controller as well as your own controller record, and they should be separate. Could your Article 27 representative, or anyone else, hand your record to a supervisory authority tomorrow without you? If no, the record is not in the form Article 30(3) and 30(4) require. Then pull the data map, however rough, and check whether every system on it appears in the record. The gaps are your work list.

Frequently asked questions

Does a company with fewer than 250 employees need a RoPA?

Usually yes, for most of what it does. Article 30(5) exempts organisations employing fewer than 250 persons, but the exemption is lost where the processing is likely to result in a risk to individuals, is not occasional, or involves special categories or criminal-offence data, and the Article 29 Working Party paper endorsed by the EDPB states that any one of those conditions alone triggers the obligation. The paper's own example is employee data: a small organisation processes it regularly, so that processing cannot be considered occasional and must be recorded. The concession is that such an organisation need only record the types of processing that meet one of the conditions, so a genuinely one-off, low-risk activity can be left out.

What is the difference between a RoPA and a data map?

A data map is your internal inventory of systems, fields, flows and vendors, at whatever detail your engineers need, and it is where the factual truth about your processing lives. A RoPA is the register Article 30 requires, organised by processing activity in the fields the Regulation names, written for a supervisory authority that can demand it on request under Article 30(4). The record is built from the map, and a record built without one tends to describe an organisation that does not exist. Keep both, and keep the map as the source the record is refreshed from.

Is the 250-employee threshold changing to 750?

A European Commission proposal of May 2025, COM(2025) 501, would replace Article 30(5) so that the obligation does not apply to an enterprise or organisation employing fewer than 750 persons unless its processing is likely to result in a high risk within the meaning of Article 35, and the EDPB and EDPS published a joint opinion on it in July 2025 supporting the objective while asking for clarifications. In every primary document read for this article it remains a proposal, and the text in force is the 250-person version with its three alternative conditions. A record built to the current text is right today and would also be the evidence used to show processing is not high risk under the proposed one.

Who can ask to see our record of processing activities?

The supervisory authority, on request, under Article 30(4), and the request can be addressed to your representative in the Union as well as to you, since the Article names the controller's or processor's representative alongside them. That is why the record has to exist in writing, including electronic form, in a state that someone other than you could produce without explanation. Enterprise customers also ask for it during procurement, which in practice happens far more often than a regulator asking, and a record that reads as a form nobody maintains costs deals before it costs fines.