What is a Record of Processing Activities (RoPA)?
A Record of Processing Activities (RoPA) is an internal document that lists every way your organisation processes personal data. It's required by Article 30 of the GDPR and serves as the backbone of your data protection compliance programme.
Think of it as a map of every data flow in your business: what data you collect, why you collect it, who has access to it, how long you keep it, and who you share it with. It's not published publicly (unlike your privacy policy) — it's an internal compliance document that supervisory authorities can request at any time.
Who must keep a RoPA?
Article 30(5) provides an exemption for organisations with fewer than 250 employees — but the exemption is narrow. You must still maintain a RoPA if your processing:
- Is not occasional (i.e., you process personal data on a regular basis — which every SaaS product does)
- Includes special category data (health, biometric, racial/ethnic origin, etc.) or criminal conviction data
- Is likely to result in a risk to the rights and freedoms of individuals
In practice, virtually every SaaS product must maintain a RoPA, regardless of company size, because SaaS platforms process personal data on a continuous, non-occasional basis (user accounts, logs, analytics, etc.).
The "fewer than 250 employees" exemption was intended for small organisations with genuinely occasional processing — not SaaS companies.
What must the RoPA contain?
Article 30(1) specifies what a controller's RoPA must contain for each processing activity:
| Required element | What to document |
|---|---|
| Name and contact details of controller | Your company name, address, DPO contact (if appointed) |
| Purpose of the processing | Why you're processing the data (e.g., "to provide user accounts and authenticate users") |
| Categories of data subjects | Who the data belongs to (e.g., end users, employees, leads) |
| Categories of personal data | What type of data (e.g., names, email addresses, IP addresses, payment data) |
| Recipients / categories of recipients | Who you share the data with (sub-processors, third-party services) |
| International transfers | If data is transferred outside the EEA: which country, which transfer mechanism (SCCs, adequacy decision, etc.) |
| Retention periods | How long you keep each category of data before deletion |
| Technical & organisational security measures | General description of how you protect the data (encryption, access controls, etc.) |
Controller vs processor RoPA
As a SaaS founder, you are likely both a controller (for your own business data: employees, leads, marketing) and a processor (when you process your customers' data on their behalf).
Article 30(2) specifies a slightly different record for processors. The processor's RoPA must contain:
- Name and contact details of each controller whose data you process (i.e., your customers)
- Categories of processing carried out on each controller's behalf
- Recipients / international transfers
- Security measures (TOMs)
Many SaaS products need two RoPAs: one as a controller (for HR, marketing, sales) and one as a processor (for product usage data of their customers).
Example RoPA entries for a typical SaaS product
1. User account management (Controller)
- Purpose: Creating and managing user accounts; authenticating users
- Data subjects: End users / customers
- Data categories: Name, email address, hashed password, account preferences
- Lawful basis: Contract (Art. 6(1)(b)) — necessary to provide the service
- Retention: For the duration of the account + 30 days after deletion
- Recipients: Supabase (database hosting, EU), Clerk (authentication, US — SCCs)
- Transfers: Clerk is US-based; covered by SCCs + Clerk's DPA
2. Product analytics (Controller)
- Purpose: Understanding how users interact with the product to improve UX and performance
- Data subjects: End users
- Data categories: Pseudonymised user ID, feature usage events, session duration, browser type
- Lawful basis: Legitimate interests (Art. 6(1)(f)) — product improvement
- Retention: 12 months, then aggregated and anonymised
- Recipients: PostHog (EU-hosted) or Mixpanel (US — SCCs)
3. Transactional email (Controller)
- Purpose: Sending account-related emails (registration confirmation, password reset, billing notifications)
- Data subjects: End users
- Data categories: Email address, name, email open/click data
- Lawful basis: Contract (Art. 6(1)(b)) / Legitimate interests
- Retention: Email logs: 90 days; email address in user record: see user account
- Recipients: Resend / SendGrid / Postmark (DPA in place)
4. Billing and subscriptions (Controller)
- Purpose: Processing payments, managing subscriptions, issuing invoices
- Data subjects: Paying customers
- Data categories: Name, billing address, email, payment card token (tokenised by Stripe — raw card data never reaches your servers)
- Lawful basis: Contract (Art. 6(1)(b)); Legal obligation for invoice retention
- Retention: Billing records and invoices: 7 years (Estonian accounting law / EU VAT rules)
- Recipients: Stripe Payments Europe Ltd. (IE)
How to build and maintain your RoPA
You don't need specialised software. A well-structured Google Sheet or Notion table works fine at early stage. The important thing is that it's complete, accurate, and kept up to date.
Step 1: Inventory your processing activities
List every purpose for which you collect or use personal data. Common categories for SaaS:
- User registration and account management
- Authentication and session management
- Product analytics and telemetry
- Customer support (tickets, chat logs)
- Billing and subscription management
- Email marketing and product newsletters
- Security monitoring and incident logging
- Infrastructure logging (server logs, error tracking)
- Employee/contractor data (HR)
- Sales CRM (leads, contacts)
Step 2: For each activity, document the required fields
Use the 8-column structure from Article 30 shown above. Be specific about retention periods — "as long as necessary" is not compliant. Define actual timeframes.
Step 3: Map your sub-processors and transfers
Every tool you use that processes your users' data is a sub-processor (if you're a processor) or a third-party controller/recipient (if you're a controller). List them all. Check whether each one has a signed DPA. Flag any that transfer data outside the EEA and document the transfer mechanism.
Step 4: Keep it updated
The RoPA must reflect your actual processing. Update it when you:
- Launch a new product feature that processes new types of data
- Integrate a new third-party tool (analytics, support, infrastructure)
- Change your data retention policies
- Start processing in a new jurisdiction
A good practice: review your RoPA quarterly and before any significant product changes.
RoPA vs privacy policy: what's the difference?
They serve different purposes and audiences:
- Privacy policy: External-facing, plain language, public. Tells users what data you collect and why. Required under Art. 13/14 GDPR.
- RoPA: Internal, technical, not published. Documents processing for compliance and audit purposes. Required under Art. 30 GDPR.
They should be consistent with each other. If your RoPA says you use Mixpanel for analytics, your privacy policy should also disclose Mixpanel as a sub-processor/recipient.
What happens if you don't have one?
Supervisory authorities (like Estonia's Andmekaitse Inspektsioon) can request your RoPA at any time. Failure to maintain one is itself a violation of GDPR and can result in a fine of up to €10 million or 2% of global annual turnover (whichever is higher) under Article 83(4).
In practice, enforcement against small SaaS companies for RoPA violations alone is rare — but in a data breach investigation, the absence of a RoPA will significantly aggravate your position with the regulator.
👉 Generate your Privacy Policy free — covers all the disclosure requirements that your RoPA and privacy policy must be consistent on.
👉 Generate your GDPR DPA free — the Article 28 DPA you need for each processor relationship documented in your RoPA.
Key takeaways
- Most SaaS products must maintain a RoPA regardless of company size, because SaaS processing is non-occasional.
- Document each processing activity: purpose, data categories, data subjects, recipients, retention, transfers, and security measures.
- Keep two RoPAs if you act as both controller and processor.
- Update the RoPA quarterly and whenever you launch new features or add new tools.
- Your privacy policy and RoPA must be consistent with each other.