Do Freelancers Need a Record of Processing Activities (ROPA)?

Practical guide · GDPR Art. 30 · for freelancers, agencies, and micro-businesses under 250 employees

GDPR Art. 30(5) is often quoted as "businesses under 250 employees don't need a ROPA" — and freelancers stop reading right there. That's not quite what it says. The exemption has three exceptions, and one of them catches almost every freelancer or micro-business anyway. Here's what the rule actually requires, and the simplest version that satisfies it.

The exemption, and why it usually doesn't apply

Art. 30(5) exempts organisations with fewer than 250 employees from keeping a full Record of Processing Activities — unless at least one of these is true:

• the processing is likely to result in a risk to the rights and freedoms of the people whose data you handle,
• the processing is not occasional (i.e. it's a regular part of how you work, not a one-off), or
• it involves special-category data (health, biometric, etc.) or data relating to criminal convictions.

In practice, this means the "under 250 employees, no ROPA needed" advice is usually wrong for a working freelancer or small studio. The good news: a minimal ROPA is a short table, not a compliance department.

What a minimal ROPA actually needs (Art. 30(1))

One row per processing activity — a "processing activity" is just a distinct reason you handle personal data (contact form, checkout, newsletter, analytics, and so on). For each one, record:

• Purpose — why you're processing this data (e.g. "respond to enquiries," "deliver the product ordered").
• Categories of data subjects — who the data is about (customers, website visitors, newsletter subscribers).
• Categories of personal data — what you actually collect (name, email, billing address — not every field, just the categories).
• Legal basis — which Art. 6 basis applies (contract, consent, legitimate interest, legal obligation).
• Recipients — which third parties see this data (your host, payment processor, email tool).
• International transfers — does any of it leave the EEA, and if so, under what safeguard (adequacy decision, SCCs)?
• Retention period — how long you keep it, and why (e.g. invoices: 10 years under Italian tax law; contact-form messages: 12 months).
• Security measures — the basics (HTTPS, access-limited inbox, encrypted storage) — a sentence per row, not a security audit.

Why bother if enforcement is unlikely to check?

Two practical reasons that have nothing to do with fear of an audit:

1. It's the fastest way to answer a data subject access request. If someone asks "what data do you have on me and why," a filled-in ROPA answers it in minutes instead of a scramble through every tool you use.
2. It's what you're asked for first if something goes wrong. If you ever need to notify the Garante of a data breach, the first questions are "what data was affected, and why did you have it" — a ROPA answers both instantly.

Keep it a living document

A ROPA isn't a one-time exercise. Update the relevant row whenever you add or drop a tool, supplier, or new type of data collection (a new form field, a new ad-tracking pixel, a new subprocessor). A ROPA describing tools you stopped using two years ago is worse than no ROPA, since it actively misleads anyone who reads it — including you, in a crisis.

Related reading

A ROPA cross-references your other GDPR paperwork rather than replacing it: the legal bases and recipients you list should match what your Privacy Policy discloses, and any processor listed as a "recipient" should be covered by a DPA with them.

Not legal advice. This guide is general information, not a substitute for advice from a qualified lawyer or data protection professional about your specific processing activities. NormaKit's templates are likewise informational starting points, not legal advice, and should be reviewed and adapted before use.