The Record of Processing Activities (ROPA) is the document the rest of your GDPR compliance hangs off. It lists every process in your company that involves personal data, with the purpose, the data categories, the recipients, the retention periods and the safeguards. Build it well and your privacy notice, your DPAs and your DPIAs all follow from it. This guide covers who needs a ROPA, the mandatory fields under Article 30, a worked example, and a free template to start from.
- Article 30 formally requires a ROPA at 250+ employees, but its exception covers nearly every SME that processes data regularly.
- Each entry has the same set of mandatory fields - leave none blank.
- Start from a tool inventory, not the template.
What Is a Record of Processing Activities?
Do I really need one as an SME?
Almost certainly yes. Article 30 names a 250-employee threshold, but the exception that follows - for processing that is regular, or that poses a risk to individuals - covers virtually every business that runs a CRM, sends marketing emails or manages HR data. In practice, "do we process personal data routinely?" is the real test, and for an SME the answer is usually yes. The ROPA is also what a supervisory authority asks for first, so a missing or incomplete one is itself a finding under Art. 30, regardless of whether your processing was otherwise correct.
The Mandatory Fields Under Article 30
What goes in each entry?
Every processing activity in your ROPA records the same fields:
- Purpose of processing - why the data is processed (e.g. "sending marketing newsletters").
- Categories of data subjects - whose data (customers, prospects, applicants).
- Categories of personal data - which data (name, email, purchase history).
- Recipients - who receives it, including sub-processors.
- Third-country transfers - whether data leaves the EU/EEA, and the safeguards.
- Retention periods - how long the data is kept.
- Technical and organisational measures (TOM) - how the data is protected.
No field left blank: a gap is treated like a missing record during an inspection.
A Worked ROPA Example
What does a filled entry look like?
| Field | Example entry |
|---|---|
| Purpose | Email marketing / newsletter |
| Data subjects | Customers and newsletter subscribers |
| Personal data | Name, email address, open/click history |
| Recipients | Email service provider (sub-processor) |
| Third-country transfer | None (EU-hosted) |
| Retention | Until consent is withdrawn + 30 days |
| TOM | TLS in transit, access control, double opt-in |
Repeat one row like this for every tool and process - CRM, applicant tracking, support tickets, website analytics, AI tools. A handful of clear entries beats a single vague one.
How to Build Your ROPA, Step by Step
Where do I start?
1. Map your processing activities first, not the template. Ask each department about purposes and the tools they use - including unofficial ones (Shadow IT is in almost every SME). A purpose can exist without any tool, and one tool can serve several purposes. You can only document what you know is running.
2. Fill the seven Article 30 fields for each activity. Use the worked example above as the pattern.
3. Assign ownership and a review trigger. Decide who maintains the ROPA and what prompts an update - typically any new tool or changed purpose.
ROPA Template (Excel)
How do I keep it current?
A ROPA created once and never touched is outdated within months. Tie updates to events: a new vendor, a new tool, a new processing purpose. A short annual full review on top of that keeps it defensible. The ROPA feeds your privacy notice and your DPAs, so keeping it current keeps those current too.
building the ROPA by hand is the slow part - ETHYX gives you a pre-structured register, checks each new entry for a missing DPA or DPIA, and flags entries for review before they go stale, so it stays a living record rather than a one-off file.