What is a RoPA?
Records of Processing Activities (RoPA) is a mandatory GDPR compliance document required by Article 30. It is essentially a register of all the ways your organisation processes personal data — who you process it for, why, how, and how long.
Unlike a privacy policy (which is public-facing and tells users about their data), a RoPA is an internal compliance document maintained for accountability purposes. You don't publish it — but you must make it available to your supervisory authority on request.
The RoPA is often called the foundation of GDPR compliance: if you have an accurate RoPA, you can answer almost any compliance question about your data processing.
Who must maintain a RoPA?
Article 30(5) states that organisations with fewer than 250 employees are exempt from the RoPA requirement — but with three critical exceptions that swallow the rule for most SaaS companies:
- The processing is not occasional (i.e., it is regular and systematic — which describes virtually every SaaS company's core processing)
- The processing includes special category data (Art. 9) or personal data relating to criminal convictions
- The processing is likely to result in a risk to the rights and freedoms of data subjects
In practice: if your SaaS processes user accounts, analytics, or billing data on a regular basis (which all SaaS companies do), you are not covered by the exemption. You need a RoPA regardless of company size.
Controller vs processor: different RoPA obligations
Article 30 distinguishes between controllers and processors:
- Controller RoPA (Art. 30(1)) — documents processing activities where you determine the purpose and means. Required fields: controller identity, DPO contact, processing purposes, data categories, recipient categories, international transfers, retention periods, technical and organisational security measures.
- Processor RoPA (Art. 30(2)) — documents processing carried out on behalf of controllers. Required fields: processor identity, each controller's identity, processing categories (on behalf of each controller), international transfers (including to sub-processors), security measures.
Most SaaS companies are both a controller (for their own employee and marketing data) and a processor (for the data of their customers' end users). You likely need both types of RoPA.
Required RoPA fields (Article 30(1) — Controller)
| Field | Required Content | Notes |
|---|---|---|
| Controller identity | Name, address, contact details | Also joint controller if applicable |
| DPO contact | DPO name and contact details | If you have a DPO |
| Processing purpose | Why you process this data | Be specific — "to provide the SaaS service" is too vague |
| Data categories | Categories of personal data processed | e.g., contact data, usage data, billing data |
| Data subject categories | Who the data relates to | e.g., registered users, trial users, employees |
| Recipient categories | Who you share data with | Sub-processors, public authorities, other controllers |
| International transfers | Third-country transfers and safeguards | e.g., SCCs, DPF, adequacy decision |
| Retention periods | How long data is kept or criteria for determining this | Align with Data Retention Policy |
| Security measures | TOM description | "Where possible" per Art. 30(1)(g) |
Worked RoPA example: typical SaaS
A typical B2B SaaS company might have these processing activities in its controller RoPA:
Processing Activity 1: User account management
- Purpose: Create and manage registered user accounts; provide access to the SaaS platform
- Lawful basis: Contract (Art. 6(1)(b)) — performance of contract with the user or their employer
- Data categories: Name, email address, job title, company name, profile photo (optional), password hash
- Data subjects: Registered users
- Recipients: Authentication provider (e.g., Auth0/Clerk), cloud infrastructure (AWS), email provider (SendGrid)
- International transfers: Auth0 (US) — EU-US DPF; AWS (EU region) — no transfer
- Retention: Duration of account; deleted within 30 days of account termination request
Processing Activity 2: Billing and payments
- Purpose: Process subscription payments; issue invoices; manage subscription lifecycle
- Lawful basis: Contract (Art. 6(1)(b)) and Legal Obligation (Art. 6(1)(c) — tax/accounting records
- Data categories: Name, email, billing address, last 4 digits of card, VAT number, payment history
- Data subjects: Paying customers (individuals or company representatives)
- Recipients: Stripe (payment processor), accounting software
- International transfers: Stripe (US) — EU-US DPF
- Retention: 7 years from invoice date (Estonian Accounting Act; EU VAT Directive)
Processing Activity 3: Product analytics
- Purpose: Understand product usage to improve features and user experience
- Lawful basis: Legitimate Interests (Art. 6(1)(f)) — LIA conducted; no override of user interests
- Data categories: User ID (pseudonymous), feature usage events, session data, IP address (anonymised)
- Data subjects: Registered users
- Recipients: Analytics platform (Mixpanel/PostHog)
- International transfers: If US-based analytics tool — SCCs / DPF as applicable
- Retention: Aggregated analytics: indefinite; individual event data: 24 months
Processing Activity 4: Customer support
- Purpose: Respond to customer support inquiries; troubleshoot technical issues
- Lawful basis: Contract (Art. 6(1)(b))
- Data categories: Name, email, support ticket content (may include personal data uploaded by user)
- Data subjects: Support requesters
- Recipients: Support platform (Intercom, Zendesk, Freshdesk)
- International transfers: As applicable for support platform
- Retention: 3 years from last contact
Processor RoPA example: SaaS as processor
If your SaaS processes your customers' end-user data (very common for B2B SaaS), you also need a processor RoPA. It is simpler:
- Controller: Customer name / company (you can maintain a generic entry for all customers if processing is uniform)
- Processing categories: Storing and processing personal data of Controller's end users in accordance with the service agreement and DPA
- Sub-processors: AWS (hosting), Sentry (error tracking), OpenAI (AI features) — with their countries and transfer mechanisms
- Security measures: Reference to your Information Security Policy and TOMs in the DPA
RoPA vs privacy policy vs DPA
| Document | Who Is It For? | Public? | Legal Basis |
|---|---|---|---|
| RoPA | Internal compliance; supervisory authority on request | No | Art. 30 GDPR |
| Privacy Policy | Data subjects — transparency obligation | Yes | Art. 13/14 GDPR |
| DPA | Controller ↔ Processor — contractual obligation | No (but often referenced publicly) | Art. 28 GDPR |
| Data Retention Policy | Internal operations; informs RoPA retention fields | Optional | Art. 5(1)(e) GDPR |
How to build your RoPA in practice
- Start with a spreadsheet or table — the RoPA has no mandatory format; a spreadsheet with one row per processing activity works well
- Walk through your sub-processor list — each sub-processor represents a processing activity; map backwards to understand what data flows to them
- Interview department heads — HR, Sales, Marketing, Engineering, Finance each have processing activities not always visible to the technical team
- Map to your privacy policy — your RoPA processing activities should align with what you disclose to users; gaps signal undisclosed processing
- Assign retention periods — cross-reference with your Data Retention Policy
- Review at least annually — when you add new features, new vendors, or new data categories, update the RoPA
Build your GDPR compliance foundation
A RoPA is the backbone of GDPR compliance. The documents it references should be in place:
- Privacy Policy Generator — public transparency document aligned with your RoPA
- GDPR DPA Generator — DPAs with all processors listed in your RoPA
- Sub-Processor List Generator — fulfils Art. 28(4) and provides source data for your RoPA
- Data Retention Policy Generator — provides the retention periods your RoPA references
- DPIA Generator — certain high-risk processing activities in your RoPA will require a DPIA
See also our guide on GDPR Article 30 RoPA for more context on the legal requirements and a practical build guide.