ROPA for Cookies: Building an Article 30 Record for Your Trackers

What Article 30 Actually Requires

A record of processing activities (ROPA) is the internal register that says, in one place, what personal data your organisation processes and why. Article 30 of the GDPR makes it a written obligation, electronic form is fine, and Article 30(4) says you have to produce it to a supervisory authority on request. It's the document a regulator asks for first, because it reveals whether you actually understand your own data flows.

Cookies are where a lot of ROPAs fall short. The register lists the CRM and the payroll system but says nothing about the analytics, advertising, and session-replay trackers quietly collecting online identifiers on every page. Those are processing activities too, and Recital 30 is explicit that online identifiers like cookie IDs count as personal data.

The "Fewer Than 250 Employees" Trap

People reach for the small-business exemption and assume it lets them off. Read it carefully. The obligation still applies to an organisation with fewer than 250 staff if any of the following is true: the processing is likely to result in a risk to people's rights and freedoms, the processing is not occasional, or it involves special-category data or criminal-offence data.

Run your cookies through that test. Behavioural advertising and analytics running on every visit are the definition of "not occasional," and profiling for ad targeting carries a risk to rights. In practice the exemption almost never covers the marketing trackers on a live commercial website, which is why most guidance treats a ROPA as effectively mandatory.

What Goes in a ROPA Entry

Article 30(1) lists what a controller's record must contain. For a cookie-driven activity, each field has a concrete answer:

• Controller and DPO contact details, plus any joint controllers (relevant when an ad platform is a joint controller with you).
• Purposes of the processing, for example audience measurement, or conversion attribution for advertising.
• Categories of data subjects, typically website visitors and, where relevant, customers.
• Categories of personal data, online identifiers, device and browser data, IP-derived location, and behavioural events.
• Categories of recipients, the vendors that receive the data: your analytics provider, ad networks, tag managers.
• Transfers to third countries and the safeguard relied on, such as Standard Contractual Clauses or a Data Privacy Framework certification.
• Envisaged erasure time limits, which is where your retention schedule plugs straight in.
• A general description of security measures.

From Cookie Inventory to ROPA Rows

The good news: a cookie scan already gives you most of these fields. You group the trackers by purpose, and each group becomes a processing activity. Here's one filled-in row for the advertising cookies on a typical e-commerce site.

Controllers and Processors Both Keep Records

Article 30(1) covers controllers. Article 30(2) sets a shorter list for processors, who record the categories of processing carried out on behalf of each controller, transfers, and security measures. If you're an agency running tags on a client's site, or a platform processing consent data on a customer's behalf, you keep 30(2) records too. Knowing which hat you wear for each activity is half the work, and it ties directly to your data processing agreements.

Keeping It Current

A ROPA rots the moment a marketer adds a tag. Every new tracker can introduce a new recipient, a new transfer, and a new retention question. The fix is to tie the register to a recurring scan rather than an annual spreadsheet review. When a scan detects an unfamiliar cookie or a new outbound connection, that's your prompt to add or update a ROPA row before the tag has been live for a quarter.