Records of processing activities: turn the inventory into a working control (2026)

Your product team wants to launch a customer-support platform. Procurement asks for the record of processing activities, and someone exports a list of the systems the company uses. The list names the CRM, ticketing tool, analytics platform and payroll system. It still cannot answer the question a reviewer needs to ask: what personal-data processing does each system perform, for which purpose, and under whose responsibility?

A record of processing activities (ROPA) becomes useful when it describes the work rather than the software catalogue. Under GDPR Article 30, it is a written accountability record that connects a processing activity to its purpose, the people and data involved, recipients, transfers, retention and security. The legal minimum sets the boundary. The record's structure and maintenance determine whether it can support a real decision.

What Article 30 requires

The GDPR places different record-keeping duties on controllers and processors. A controller records the processing activities under its responsibility. A processor records the categories of processing it carries out on behalf of a controller. Both records must be in writing, including electronic form, and the controller or processor must make the record available to the supervisory authority on request. 1

For a controller, Article 30(1) requires these fields:

Organisation and responsibility: the controller's name and contact details, plus the details of joint controllers, a representative and the data protection officer where applicable.
Purpose: the purposes of the processing.
People and data: the categories of data subjects and the categories of personal data.
Recipients: the categories of recipients to whom the data has been or will be disclosed, including recipients in third countries or international organisations.
Transfers: applicable transfers to a third country or international organisation, including the destination and, for the specified Article 49(1) case, documentation of suitable safeguards.
Erasure: envisaged time limits for erasure of different categories of data, where possible.
Security: a general description of the technical and organisational security measures referred to in Article 32(1), where possible. 1

A processor's record uses a different unit. It identifies the processor and each controller on whose behalf it acts, records the categories of processing performed for each controller, captures applicable international transfers and safeguards, and includes a general description of security measures where possible. A processor's Article 30 record does not become a controller's record simply because the processor uses a sophisticated platform or makes operational choices inside the service. The roles still depend on the processing facts.

The small-organisation provision is easy to overread. Article 30(5) removes the Article 30(1) and 30(2) obligation for an organisation with fewer than 250 persons only unless the processing is likely to result in a risk to people's rights and freedoms, is not occasional, or includes special-category data or criminal-conviction and offence data. Company size is therefore not a blanket exemption for recurring customer, employee or user processing. 1

Make one row describe one processing activity

The first design decision is the unit of record. CNIL recommends identifying processing by its purpose or end result, rather than by the software used. One application can support several distinct activities, and each activity can have a different purpose, data set, recipient group, retention rule or lawful-basis record. 2

Imagine a company uses one HR platform for three activities:

managing employment contracts and payroll;
monitoring access to corporate buildings; and
operating an employee helpdesk.

The platform name is common to all three. The processing activity is not. The activities involve different purposes, data categories, recipients, retention events and access groups. A single row called "HR platform" hides those differences. Three purpose-based entries expose them.

The same principle applies to a customer-support system. "Support platform" is too broad if the system handles ticket resolution, quality monitoring, fraud investigation and product analytics. A support agent may need the ticket content to answer a customer. A quality team may sample calls for coaching. A fraud team may correlate account events. Product analytics may use a different data set and a different retention period. The application is one technical environment; the purposes are separate processing activities.

This is where a ROPA can become a working control. A purpose-based row lets a reviewer ask whether the data is necessary for that purpose, whether the notice matches it, whether the recipients are expected, whether the retention period has an end event, and whether a DPIA or transfer assessment is linked. A system list cannot answer those questions by itself.

Use a connected decision screen

A practical controller record can use a table, database or governance platform. Article 30 does not prescribe a particular template. The ICO recommends a granular, meaningful structure that connects purposes, people, data, recipients and retention instead of presenting disconnected lists. It also recommends a broad-to-narrow approach: start with a business function such as HR, sales or customer service, then describe the activities inside it. 3

For each controller activity, use this screen:

Field	What the reviewer should be able to see
Activity and purpose	The processing activity's name, its business outcome, and the purpose stated in operational terms. 1
People and data	The categories of people affected and the categories of personal data used. 1
Operations and systems	What the organisation does with the data, and which systems support the activity. This is an operational addition that makes the legal fields traceable to the real workflow.
Recipients and access	Recipient categories, internal access groups, processors, subprocessors and other parties that receive or can access the data. Article 30 expressly requires recipient categories; the access detail helps test whether the entry reflects the service. 1
Transfers	Third countries or international organisations involved in the flow, with applicable safeguards. 1
Retention and deletion	The envisaged erasure period or the event and criteria that determine it, where possible. 1
Security	A general description of the technical and organisational security measures, where possible. The row can link to the fuller security record rather than copying it. 1
Evidence and governance	The operational owner, last review, change triggers and links to the privacy notice, lawful-basis analysis, DPIA, processor contract or transfer assessment. These links are useful governance fields, not a claim that Article 30 requires every linked document.

