Article 30 Records of Processing: A Practical ROPA Template

Article 30 records of processing activities — the ROPA — is one of those GDPR requirements that feels administrative until the moment a data protection authority asks for it. At that point, reconstructing six months of documentation in 48 hours is not a workable plan. This post explains what Article 30 actually requires, who is genuinely exempt, and provides a template with eight worked examples for a typical SaaS business.

GDPR Article 30 places a direct obligation on every controller and processor to maintain written records of their processing activities. “Written” includes electronic format — a spreadsheet or a structured document qualifies. A binder of Post-it notes does not.

For controllers (organisations that decide the purpose and means of processing), each record must include:

The name and contact details of the controller, and of the Data Protection Officer if one is appointed.
The purposes of each processing activity — not a single omnibus description, but a purpose per activity.
A description of the categories of data subjects (e.g. customers, prospective customers, employees, website visitors) and the categories of personal data processed.
The categories of recipients to whom data is or may be disclosed, including sub-processors.
Where applicable, transfers to third countries and the legal safeguard relied on (adequacy decision, standard contractual clauses, binding corporate rules).
Retention periods — the expected erasure timeline, or the criteria used to determine it.
A general description of the technical and organisational security measures in place.

This is not optional. Article 30(1) uses “shall maintain” — there is no discretion on whether to keep the ROPA, only on its format.

The 250-employee exemption and why it probably does not apply to you

Article 30(5) says organisations with fewer than 250 employees are exempt from the obligation “unless the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data.”

Three separate carve-outs, each of which independently removes the exemption. In practice, they cover the overwhelming majority of commercial data processing:

“Not occasional” — if you process personal data as a regular part of running your business (maintaining a customer database, sending marketing emails, logging user sessions), the processing is not occasional. The exemption does not apply.

“Special categories” — if you process health data, political opinions, biometric data, or any of the Article 9 categories, the exemption does not apply even for a single data subject.

“Likely to result in a risk” — broad-reach analytics platforms, tracking-heavy marketing stacks, and any processing of financial data from consumers are likely to qualify as risk-bearing in most DPA interpretations.

Enforcement guidance from the ICO, the CNIL, and the EDPB consistently treats the 250-employee exemption as narrow. The Dutch Autoriteit Persoonsgegevens has explicitly stated in its audit guidance that most commercial organisations — regardless of headcount — must maintain records. A DPA finding you without a ROPA is also a signal that you have not thought carefully about your processing activities, which invites broader scrutiny. The risks of GDPR enforcement against SMBs are real, and a missing ROPA is one of the first things auditors check.

What a ROPA record looks like in practice

Each processing activity gets its own row (or page). The fields below match the Article 30 requirements while adding two practical columns DPAs commonly ask for but which the regulation leaves implicit.

Field	Example value
Activity name	User account management
Controller	[Your company name and registered address]
DPO (if any)	dpo@yourdomain.com
Purpose	Creating and maintaining user accounts; authenticating users
Legal basis	Art. 6(1)(b) — performance of a contract
Data subjects	Customers, trial users
Data categories	Name, email, hashed password, billing address
Recipients	Stripe (payment), AWS (hosting), Postmark (transactional email)
Third-country transfers	AWS US-EAST — EU SCCs in place
Retention	Account data: 30 days after deletion request or 24 months inactive; invoices: 7 years (legal requirement)
Security measures	Encryption at rest (AES-256), TLS in transit, bcrypt password hashing, MFA for admin accounts
Last reviewed	2026-05-01

Eight processing activities for a typical SaaS — a worked template

The following table covers the processing activities found in most B2B SaaS products. Adapt the specific values to your stack.

1. User account management — Purpose: contract performance. Legal basis: Art. 6(1)(b). Data: name, email, password hash, billing info. Sub-processors: Stripe, AWS. Third-country transfers: AWS SCCs.

