What is a RoPA and why it matters more than you think
Article 30 of the GDPR requires controllers and processors to maintain a record of processing activities (RoPA). On its face, this looks like an internal compliance document — a spreadsheet only a DPA inspector would ever read. In practice, your RoPA is one of the most operationally valuable documents you can build:
- It forces you to map exactly what data you hold and why — which clarifies your legal exposure
- Enterprise customers ask for it during due diligence
- It's the backbone of your GDPR compliance programme (privacy policy, DPAs, DPIAs, and DSR responses all depend on it)
- A DPA can request it within hours of opening an investigation — you do not want to be building it under pressure
The GDPR does not prescribe a specific format. The law requires substance, not a particular spreadsheet layout. What follows are the best practices that hold up under real DPA scrutiny.
Who must maintain a RoPA?
Article 30(5) includes a famous exemption: organisations with fewer than 250 employees may be exempt from the RoPA requirement. The exemption is almost never applicable to SaaS companies. It only applies if the processing:
- Is not likely to result in a risk to the rights and freedoms of data subjects, and
- Is occasional, and
- Does not include special categories of data (Art. 9) or criminal conviction data (Art. 10)
A SaaS product with registered users processes personal data regularly — not occasionally. Any analytics, logging, email communication, or customer support involves systematic processing. The exemption does not apply. Every SaaS company should maintain a RoPA regardless of size.
Controller vs processor RoPA — which do you need?
You need both if you act in both capacities — which most B2B SaaS companies do.
Controller RoPA (Art. 30(1)): You are the controller for your own users' data. This is where you document how you process data on behalf of your business — marketing, analytics, billing, support, HR, etc.
Processor RoPA (Art. 30(2)): You are a processor when you process personal data on behalf of your B2B customers. The categories of processing here are the services you provide. You document: the categories of processing carried out for each client type, the data categories involved, any sub-processors you engage, and international transfers.
If you are a pure B2B SaaS, your processor RoPA is often simpler and covers your service broadly. The controller RoPA covers your own business operations.
The 7 required fields for a controller RoPA (Art. 30(1))
Article 30(1) is explicit about what a controller RoPA must contain. Nothing in this list is optional:
| Field | Article Reference | Common Mistakes |
|---|---|---|
| Name and contact details of the controller (and DPO if applicable) | Art. 30(1)(a) | Using a trading name instead of the legal entity; omitting DPO contact |
| Purposes of the processing | Art. 30(1)(b) | Too vague ("data processing"); each purpose should be specific ("user account management", "billing", "product analytics") |
| Categories of data subjects | Art. 30(1)(b) | Omitting job applicants, contractors, or B2B contacts; only listing "customers" |
| Categories of personal data | Art. 30(1)(b) | Listing "user data" without specifying what data — IP addresses, emails, and payment data are all different |
| Categories of recipients | Art. 30(1)(d) | Not listing cloud sub-processors; treating Stripe and SendGrid as "internal" |
| International transfers (if applicable) | Art. 30(1)(e) | Forgetting that AWS US-East is an international transfer from the EU; no transfer mechanism documented |
| Retention periods (where possible) | Art. 30(1)(f) | Writing "as long as necessary"; DPAs expect specific periods or deletion criteria |
| Description of security measures (where possible) | Art. 30(1)(g) | Either omitting entirely or copy-pasting generic text; should reflect actual controls |
How to structure your processing activities
Each distinct processing activity should be a separate row or section in your RoPA. "Distinct" means a different purpose — not a different tool. Here's a practical breakdown for a typical B2B SaaS company:
| Processing Activity | Lawful Basis | Key Data Categories | Common Recipients | Typical Retention |
|---|---|---|---|---|
| User account management | Art. 6(1)(b) — contract | Name, email, username, IP, preferences | Cloud provider, auth provider | Duration + 3 years |
| Billing and invoicing | Art. 6(1)(b) — contract + Art. 6(1)(c) — legal obligation | Name, address, VAT number, payment token, invoice history | Payment processor, accounting software | 7 years (tax law) |
| Product analytics | Art. 6(1)(f) — legitimate interests | Usage events, session data, IP, device info | Analytics platform | 2 years |
| Customer support | Art. 6(1)(b) — contract | Email, name, support ticket content, attachments | Support platform, email provider | 3 years |
| Marketing and lead nurturing | Art. 6(1)(a) — consent (for marketing emails) or Art. 6(1)(f) (B2B soft opt-in) | Email, name, company, engagement data | Email marketing platform, CRM | Until unsubscribe + 1 year |
| Security and fraud monitoring | Art. 6(1)(f) — legitimate interests | IP, access logs, error logs, session tokens | Log management, SIEM, error tracking | 90 days to 1 year |
| Employee HR and payroll | Art. 6(1)(b) + Art. 6(1)(c) | Name, address, bank details, NI/tax ID, payroll data | Payroll provider, HR software | 7 years (employment law) |
| Recruitment | Art. 6(1)(b) (during process) or Art. 6(1)(a) for CVs retained after | CV, covering letter, interview notes, references | ATS, LinkedIn | Duration of process + 6 months (unsuccessful) |
The international transfers problem
This is where most SaaS RoPAs fall short. Every time you send personal data to a service hosted outside the EEA (European Economic Area), you have an international transfer that must be documented.
Common transfers that founders miss:
- AWS us-east-1 — even if AWS has an EU subsidiary (AWS EMEA SARL), if your data is stored in a US region, it's a transfer. Use Standard Contractual Clauses (SCCs) and document them.
- Stripe — Stripe's legal entity is US-based. Data Privacy Framework (DPF) certified, so EU-US transfers are covered. Still needs to be in your RoPA.
- OpenAI / Anthropic — US entities processing personal data in API calls. Document: SCCs or DPF, transfer countries, and that you've assessed the transfer risk.
- Intercom / HubSpot / Salesforce — CRMs with EU data centres but US parent companies. SCCs typically needed; check their DPA pages.
For each transfer, your RoPA should document: the recipient country, the transfer mechanism (SCCs, DPF, adequacy decision, BCRs), and a reference to the relevant DPA or agreement.
Keeping your RoPA up to date
A RoPA that was accurate in 2024 and hasn't been touched since is a liability. These events require an immediate RoPA update:
- Adding a new sub-processor (analytics tool, support platform, AI service)
- Launching a new product feature that involves new data types or purposes
- Changes to retention periods (new legal requirements or product decision)
- Ending a processor relationship
- Moving infrastructure to a different region or provider
- Hiring employees in a new country (new HR processing activity)
- Starting to process special category data
Best practice is to review your RoPA at least annually and connect it to your vendor management process — every time a new vendor is approved, the RoPA should be updated before the vendor processes any personal data.
RoPA vs Privacy Policy vs Sub-Processor List
These are three different documents that often get confused:
| Document | Audience | Legal basis | Update frequency |
|---|---|---|---|
| RoPA | Internal / DPA inspectors | Art. 30 GDPR (mandatory) | Continuous / at least annually |
| Privacy Policy | Data subjects (public) | Art. 13/14 GDPR (mandatory) | When practices change |
| Sub-Processor List | Customers / public | Art. 28(4) (mandatory if DPA requires general authorisation) | Before adding new sub-processors |
Your RoPA is the internal source of truth. Your Privacy Policy is the public-facing summary. Your Sub-Processor List is the specific disclosure required by Art. 28(4) for your customers to review and object to. They should all be consistent with each other.
What DPAs look for during inspections
Based on enforcement patterns across EU supervisory authorities, these are the RoPA gaps most likely to result in findings:
- Incomplete recipient list — The most common gap. Every sub-processor must be listed, not just "IT providers".
- Missing international transfer documentation — Undocumented US transfers are the second most common finding.
- No special category data documentation — Health, biometric, or religious data often slips through without Art. 9(2) condition documented.
- Vague retention periods — "As needed" is not a retention period. DPAs expect specific timeframes.
- No processor RoPA — B2B SaaS companies often forget they act as processors for their customers and need a separate RoPA section.
Build your RoPA
The most practical way to build a GDPR-compliant RoPA is to work through each processing activity systematically. Our GDPR Article 30 RoPA Generator walks you through each activity with the correct fields, pre-loaded with common categories, recipients, and transfer mechanisms for SaaS companies. You add your processing activities, fill in the details, and download a ready-to-use document.
Related documents you should build alongside your RoPA:
- Privacy Policy Generator — public-facing transparency document
- GDPR DPA Generator — agreements with processors
- Sub-Processor List Generator — public sub-processor disclosure
- Data Retention Policy Generator — internal deletion schedule
- DPIA Template Generator — for high-risk processing activities