Article 30 is the one GDPR obligation that is purely an internal record. No public disclosure, no customer-facing consent, no banner on the homepage. It is a spreadsheet (or a database) that lists every processing activity your company runs, the lawful basis for each, and the security measures that protect it.
It is also the document a regulator or auditor will ask for first. When we review a SaaS product for GDPR readiness, the RoPA is the single highest-leverage thing to get right — get it right and most of the rest follows. This page is a working template: the exact fields, a complete example for a typical B2B SaaS, the mistakes we see most often, and how a free self-check fits next to a manual review.
Key takeaways
- Article 30 is the only GDPR obligation that is purely an internal record — no public disclosure required — and regulators ask for it first.
- You need one per controller (your company) and one per processor (every vendor that processes personal data on your behalf).
- The required fields are: purpose, lawful basis, categories of data subjects, categories of personal data, recipients, transfers, retention, and security measures.
- For a typical B2B SaaS, the controller register runs 8-15 processing activities; the processor register runs 10-25 vendors.
- Most SaaS RoPAs we review are missing at least one of: sub-processors, retention periods, or security measures per activity.
What Article 30 actually requires
Article 30 of the GDPR requires every controller to maintain a record of processing activities. The list of fields is short and exact; nothing about it is open to interpretation. The work is in filling them out honestly and keeping the register current, not in interpreting the regulation.
The same article requires processors — every vendor that processes personal data on your behalf — to maintain a parallel record. For a SaaS company that means two registers: one for what you do as the controller, and one for what each of your processors does on your behalf. Keeping them in sync is the single biggest source of findings in GDPR readiness reviews.
Who needs a RoPA (and who is exempt)
Article 30(5) carves out organisations with fewer than 250 employees, but only if the processing is occasional, does not include special-category data, and is unlikely to risk the rights of data subjects. For a SaaS that runs a production database with continuous processing of user data, the exemption almost never applies. Treat yourself as needing one unless you have specific legal advice otherwise.
The exemption is also conditional: if a supervisory authority asks for the register, the exemption disappears for that request. For most small SaaS companies the choice is between writing it now or writing it under pressure later.
The exact fields you need
Article 30 lists nine required fields. Some apply to controllers, some to processors, and most apply to both. Each of these is the literal text or a paraphrase of the text in the regulation — there is no “FPSEC extension” here.
01Controller / processor name and contact details
Your legal entity, contact, and where applicable the joint controllers or representative under Article 27.
02Purposes of processing
One row per business purpose — for example, 'delivering the core service', 'billing', 'product analytics', 'transactional email', 'marketing email'. Resist the urge to merge purposes; each purpose gets its own lawful basis.
03Description of categories of data subjects
For a B2B SaaS: 'authenticated users', 'trial users', 'customer billing contacts', 'support requesters', 'job applicants'. For a consumer product, also include anonymous visitors.
04Description of categories of personal data
For an authenticated user: 'account email, hashed password, role, organisation, IP of last login'. Be specific enough that an auditor can map fields to your database schema.
05Categories of recipients
Internal teams (engineering, support, finance) and external processors (Stripe, HubSpot, AWS, etc.). List every recipient that receives personal data — this is the field auditors verify against your DPA register.
06Transfers outside the EEA
Flag the transfer (for example, 'Stripe Inc, United States, SCCs in place via DPA addendum, transfer impact assessment on file') rather than just the destination. The transfer mechanism matters more than the geography.
07Retention periods
A specific period per data category, not 'as long as necessary'. Examples: 'account data, life of account plus 30 days for deletion', 'billing records, 7 years for tax compliance', 'analytics events, 13 months', 'support tickets, 3 years after closure'.
08Security measures (Article 32)
Encryption in transit (TLS, HSTS), encryption at rest (database-level), access control (RBAC, MFA on admin), logging (audit logs, security event monitoring), and backup / restore. One or two sentences per measure is enough; link to the internal policy.
Worked example: a B2B SaaS controller register
Below is a filled-in controller register for a fictional but typical B2B SaaS — the kind of mid-stage startup we audit most often. Adapt the purposes, data categories, and recipients to match your own product.
| Purpose | Lawful basis | Data | Recipients | Transfers | Retention |
|---|---|---|---|---|---|
| Deliver the core service | Contract (Art. 6(1)(b)) | Authenticated users Email, hashed password, role, organisation, last-login IP | Engineering, internal; AWS (EU region), Stripe, Intercom | AWS EU only; Stripe US via SCCs; Intercom US via SCCs | Life of account + 30 days |
| Billing and payment | Contract (Art. 6(1)(b)); legal obligation (Art. 6(1)(c)) | Customer billing contacts Name, billing address, VAT number, payment token | Finance, internal; Stripe | Stripe US via SCCs | 7 years (tax compliance) |
| Product analytics | Legitimate interest (Art. 6(1)(f)) | Authenticated users User ID, event name, timestamp, page URL, anonymised IP | Product team, internal; PostHog (EU) | PostHog EU only | 13 months |
| Transactional email | Contract (Art. 6(1)(b)) | Authenticated users Email, name, account email | Engineering, internal; Postmark (EU) | Postmark EU only | Logs retained 3 years |
| Marketing email | Consent (Art. 6(1)(a)) | Prospects and opted-in users Email, name, signup source | Marketing, internal; Resend | Resend US via SCCs | Until unsubscribe + 30 days; consent log retained 3 years |
| Customer support | Contract (Art. 6(1)(b)); legitimate interest (Art. 6(1)(f)) | Support requesters Name, email, ticket content, account metadata | Support team, internal; Front (US) | Front US via SCCs | 3 years after closure |
| Security monitoring and incident response | Legitimate interest (Art. 6(1)(f)); legal obligation (Art. 6(1)(c)) | Authenticated users IP, user agent, request metadata, audit log entries | Security team, internal; Datadog (EU) | Datadog EU only | Audit log 1 year; SIEM events 90 days |
| Recruitment | Contract (Art. 6(1)(b)); legitimate interest (Art. 6(1)(f)) | Job applicants CV, cover letter, references, interview notes | Hiring team, internal | None | 12 months after application; opt-in retention for 24 months |
The processor register, in parallel
For each vendor that processes personal data on your behalf, keep a parallel entry. The recipients column in the controller register should reconcile line-for-line with this list.
| Vendor | Role | Data categories | Mechanism |
|---|---|---|---|
| AWS | Hosting (EU region) | Account data, billing data, support data | DPA in place; EU region; ISO 27001 / SOC 2 on file |
| Stripe | Payment processing | Payment tokens, billing data | DPA + SCCs (US) |
| PostHog | Product analytics | User ID, events, page URL | EU hosting; DPA in place |
| Intercom | Customer support messaging | Email, name, message content | DPA + SCCs (US) |
| Postmark | Transactional email | Email, name | EU hosting; DPA in place |
| Resend | Marketing email | Email, name | DPA + SCCs (US) |
Sub-processors
Article 30 expects you to capture sub-processors — the vendors your vendors hand data to. This is the field that is most often missing.
| Vendor | Known sub-processors |
|---|---|
| Stripe | Plaid (when used), tax calculation vendors, fraud signals providers |
| Intercom | Cloud infrastructure providers, AI sub-processors for summarisation |
| AWS | AWS region partners, content delivery networks |
Common mistakes we see in SaaS RoPAs
One row per database instead of one row per purpose
The purpose is what determines the lawful basis. 'Users table' is not a purpose; 'deliver the core service' is. A row per database hides the fact that you are processing the same data for several different purposes with different lawful bases.
Listing vendors without listing what they receive
Auditors verify your processor register against your actual data flows. 'Stripe — payments' is not enough; you need 'Stripe — billing contact name, address, payment token, VAT number' so the auditor can confirm the match.
Forgetting the sub-processors
Article 30 expects you to capture sub-processors. Most SaaS companies list Stripe, Intercom, and AWS, but not the four analytics vendors Stripe hands data to. Sub-processors count.
Retention periods that say 'as long as necessary'
Storage limitation requires a specific period, not a hand-wave. Write down the period per data category and the trigger that starts the clock (account deletion, ticket closure, last login, etc.).
No version history
A regulator will ask which version was current on the date of an incident. Maintain a dated changelog of additions, removals, and basis changes. Most templates skip this; it is the one thing that turns a defensible RoPA into an indefensible one.
Treating it as a one-time project
RoPAs have to be reviewed at least annually and updated when you onboard a new processor, ship a new feature, or change retention. Bake the review into your security program cadence.
How to keep it current
A RoPA that is current is worth ten times more than one that is pristine and a year old. The mechanical parts:
- Tie register updates to your release process. Every time a feature ships that processes personal data for a new purpose, the RoPA is updated as part of the release checklist.
- Tie register updates to procurement. Every time a new processor is onboarded, the entry is created with the DPA on file before the integration goes live.
- Run a quarterly review of the whole register. One owner, one meeting, one updated document, dated and versioned.
- Keep a dated changelog. “v1.4 — added Twilio as processor for SMS OTP, 2026-05-14.” Future you will thank present you.
If you want a faster way to check the rest of your GDPR posture, the free FPSEC GDPR self-check asks 17 questions across the eight controls and gives you a 0-100 score plus an embeddable badge. When buyers or auditors ask for evidence beyond the public surface, AppCheck pairs scanners with human review of your RoPA, DPAs, and source code for a flat €500 per audit delivered in days. Request an audit.
Frequently asked questions
Do I need a RoPA if I have fewer than 250 employees?
Article 30(5) carves out organisations with fewer than 250 employees, but only if the processing is occasional, does not include special-category data, and is unlikely to risk the rights of data subjects. For a SaaS that runs a production database with continuous processing of user data, the exemption almost never applies. Treat yourself as needing one unless you have specific legal advice otherwise.
Is the RoPA public?
No. Article 30 records are an internal obligation. You do not publish them, but you must make them available to the lead supervisory authority on request. The way the public learns you have one is usually a buyer questionnaire asking for evidence of GDPR readiness.
Do I need a separate RoPA for every EU member state?
No. One RoPA covers your processing across all EEA member states. You may need separate entries for different legal entities if your company has multiple EU subsidiaries acting as joint controllers, but for most SaaS companies a single register is enough.
How often should I update the RoPA?
At minimum annually. In practice, update it whenever you onboard a new processor, ship a new feature that processes personal data for a new purpose, change a retention period, or change the legal basis for a purpose. Most teams set a quarterly review cadence and tie updates to product releases.
Is a RoPA the same as a DPIA?
No. A RoPA is a register of every processing activity. A Data Protection Impact Assessment (DPIA, Article 35) is a deeper risk analysis you do for processing that is likely to result in a high risk to data subjects — for example, large-scale profiling, biometric identification, or systematic monitoring of public areas. A RoPA always; a DPIA when the processing triggers the threshold.
What does an auditor actually look at first?
The RoPA, the DPA register, and the DSAR runbook, in that order. If the RoPA and DPA register are out of sync (different vendors, different data categories, no sub-processors), the auditor's first question is 'what else is out of sync'. A current, honest RoPA is the single highest-leverage document in a GDPR readiness review.
Where does the free self-check fit?
The free FPSEC GDPR self-check has a question on Article 30 readiness. It is a posture signal for buyers and a sanity check for founders. The RoPA itself is the substantive work — the self-check tells you whether to take the next step, and AppCheck is the next step.