GDPR Article 30: The Record of Processing Activities an SMB Can Build

A record of processing activities (RoPA) is the single document that proves you know what personal data you hold, why, who sees it, where it goes, and when you delete it. It is the first thing a supervisory authority asks for after a breach. Most SMBs are technically exempt from keeping one — and almost always wrong to rely on that exemption.

Article 30 of the GDPR requires both controllers and processors to maintain a record of processing activities. The accountability principle (Article 5(2)) makes the controller responsible for demonstrating compliance, and the RoPA is the primary instrument for that demonstration. It is the artifact that turns “we think we are compliant” into “here is what we process and why.”

The item list below reflects the public text of Article 30 of the GDPR (Regulation (EU) 2016/679). Confirm the exact wording against the official text on EUR-Lex before filing — the regulation is public law and stable, but you want to cite the current consolidated version.

The exemption most SMBs misread

Article 30(5) exempts an organisation from the documentation obligation where:

• the processing is **occasional**,
• it is **not likely to result in a risk to the rights and freedoms** of data subjects, and
• it does not involve **special categories of data** (Article 9) or **criminal conviction and offence data** (Article 10).

The exemption also historically carried a 250-employee threshold framing in guidance; the conditions above are the operative test. The trap: almost no SMB processing meets all three. If you run a CRM, send marketing email, run payroll, or operate a website with analytics, your processing is not “occasional” and a breach would risk data subjects’ rights. If you store health data, union membership, or any Article 9 category, the exemption is unavailable regardless of size. Processors are never exempt from keeping their own Article 30(2) record — the exemption is a controller-only relief.

The practical reading: keep a RoPA. The exemption is narrower than it looks, and the document is the cheapest compliance asset you will build.

What a controller’s RoPA must contain (Article 30(1))

Each processing activity gets a row (or section) with:

1. The identity and contact details of the controller and, where applicable, the joint controller, the controller’s representative, and the data protection officer. 2. The purposes of the processing. 3. A description of the categories of data subjects and the categories of personal data. 4. The categories of recipients to whom the personal data has been or will be disclosed (including recipients in third countries or international organisations). 5. Third-country transfers, where applicable, and the documentation of suitable safeguards (Article 46). 6. The envisaged time limits for erasure of the different categories of data (retention). 7. A general description of the technical and organisational security measures referred to in Article 32 (where feasible).

That is the whole item list. A spreadsheet with one row per processing activity and those seven columns is a compliant RoPA.

What a processor’s RoPA must contain (Article 30(2))

A processor’s record is shorter. It holds, for each processing activity carried out on behalf of a controller:

1. The identity and contact details of the processor and of each controller on whose behalf it acts, the processor’s representative, and the DPO. 2. The categories of processing carried out on behalf of each controller. 3. Third-country transfers and the suitable safeguards. 4. A general description of the Article 32 security measures (where feasible).

A processor does not record purposes or retention — those are the controller’s call. The processor records what it does, for whom, and how it is secured.

How an SMB builds a RoPA in an afternoon

1. Inventory your processing activities. Walk the business: website/analytics, email marketing, CRM, HR/payroll, customer support, accounting, backups, CCTV if any. Each distinct activity is a row. 2. Fill the seven columns. For each activity: who is the controller (usually you), what is the purpose, whose data and what categories, who receives it, any cross-border transfer, how long you keep it, what security protects it. 3. Surface the third-country transfers. Cloud services with US hosting, a US-based analytics tool, a support desk hosted outside the EU. Each is a transfer and needs a safeguard named (SCCs, adequacy decision, BCRs). This is the column SMBs leave empty and authorities hit first. 4. Name the security measures. Not a full ISO 27001 statement — “TLS in transit, AES-256 at rest, MFA on admin access, encrypted backups” per activity is the “general description” Article 30 asks for. If you run ISO 27001, point at the ISMS — see the joint implementation article. 5. Set retention. A column with “6 years” for accounting records (statutory), “duration of contract + 1 year” for customer data, “until consent withdrawn” for marketing. A RoPA without retention is incomplete. 6. Review it on change. A new SaaS tool, a new marketing channel, a new third-country vendor — update the row. Annual review minimum.

The RoPA as the spine of the GDPR program

The RoPA is not a standalone document. It is the index that the rest of the GDPR program references:

• **Data subject rights** (Articles 15–22) are exercised against what the RoPA says you hold. You cannot answer an access request (Article 15) without knowing your processing activities — the data subject rights and 72-hour clock article builds on the RoPA.
• **The DPIA** (Article 35) is triggered for high-risk processing you identified in the RoPA. The DPIA template starts from the RoPA’s activity list.
• **Breach notification** (Article 33, 72 hours) requires you to know what data and whose — the RoPA answers that in minutes, not days.
• **Records of consent and processing lawfulness** are referenced from the RoPA’s purpose column.

Build the RoPA first; every other GDPR artifact becomes easier.

The Article 30 / Article 32 overlap

Article 30(1)(g) asks for a general description of the Article 32 security measures. Article 32 itself requires security appropriate to the risk — pseudonymisation/encryption, confidentiality/integrity/availability, resilience, regular testing. You do not need a full security assessment in the RoPA — a general description suffices. The detailed controls live in your security program; if you run ISO 27001, the ISMS risk assessment and Annex A controls are the substance, and the RoPA’s security column points at them. This is the merge point between GDPR and ISO 27001 — one security description, cited from the RoPA and audited under ISO 27001.

Common SMB mistakes

• **Skipping the RoPA on the exemption.** The three conditions rarely hold simultaneously; processors never qualify.
• **Empty third-country column.** Every US-hosted SaaS is a transfer. Name the safeguard (usually Standard Contractual Clauses).
• **No retention.** "We keep it as long as needed" is not a RoPA entry. Set a limit per category.
• **One row for the whole company.** Marketing email and payroll are different activities with different purposes, recipients, and retention. Separate rows.
• **Static RoPA.** A RoPA written once and never updated drifts from reality and fails the accountability test on change.

How this fits the series

This is the use-case companion to the GDPR pillar. It is the first artifact to build after establishing you are subject — the data subject rights and 72-hour clock, the DPIA template, and the ISO 27001 joint implementation all reference it. If you also run PCI DSS, the RoPA’s security column is the GDPR-facing view of the same controls the PCI assessment examines.

What to do next

Open a spreadsheet. List your processing activities — you will have between 5 and 15 as an SMB. Fill the seven Article 30(1) columns for each. Pay particular attention to the third-country transfer and retention columns — those are the two authorities check. If any activity looks high-risk (large-scale, special-category, profiling, systematic monitoring), flag it for a DPIA. That spreadsheet, reviewed on every tool or vendor change, is a compliant Article 30 RoPA — built in an afternoon, maintained for the life of the business.

Want a review of your RoPA against the Article 30 elements? Book a 30-minute **GDPR applicability assessment** — we map your processing activities, flag the transfers missing safeguards, and set the retention schedule. Bilingual EN/FR, no obligation.

→ /contact · download the GDPR for SMBs readiness guide