Skip to the article
ComplyVox Join the waitlist

Writing

How to write your first ROPA

11 min read ComplyVox
  • gdpr
  • ropa

A ROPA is a written record of what your business does with personal data: one entry per activity, saying why you do it, whose data it is, who else sees it, where it goes and how long you keep it. Article 30 GDPR sets out what has to be in it. You write your first one by listing your activities and answering the same seven questions about each, which is a smaller job than it sounds and a different job from finding a template.

The word "record" is what misleads people. It suggests a form. It is closer to an inventory of your own business, written down in a shape a regulator can read.

What a ROPA is, and who has to keep one

Article 30(1) requires every controller to maintain a record of the processing activities under its responsibility. A controller is the organisation that decides why and how personal data is used, which for most small businesses is you: your employee records, your customer list, your marketing.

If you also handle personal data on another organisation's instructions, Article 30(2) puts a shorter, separate record obligation on you as a processor. Most people arriving at this question are controllers, and the rest of this post is about the controller's record.

Two further parts of Article 30 are easy to miss and worth knowing early. Article 30(3) requires the record to be in writing, "including in electronic form": a spreadsheet counts. Article 30(4) requires you to make it available to the supervisory authority on request. In Ireland that is the Data Protection Commission, in the UK the Information Commissioner's Office.

The exemption for smaller organisations is narrower than it sounds

Article 30(5) is the part people usually hear about second-hand, and it is usually repeated wrongly. What it says is that the obligations in 30(1) and 30(2) do not apply to 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".

The word doing the work is "unless". Being under 250 people is where the test starts, not where it ends. Any one of those three things brings the obligation back, and the bar is low: processing that is simply not occasional is enough on its own, with no risk and no sensitive data anywhere near it.

That is where most small businesses land. Running payroll every month is not occasional. Working through a customer list every week is not occasional. The DPC's guidance note on Article 30 says it plainly: "most organisations will need to record processing activities such as HR and payroll functions".

The ICO's guidance for the UK makes the same point with a worked example. An insurance company with 100 staff still has to document its claims, sales and HR processing, because none of that is occasional. A staff engagement survey it runs rarely need not be documented. Same company, same headcount, different answer per activity.

One detail from the DPC is worth carrying with you: where the exemption does fall away, it falls away only for the processing that failed the test. The obligation is "only in respect of the particular type of processing that does not fall within the scope of the derogation". In practice, a record that deliberately covers only your non-exempt activities is harder to keep than one that covers everything, because every new tool and every new use of data then has to be argued against Article 30(5) before you are allowed to leave it out.

What Article 30 says the record has to contain

For a controller, Article 30(1) lists seven things. This is the whole list.

  • Who you are. The name and contact details of the controller and, where applicable, the joint controller, the controller's representative and the data protection officer. Article 30(1)(a). If you have no DPO, there is nothing to put in that part.
  • The purposes of the processing. Article 30(1)(b). Why you are using the data: running payroll, managing customer accounts, recruitment.
  • The categories of data subjects and of personal data. Article 30(1)(c). Who the people are, such as employees, customers or job applicants, and what you hold about them, such as contact details, bank details or employment history.
  • The categories of recipients. Article 30(1)(d). Anyone the data has been or will be disclosed to. Your suppliers count: the DPC's example is an external HR company brought in to deal with an internal matter.
  • Transfers to a third country or an international organisation, where applicable. Article 30(1)(e), including naming the country and documenting the safeguards. If a supplier stores the data outside the EEA, or outside the UK under the UK GDPR, it belongs here.
  • Retention, where possible. Article 30(1)(f) asks for the envisaged time limits for erasure of the different categories of data. How long you keep each kind of record.
  • Security, where possible. Article 30(1)(g) asks for a general description of the technical and organisational measures referred to in Article 32(1). Encryption, access controls, staff training.

Read the qualifiers as they are written. Transfers are "where applicable", retention and security are "where possible", and the first four are not qualified at all.

The DPC found that many organisations add useful things Article 30 does not ask for: the Article 6 legal basis, the Article 9 basis for special category data, the transfer mechanism relied on, whether a breach has occurred. That is fine, and its advice is to label which fields are the Article 30 requirements and which are your own additions, so that the next person to open the file can tell the difference.

What counts as one processing activity

Take running payroll. That is one activity, and here is what the seven questions look like when they are answered about it.

  • Purpose: paying your employees and meeting the related tax obligations.
  • Categories of data subjects: employees, plus contractors or interns if you pay them the same way.
  • Categories of personal data: name, address, PPS or National Insurance number, bank account details, salary, pension contributions, sick leave.
  • Recipients: your payroll provider or accountant, the tax authority, your pension provider, your bank.
  • Transfers outside the EEA: often none, but check where your payroll software actually stores the data rather than assuming.
  • Retention: the period employment and tax law requires you to keep payroll records for. That is not a number this post can give you, because it varies by record and by jurisdiction.
  • Security: who can open the payroll file, whether it is encrypted, who has been trained.
