Skip to main content
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Category: Consent Records

Records of Processing

Also known as: RoPA, Records of Processing Activities, Article 30 records, processing records
Simply put

Records of Processing Activities are internal documents in which an organisation describes what personal data it handles, why, and how. Under the GDPR, they capture details such as the purposes of processing, the categories of data and individuals involved, and how long data is kept. They serve as evidence that an organisation understands and can account for its data processing, and must be provided to a supervisory authority on request.

Formal definition

Records of Processing (RoPA) are the documentation that controllers and, where applicable, processors are required to maintain under Article 30 of the EU GDPR (and the UK GDPR). Article 30 prescribes the specific information the records must contain, which generally includes the purposes of processing, categories of data subjects and personal data, categories of recipients, retention periods, and applicable safeguards, with the content differing between controller records and processor records (the latter covering categories of processing carried out on behalf of a controller). The records must be kept current to reflect the organisation's actual processing and must be capable of being made available to the relevant supervisory authority (such as the ICO in the UK or the DPC in Ireland) on request. RoPA is an accountability instrument; it does not itself establish a lawful basis or authorise processing, and Article 30 includes conditions that may narrow the obligation for certain organisations. Scope note: this entry addresses the EU/UK GDPR Article 30 obligation and does not cover analogous record-keeping requirements that may exist under US state privacy laws or other regimes, which differ in form and application.

Why it matters

Records of Processing Activities are a cornerstone of the GDPR's accountability principle. Under Article 30, controllers and, where applicable, processors are generally required to document what personal data they handle, why, and how, and they must be in a position to provide those records to the relevant supervisory authority on request. In practice, this means RoPA is often one of the first documents a data protection authority such as the ICO or the DPC may ask to see when reviewing an organisation's compliance posture, making it a tangible test of whether an organisation actually understands its own processing.

For cookie and tracking contexts, RoPA matters because the personal data collected through cookies, pixels, SDKs, and similar technologies typically constitutes processing that should be reflected in the records. Where consent or another lawful basis is relied upon for such processing under the GDPR, maintaining accurate records helps an organisation demonstrate that it can account for the purposes, data categories, and retention periods involved. RoPA does not itself establish a lawful basis or authorise any processing; it is an evidentiary and governance instrument rather than a permission.

Because the records must reflect the organisation's actual, current processing rather than a one-off snapshot, outdated or incomplete records can undermine an organisation's ability to respond credibly to a supervisory authority. Article 30 also includes conditions that may narrow the obligation for certain organisations, so the practical scope of the requirement depends on facts specific to each organisation.

Who it's relevant to

Privacy officers and data protection officers
Those responsible for accountability and governance typically own the RoPA process, ensuring the records accurately capture purposes, data categories, retention periods, and recipients across the organisation, and keeping them current rather than treating documentation as a one-off exercise.
Legal and compliance counsel
Counsel advising on GDPR obligations need to understand how Article 30 applies to their organisation, including the conditions that may narrow the obligation and the distinction between controller and processor records. They should note that RoPA is an evidentiary instrument and does not itself establish a lawful basis for processing.
Web developers and marketing compliance teams
Teams deploying cookies, pixels, SDKs, and similar technologies generate personal data processing that should generally be reflected in the records. Providing accurate detail on what these technologies collect and why supports the maintenance of complete and current RoPA entries.
Data processors and their representatives
Processors acting on behalf of controllers have their own Article 30 obligation to maintain records of the categories of processing activities they carry out, which differs in content from controller records and must also be available to supervisory authorities where the obligation applies.

Inside RoPA

