What Is a Record of Processing Activities (RoPA)?

What must a RoPA contain?

Article 30(1) sets out what a controller's record must include:

• The name and contact details of the controller, and where applicable the joint controller, representative and data protection officer • The purposes of the processing • A description of the categories of data subjects and the categories of personal data • The categories of recipients the data has been or will be disclosed to, including recipients in third countries • Where applicable, transfers to a third country or international organisation, and the safeguards relied on • Where possible, the envisaged time limits for erasure of the different categories of data • Where possible, a general description of the technical and organisational security measures

Article 30(2) sets a shorter list for processors acting on someone else's behalf.

Two of these are where most records are weakest. Retention periods are usually left blank or filled with a placeholder, and categories of recipients often omit the integrations nobody documented.

Who is exempt?

Fewer organisations than the headline suggests.

Article 30(5) exempts an enterprise employing fewer than 250 persons, unless any of the following applies:

• The processing is likely to result in a risk to the rights and freedoms of data subjects • The processing is not occasional • The processing includes special categories of data under Article 9(1), or data relating to criminal convictions and offences under Article 10

The second condition is what closes the door. The European Data Protection Board has taken the position that ordinary, ongoing business activity is not occasional. Running a website, maintaining employee records, using analytics and sending marketing email all count as regular processing.

The practical effect: a small company with staff and customers is processing personal data regularly, so the exemption does not apply to that processing. Smaller organisations are not required to record everything, but they are required to record whatever is regular or risky, which in most cases is the bulk of it.

Treat the exemption as narrow unless counsel has told you otherwise in writing.

What does a good RoPA look like?

The most common structural mistake is organising it by system.

A row that says "Salesforce" is not a processing activity. Salesforce hosts many: lead capture, marketing communications, customer support, contract management, possibly recruitment. Each has its own purpose, its own data subjects, its own recipients and its own retention period. Collapsing them into one row makes every column wrong.

The unit is the activity. One system appears in many rows; one activity may span several systems.

A second common weakness is treating it as a document rather than a register. A RoPA written once and filed is inaccurate within a quarter, because someone will have added an integration or a custom object. It needs a review cycle and an owner.

Where does the information come from?

Three sources, and the third is the one that gets skipped.

The business supplies purposes, data subject categories and recipients. Only the people running an activity know why it exists.

Legal supplies lawful basis, transfer safeguards and retention justifications.

The system of record supplies what is actually there. This is the gap. The business will tell you the CRM holds names, emails and phone numbers. It will not tell you about the passport number pasted into a case description in 2021, the custom object built for a decommissioned process, or the attachment field holding scanned ID documents.

A RoPA built only from interviews describes the system people believe they have. Scanning the org describes the system they actually have, and the difference is usually material.

What does this mean in Salesforce?

Salesforce typically appears in several rows of a RoPA and supplies the raw material for several columns.

Categories of personal data come from an inventory of objects and fields, including custom ones. Personal Data Discovery scans standard and custom objects to produce that inventory, which is the input the business cannot supply from memory.

Retention periods come from your retention policy, and are only credible if something enforces them. A RoPA stating "deleted after 24 months" against data nothing deletes is a documented failure rather than a control.

Recipients come from your integration inventory. Every connected app and API consumer that receives personal data belongs in that column.

One architectural note worth making, because it affects the record itself: a privacy tool that runs as a managed package inside your own org does not add a sub-processor to your RoPA and does not create a cross-border transfer to assess for the tool. A tool that reaches into Salesforce over an external API does both. That is not a reason to choose one over the other, but it is a difference that shows up as rows in this document.