2. Product analytics — Purpose: improving platform performance and understanding feature usage. Legal basis: Art. 6(1)(f) legitimate interest (or consent where tracking crosses into ePrivacy Directive scope). Data: anonymised session events, IP address (truncated), browser/device metadata. Sub-processors: PostHog or equivalent. Note the distinction between GDPR and ePrivacy Directive obligations here — client-side analytics that set cookies need a consent lawful basis under ePrivacy, regardless of what GDPR basis you rely on.

3. Marketing email (newsletter) — Purpose: promoting Elgarde features and regulatory content to subscribers. Legal basis: Art. 6(1)(a) consent. Data: email address, name, send/open/click metadata. Sub-processors: Brevo or equivalent. Retention: until unsubscribe plus 90 days (to honour unsubscribes from legacy lists).

4. Transactional email — Purpose: sending invoices, password-reset links, and security alerts. Legal basis: Art. 6(1)(b) contract performance. Data: email address, transaction identifiers. Sub-processors: Postmark or equivalent. Retention: 7 years (invoice compliance).

5. Customer support — Purpose: handling support tickets and bug reports. Legal basis: Art. 6(1)(b) contract performance. Data: email, name, support conversation content (which may include personal data shared by the customer). Sub-processors: Linear, Intercom, or equivalent. Retention: 24 months after ticket closure.

6. Payment processing — Purpose: billing for subscriptions and ad-hoc charges. Legal basis: Art. 6(1)(b) contract performance. Data: name, billing address, payment method (tokenised — full card data never touches your servers). Sub-processors: Stripe. Third-country transfers: Stripe US — adequacy decision (where applicable) or SCCs.

7. Server logs and security monitoring — Purpose: detecting intrusion attempts, diagnosing errors, uptime monitoring. Legal basis: Art. 6(1)(f) legitimate interest. Data: IP addresses, request paths, HTTP status codes, timestamps. Retention: 30 days rolling. Note: IP addresses are personal data under GDPR even if you do not join them to other data.

8. B2B outreach and lead management — Purpose: identifying and contacting decision-makers at organisations that may benefit from the platform. Legal basis: Art. 6(1)(f) legitimate interest (requires a documented legitimate-interest assessment). Data: professional email, job title, LinkedIn URL, company name, scan results. Retention: until opt-out, maximum 24 months without re-validation.

What DPAs look for when they audit a ROPA

DPAs do not expect perfection. They expect evidence that you have thought about what you process and why. Common audit findings that lead to enforcement action:

No ROPA at all, despite ongoing commercial operations.
Single-entry ROPAs — one row labelled “customer data” that covers everything. Each distinct processing purpose needs its own entry.
Retention periods listed as “indefinitely” or left blank.
Sub-processors not listed — particularly cloud infrastructure, analytics tools, and email providers.
Third-country transfers not acknowledged — using US-based SaaS tools (AWS, Google Workspace, Stripe) without noting the transfer and the safeguard in place.
ROPA never reviewed — a document created in 2020 and never updated is evidence of a compliance posture that exists on paper only.

The ICO’s records of processing activities guidance is the most comprehensive plain-language treatment of Article 30 obligations and worth reading before finalising your template.

How to keep your ROPA current

A ROPA is a living document, not a one-time exercise. Every time you add a new tool to your stack — a CRM, a monitoring platform, a new analytics provider — a new row or an update to an existing row is required. Build the habit into your procurement process: before any new vendor goes live, ask whether it processes personal data, and if so, add it to the ROPA.

Quarterly reviews are a practical cadence for most SMBs. Annual reviews are the minimum. Each review should cover retention: if you said you would delete data after 12 months, check whether the deletion is actually happening.

If you want to understand what personal data your website exposes to third parties before you start building your ROPA, run a free compliance audit on Elgarde — it maps third-party data flows, consent gate failures, and tracker categories, giving you a clearer picture of what needs to appear in your records.

Published by Elgarde Team · May 2026