One record, seven fields: payroll
(a) Controller
Your name and contact details. No DPO: nothing to enter.
(b) Purpose
Paying employees, and meeting the related tax obligations.
(c) People, and data about them
Employees, plus contractors or interns if you pay them the same way. Name, address, PPS or National Insurance number, bank details, salary, pension, sick leave.
(d) Recipients
Payroll provider or accountant, tax authority, pension provider, bank.
(e) Transfers outside the EEA
Often none. Check where your payroll software stores it.
(f) Retention
What employment and tax law requires. Not a number this post can give you.
(g) Security
Who can open the file, whether it is encrypted, who is trained.

Article 30(1)(a) to (g).

The test for whether something is one activity or two is whether those answers diverge. Recruitment is not part of payroll: different people, different purpose, different retention period, even though both live in HR. If splitting a row into two means writing the same seven answers twice, it was one activity. If a single row needs two different retention periods, it was two.

This is the DPC's point about granularity. Its guidance says records "should go into specific detail for each category of data subject, category of personal data or processing activity", and gives retention as the example: retention periods differ by category, and the record should reflect that for each one.

How to start when you have nothing

Three things from the DPC's guidance are worth doing in this order.

  1. Map before you write. The DPC advises that "a data mapping exercise should be done by organisations to clarify what data organisations hold and where", with the relevant parts of the organisation involved so that nothing is left out. This is the step people skip, and it is the step that determines whether the finished record is true.
  2. Use your business functions as the checklist, then write a row per purpose. The DPC recommends the record be "clearly broken down and detailed according to the different business units or functions within an organisation, such as HR, finance or marketing", because that is what stops an activity being accidentally omitted. It is not a licence to write one row called "HR". The DPC's own example makes the point: HR alone is likely to have several purposes, several categories of individuals such as employees, contractors and interns, and several categories of data.
  3. Keep it as one standalone record. The DPC is explicit that the record has to stand on its own: "the RoPA should be a standalone record that the DPC can request and view in a readable format". In its 2022 sweep of thirty organisations, one submitted a set of impact assessments and argued they satisfied Article 30. The DPC did not accept that, and its guidance now says that "expecting the DPC to review a large number of separate documents in order to try to find the information required under Article 30 is not acceptable". A record that mostly points at other policies is not a record.

There is also a speed expectation attached, and it is the single most useful thing in the guidance because it tells you what finished looks like. In that 2022 sweep, the DPC asked organisations for their records within ten days, and found that some struggled to produce one in time. Its guidance now states that "ten days should be sufficient notice for any organisation in all circumstances".

So the target is not a perfect record. It is a record that could go to the regulator in its current state, within ten days, without a scramble. The DPC's phrase for that is "ready to go" at any time. It is also a good reason not to wait until the record feels complete before treating it as real: an honest partial record you could hand over on Friday is worth more than a thorough one that exists in your head.

One last piece of the DPC's advice is aimed straight at the person reading this. It recommends that responsibility for the record not sit with the DPO alone, because activities get missed that way and the exercise turns into box-ticking. If data protection landed on your desk on top of your actual job, read that as permission to go and ask other people, rather than as another thing you are expected to know by yourself.

It is not a document you finish

Article 30 records have to describe what you do now, not what you did the year you wrote them. The DPC puts it as "a living, dynamic, document, which is continuously updated to reflect the current position of the organisation at all times". Its recommendations are practical: review it on a schedule, keep it electronic so it can actually be edited, and make sure the people rolling out new products and services know that anything new involving personal data gets added as it goes live.

In a small business that usually means one habit. The day you sign up for a new tool that will hold customer or staff data is the day the record changes, and the sentence describing it is much easier to write that day than nine months later.

The DPC even has a note on timing the review: schedule it when there is capacity to give it attention, "not in a busy period such as the run up to Christmas". Review dates that quietly go stale are the normal failure here, not bad intentions.

The hard part is not the template

If you came looking for a template, the honest answer is that the template is the easy half of this, and it is why the search results are full of them.

The hard part is knowing what you actually do with personal data. Most small businesses have never had a reason to write that list down. The sales team started using a scheduling tool that keeps prospects' contact details. Someone set up a shared inbox that has three years of customer correspondence in it. A supplier has a copy of the staff list for the health insurance scheme. None of that was hidden. It was just never collected in one place, because nothing until now required it to be.

That is why the DPC's first step is a mapping exercise across the organisation rather than a form. The real work is a series of conversations with the people who do the job, and then writing down what they tell you in the shape Article 30 asks for. The format barely matters: the DPC says that "for small organisations it may be that a simple spreadsheet is sufficient to maintain the RoPA". The spreadsheet was never the problem.

Where ComplyVox fits

This is the problem ComplyVox is built around, so it is fair to name it here.

ComplyVox is an in-house AI DPO. You talk to an AI voice agent in plain language about what your business does and what tools it uses, and it produces the GDPR documentation you are required to hold, in plain English, for you to review and approve. The record of processing activities is one of those documents. It is a conversation rather than a form, and the documents come back in hours rather than weeks.

What it does not do is make the decisions for you. You remain the controller. The record is yours, it comes back for you to check and approve, and gaps come back as concrete steps with review dates attached so the library does not quietly go stale.

It is not open yet. There is a waitlist on the ComplyVox home page.

Sources