How to Build a GDPR Processing Register (RoPA): A Practical Guide
You get a client questionnaire on your desk. Or an auditor calls. Or your own accountant asks the question: "Do you actually have a processing register?"
Then the googling begins. Record of processing activities. RoPA. Article 30 GDPR. And before long you're lost in legal jargon and templates that create more confusion than clarity.
The good news: it's not that complicated. Below, we explain what a processing register is, what it must contain, and how you can build one as an SMB without a lawyer and without endless templates.
What is a Record of Processing Activities (RoPA)?
A processing register is an overview of all the ways your organization processes personal data. Its official name is a Record of Processing Activities, or RoPA for short.
Think of it as a map of your data. It shows which personal data you collect, why, who has access to it, and how long you retain it. Article 30 of the GDPR requires this register. It's a legal obligation, not something you put off for "someday."
Who needs to maintain a RoPA?
There's a persistent misconception: "A processing register is only required for large companies." That's not true.
The GDPR states that organizations with fewer than 250 employees are exempt, unless:
- the processing is not incidental (and at almost every company, it isn't)
- special categories of personal data are processed (such as health data)
- the processing poses a risk to the rights of data subjects
In practice: if you have a CRM, employ staff, store customer data, or send newsletters, you need a processing register. That exemption rule almost never applies.
Data protection authorities are clear about this. They expect every organization to maintain an up-to-date register. And during an inspection, the processing register is often the first document they request.
What must each processing activity contain?
Each processing activity in your register includes a number of required fields. Article 30 GDPR prescribes ten core fields:
- Name and contact details of the controller (and, if applicable, the representative or Data Protection Officer)
- The purpose of the processing
- Categories of data subjects (whose data is it about?)
- Categories of personal data (what type of data?)
- Recipients (who do you share the data with, internally and externally?)
- Transfers outside the EEA
- Retention periods
- Security measures
- Legal basis
- Source of the data
That sounds abstract. An example makes it clearer.
Example: processing activity "sending newsletters"
| Field | Details | |---|---| | Controller | Your company, including contact details | | Purpose | Sending commercial newsletters | | Categories of data subjects | Customers, prospects, website visitors | | Categories of personal data | Email address, first name, click behavior | | Recipients | Mailchimp (processor), internal marketing team | | Transfers outside EEA | Yes, Mailchimp (US) with EU Standard Contractual Clauses | | Retention period | Until unsubscription, then 30 days | | Security measures | Encryption in transit, 2FA on Mailchimp account | | Legal basis | Consent (opt-in) | | Source | Website sign-up form |
This is the level of detail you need. Not "we process customer data," but exactly what, why, how long, and through which system.
How do you inventory your processing activities?
The hardest part of a processing register isn't filling in the fields. It's figuring out which processing activities you actually have. Most organizations underestimate this. You think you have five processing activities, and you end up counting fifteen.
Don't start with the data. Start with your tools and processes. That works better.
Step 1: List all your software and systems. CRM, accounting software, HR tool, email tool, project management software, customer service platform. Don't forget the tools you installed "real quick": form tools, survey platforms, or a standalone spreadsheet with personal data.
Step 2: Determine which personal data sits in each tool. What data goes in? From whom? Who has access?
Step 3: Link each tool to a processing purpose. The same tool can serve multiple purposes. You might use your CRM for sales, customer service, and marketing. Those are three separate processing activities, each with its own purpose and potentially a different legal basis.
Step 4: Fill in the ten required fields per processing activity. Use the overview above as a checklist.
Not sure where to start? These are processing activities that nearly every SMB has:
- Payroll administration for employees
- Sending newsletters
- Storing customer data in a CRM
- Onboarding new employees
- Processing job applications
- Website analytics with cookies
- Customer service via a ticketing system
- Invoicing and accounts receivable
- Access management with login credentials
- Sharing personal data with an accountant
In ComplianceHive, you record which data sits in each system, who the vendor is, and which Data Processing Agreement (DPA) goes with it. That way you build your processing register software from your existing tools, instead of from a blank document. See how it works.
Common mistakes in a RoPA
A processing register that looks good on paper can still fall short during an audit. These are the most common issues:
1. Too little detail. "We process customer data in our CRM" is not a valid entry. You need to specify which data, from whom, for what purpose, and on which legal basis. An auditor sees through this immediately.
2. Lumping everything together. Some companies create a handful of broad entries instead of a separate row per processing purpose. Your CRM processing for sales and your CRM processing for marketing are two different processing activities, with different purposes and legal bases.
3. Building it once and then forgetting about it. A processing register is not a one-time project. When you add a new tool, switch vendors, or start a new process, the register needs to change with it.
4. Retention periods are missing or unrealistic. "We keep everything forever" is not GDPR-compliant. Every processing activity needs a retention period you can justify.
5. No link between vendors and Data Processing Agreements (DPAs). Your register states you use Mailchimp, but do you also have a signed Data Processing Agreement (DPA)? Without that link, your register is incomplete. During an audit, a supervisory authority wants to follow the trail: from processing activity to system to vendor to agreement.
RoPA in practice: a step-by-step plan for SMBs
You don't have to do everything at once. Expect roughly four weeks if you work on it alongside your regular tasks:
Week 1: Inventory Create an overview of all your software and systems. Ask each department which tools they use daily. Also note tools that aren't "official" but still contain personal data.
Week 2: Document the processing activities Link the processing purposes to each tool. Fill in the ten required fields per processing activity. Use the example in this article as a reference.
Week 3: Review and supplement Walk through each record for completeness. Check whether signed Data Processing Agreements (DPAs) exist for external parties. Flag missing information and plan who will follow up.
Week 4: Ownership and maintenance Assign an owner per processing activity: who is responsible for keeping this record up to date? Decide how often you review the register (at least twice a year). Connect the register to your vendor management and your GDPR checklist.
How do you keep your RoPA up to date?
An outdated processing register is nearly as risky as having no register at all.
Imagine an inspector from the data protection authority shows up. The first thing they ask for is your processing register. They pick a random processing activity and start asking questions. What data do you process exactly? How long do you retain it? Who is the processor? Do you have a Data Processing Agreement (DPA) with them? If your register says "Mailchimp" but you switched to Brevo three months ago, you have a problem. They don't just check whether you have a register; they check whether it matches reality.
Update your register when you:
- introduce a new tool or system
- switch vendors or add a new sub-processor
- start a new process that involves personal data (think of a new onboarding process)
- change retention periods or legal basis
- face an organizational change such as a merger, acquisition, or new department
The simplest way to stay on top of this: connect your register to your software inventory. Adding a new tool? That's your cue to document the corresponding processing activity right away.
In ComplianceHive, that's exactly how it works. Your system inventory and your processing register live in the same platform. Add a new tool to your system inventory, and that's your moment to update the corresponding processing activity too. That way you keep everything in one platform instead of scattered across separate spreadsheets.
Ready to set up your processing register?
ComplianceHive gives you the structure to build your RoPA step by step. Document your processing activities, link them to your tools and vendors, and take the first step without spreadsheet chaos.