The table works because each row answers a chain of questions. What are we doing? Why are we doing it? Whose data is involved? Which data? Who receives it? Where can it be accessed? When does it expire? What protects it? Which colleague can confirm that the row is still true?

For processor records, change the row's centre of gravity. Start with the controller customer, then record the category of processing performed for that customer, relevant transfers and the general security description. The ICO's Article 30 guidance lists the processor's required fields separately and does not list retention schedules as a processor field. 4

Keep ROPA separate from neighbouring documents

Several records may contain overlapping facts. The overlap is useful when the records agree; it does not make them interchangeable.

ROPA and a data map

A data map concentrates on flows, locations and systems. A ROPA concentrates on the processing activity and the Article 30 fields. The map may provide the hosting location, access route and system details that a ROPA needs. A map that contains only arrows between applications still leaves the purpose, recipient categories, retention and security description unresolved.

ROPA and a DPIA

A DPIA examines a particular processing operation that is likely to result in a high risk. It assesses necessity, proportionality, risks and safeguards. A ROPA covers the organisation's processing activities more broadly and can link to the DPIA where one exists. The ROPA tells you that the activity exists and where its supporting assessment is; the DPIA develops the risk judgment for the high-risk operation.

ROPA and a privacy notice

A privacy notice communicates with data subjects. A ROPA supports internal accountability and supervisory-authority inspection. Their core facts should agree, but the audiences differ. A notice may explain the purpose and rights in reader-facing language, while the ROPA may need operational details about recipient categories, support access, retention criteria and linked evidence.

ROPA and a retention schedule

A retention schedule supplies periods or deletion criteria. Article 30 treats envisaged erasure time limits as one part of the controller's record. The schedule does not replace the purpose, people, data, recipients, transfers or security fields.

Treat the record as a living control

A ROPA becomes stale when the processing changes before the record changes. The ICO describes the record as a living document and recommends updating it whenever processing changes, with regular reviews to check that the information remains accurate and current. Electronic records are generally easier to add to, amend and remove. The ICO also recommends involving the teams that know the facts: IT for security, information governance for retention, and legal or compliance teams for data sharing. 3

A review should reopen the row when any of these changes occur:

the business purpose or processing outcome changes;
a new category of data or group of people enters the activity;
a new recipient, processor, subprocessor or support-access route appears;
a new country or international organisation enters the flow;
retention becomes longer, shorter or dependent on a new event;
a material security or architecture change alters who can access usable data; or
a linked DPIA, lawful-basis analysis, processor contract or transfer assessment changes its conclusion.

These triggers turn "last reviewed" from a calendar field into a control. The owner is not merely the person who maintains the spreadsheet. It is the person who can notice a change in the activity and start the update before a product launch, procurement approval or audit request exposes the mismatch.

The practical consequence appears in enforcement. In December 2025, the CNIL said that MOBIUS SOLUTIONS LTD, a processor involved in a data breach affecting more than 46 million users, had failed to keep a record of its processing activities in its capacity as a processor. The CNIL imposed a €1 million fine for several confirmed GDPR breaches, including the Article 30 failure. 5

The enforcement fact does not turn a ROPA into a security control or prove that a perfect register prevents a breach. It shows the narrower point that the processor-side record is a direct obligation with its own evidentiary value. A customer contract and a security questionnaire do not automatically supply that record.

The reviewer record

A defensible ROPA entry should let another reviewer reconstruct the activity without opening every system or contract. Keep this compact record beside the activity:

Purpose and outcome: what the organisation is trying to achieve and what processing occurs.
People and data: the affected groups, data categories and sensitive elements where relevant.
Roles and parties: controller, joint controller, processor, subprocessor, representative and DPO details where applicable.
Recipients and locations: recipient categories, access groups, hosting or support locations, onward recipients and international transfers.
Retention and security: erasure period or criteria, plus the general security-measures description where possible.
Linked decisions: privacy notice, lawful basis, DPIA, transfer assessment, processor agreement and rights-handling procedure where relevant.
Ownership and change triggers: the operational owner, last review, next review condition and the event that requires the entry to be reopened.

ROPA templates can help, but a template is not the control. The EDPB's 2025 consultation described a possible ROPA template as an example of a future ready-to-use compliance resource; it was a public consultation, not a final EDPB template. 6

The working standard is straightforward: organise the record around the purpose of the processing, connect every Article 30 field to the real activity, name the evidence and owner, and reopen the entry when the flow changes. A register that describes the work can support decisions. A register that only lists the tools cannot.