Purposes of Processing
A description of why personal data is processed, which under Article 30 of the GDPR must be recorded for each processing activity, including cookie-related processing such as analytics or advertising that follows the placing of or access to information on a user's device.
Categories of Data Subjects and Personal Data
An account of the types of individuals affected (for example website visitors) and the categories of personal data involved, such as identifiers set or read through cookies, pixels, SDKs, or similar technologies where those identifiers relate to an identifiable person.
Recipients and Transfers
Details of the recipients to whom personal data are disclosed, including third-party vendors involved in advertising or analytics, and any transfers of data to third countries, together with information about applicable safeguards where relevant.
Retention Periods
Where possible, the envisaged time limits for erasure of the different categories of data, which for cookie-related processing may correspond to cookie lifespans or the retention of derived data.
Security Measures
A general description of the technical and organizational security measures applied to the processing, recorded where possible.
Controller and Processor Details
The identity and contact details of the controller (and, where applicable, joint controllers, the controller's representative, and the data protection officer), or of the processor and controllers on whose behalf a processor acts, depending on which party maintains the record.
Consent-Related Records (distinct but related)
Records of processing under Article 30 are distinct from consent logs kept to demonstrate valid consent under the GDPR and the ePrivacy rules; a complete accountability picture typically involves both, though they serve different purposes and are not the same document.

Common questions

Answers to the questions practitioners most commonly ask about RoPA.

Are records of processing the same thing as consent logs for cookies?
No. Records of processing (often associated with Article 30 GDPR obligations) are broader organizational documentation of an organization's processing activities, whereas consent logs are records capturing whether and how a user gave, refused, or withdrew consent for specific cookies or trackers. Cookie consent records support demonstrating valid consent under the ePrivacy rules and the GDPR's accountability principle, but they are typically one input into, not a substitute for, an organization's overall records of processing. The exact relationship depends on how an organization structures its documentation and on the applicable national implementation.
Does maintaining records of processing by itself make our cookie use compliant?
No. Documentation is an accountability and evidentiary measure; it helps demonstrate what you do and the basis for it, but it does not by itself establish that the underlying processing or the placing of cookies is lawful. In most EU jurisdictions you still need a valid legal basis under the GDPR for any personal data processing and, separately, valid prior consent (or an applicable exemption) under the ePrivacy rules for placing or accessing information on a device. Records evidence your practices rather than cure a defective consent flow, and legal judgment remains necessary.
What information about cookies is useful to capture in records of processing?
Organizations commonly document the categories of cookies and similar technologies used (for example strictly necessary, analytics, advertising, or functional), the purposes of the associated processing, the legal basis relied on, categories of personal data, recipients or third parties involved, and any international transfers. Because technologies such as pixels, SDKs, local storage, and fingerprinting can fall within the same rules as cookies, it is generally useful to capture those as well. The precise fields depend on your role (controller or processor) and the applicable national implementation; the general framing of Article 30 GDPR is often referenced here.
How should consent records and records of processing be kept in sync?
In practice, many organizations connect the two by mapping each cookie or tracker category in their processing documentation to the corresponding purpose and consent state captured by their consent management platform (CMP). Because cookie inventories change as tags and third parties are added or removed, periodic reconciliation between the CMP's records and the broader processing documentation helps keep both accurate. How you operationalize this depends on your tooling and internal processes, and a CMP supports but does not replace the legal review needed to confirm accuracy.
How long should consent records for cookies be retained?
There is no single universal retention period stated in this definition. Organizations generally retain consent records long enough to demonstrate that valid consent existed for the period during which cookies were placed, and to respond to inquiries or complaints, while balancing data minimization. The appropriate duration can vary by jurisdiction, the sensitivity of the data, and guidance from the relevant data protection authority, so it is best set with reference to applicable law and internal retention policies rather than a fixed number stated here.
Who is responsible for maintaining these records when a CMP or third-party vendor is involved?
Responsibility depends on each party's role. A controller generally retains accountability for its own records of processing even where a consent management platform or another vendor operates as a processor or provides tooling. Vendors acting as processors may have their own record-keeping obligations for the processing they carry out on the controller's behalf. Because arrangements differ, the allocation of responsibilities is typically set out in the contract between the parties, and the exact division can vary by jurisdiction and factual context not covered by this definition.

Common misconceptions

Records of processing are the same as the consent logs generated by a consent management platform (CMP).
They are distinct. Records of processing describe processing activities generally under Article 30 of the GDPR, while consent logs are evidence that a specific user gave freely given, specific, informed, and unambiguous consent. Both may be needed for accountability, but a CMP's consent records do not by themselves satisfy the record-of-processing obligation, and neither guarantees compliance without legal judgment.
Maintaining records of processing is only relevant to the placing of cookies, not to what happens afterward.
The ePrivacy Directive and its national implementations govern the placing of and access to information on a device, whereas records of processing under the GDPR concern the subsequent processing of any personal data. Where cookies, pixels, local storage, SDKs, or fingerprinting lead to processing of personal data, that processing generally needs to be reflected in the records, separate from the consent needed to access the device.
Every organization must keep records of processing in exactly the same form regardless of where it operates.
The Article 30 obligation is a feature of the GDPR and applies within its scope, with some limited exemptions for smaller organizations subject to conditions. Requirements and equivalent record-keeping expectations differ across the EU, the UK, and individual US state regimes such as the CCPA and CPRA, so scope should be assessed for the applicable jurisdictions rather than assumed to be universal.

Best practices

Maintain records of processing separately from, but cross-referenced to, your consent logs so that both the description of processing activities and the evidence of valid consent can be produced when needed.
Include cookie-related and similar-technology processing (pixels, local storage, SDKs, fingerprinting) in the records where it involves personal data, distinguishing the ePrivacy basis for accessing the device from the GDPR basis for the subsequent processing.
Record purposes, data categories, recipients, third-country transfers, retention periods, and security measures for each activity, and keep these entries current as vendors, tools, and processing purposes change.
Assess which jurisdictions' record-keeping obligations apply, since requirements differ between the EU, the UK, and US state regimes, and document your scoping rather than assuming a single standard.
Use prefer qualified retention and purpose descriptions and update them when data protection authority guidance or enforcement positions evolve, rather than treating any single record structure as definitively sufficient everywhere.
Review the records periodically with legal input, recognizing that maintaining them supports accountability but does not by itself establish that any specific processing or consent practice is lawful.
Application Security Isn’t Optional Anymore.