Skip links
records of processing activities

A Step-By-Step Guide To Records of Processing Activities (RoPA)

The proactive approach to data privacy from key legislations on data protection like the GDPR makes compliance no picnic. Ask any DPO, the process often entails a laundry list of data obligations to be met. 

It doesn’t stop at managing the data lifecycle end-to-end: companies must assess the data privacy risks in their business model to mitigate them. 

In many ways, it’s a game of ball juggling, where dropping one ball can spell doom to the compliance efforts of even the most well-intentioned and attentive of teams. With this in mind, data privacy regulators deploy certain mechanisms to help companies ensure their ducks are in a row. The RoPA falls under this category. 

In this article, we’ll be showing you the ropes around all things “RoPA” — what a RoPA is, why it has become such a mainstay in data privacy compliance (the GDPR + CCPA), and finally, how to create one.


What is RoPA?

Record of Processing Activity (“RoPA”) does what it says on the tin: think of it as a record book of data transactions carried out over time, and throughout their entire lifecycle.

RoPA was once a term peculiar to the GDPR, which explains the trending “GDPR RoPA” searches globally, but now, it’s become the generic term for tracking and recording personal data cycles. 

Presenting your RoPA upon the request of the ICO (Information Commissioner’s Office), DPA (Data Protection Authority), or any relevant authority in your jurisdiction shows you have assessed the full ramifications of all data processing activities in your organization. 

In keeping with a core principle of the GDPR — the principle of accountabilityArticle 30 of the GDPR imposes an obligation on data controllers and processors to record their data processing activities. 

Article 30 offers a reliable blueprint for structuring RoPA data points. For a data controller, here are some key questions it should typically address: 

  1. Actors involved: Contact details of the data controller and their representatives. Include information about the appointed data protection officer (DPO) where applicable.
  2. Processing Purposes: The intended reasons for collecting and using personal data. This asks the question, “what is the lawful basis for processing?” 
  3. Data Subject Categories: Classes of individuals whose data they process (e.g., customers, employees, website visitors). 
  4. Data Categories: Specify the types of personal data they collect and handle (e.g., names, addresses, financial information, health data). 
  5. Data Recipients: Identify any third parties who receive or potentially access the personal data, including organizations outside their country. Indicate any international transfers and the safeguards in place for such transfers. 
  6. Data Retention Periods: If possible, estimate how long they intend to store different categories of personal data before deletion. 
  7. Security Measures: Provide a general overview of the technical and organizational measures (including but not limited to data encryption, anonymisation, restricted access to certain documents and data, and staff training) used in securing personal data, without revealing sensitive details. 


For data processors, here are the data points: 

  1. Actors involved: Contact details of the data processor. Include information from the hiring controller, as well as the appointed data protection officer (DPO) where applicable.
  2. Data Categories: Specify the categories of data processing conducted on behalf of the controller (e.g., names, addresses, financial information, health data). 
  3. Data Recipients: Identify any third parties who receive or potentially access the personal data, including organizations outside their country. Indicate any international transfers and the safeguards in place for such transfers. 
  4. Security Measures: Provide a general overview of the technical and organizational measures (including but not limited to data encryption, anonymisation, restricted access to certain documents and data, and staff training) used in securing personal data, without revealing sensitive details. 

Beyond these fundamentals, the GDPR specifically requires an entry of information explaining personal data flow within and outside their organisation into RoPA. 

This should also accompany the “legal bases” (as defined in Article 6) for collecting, using, and disclosing all personal data.

A ‘living’ document 

Your RoPA is anything but a one-and-done document. It’s an organic, living document that scales with you and should be updated at regular intervals to reflect the evolving nature of data processing activities in your firm. 

As you introduce new data sets, perform new processing activities in line with business objectives, or change vendors in the ordinary course of business, you’re required to continuously update your RoPA. 

Ideally, any changes in the conditions of processing implementation for each activity entered in your RoPA should prompt an update

Who Keeps a RoPA?

The responsibility for maintaining the Records of Processing Activities (RoPA) lies with the controllers or processors themselves. This ensures that they have a bird’s eye view of all personal data processing activities within their purview.

Within the organization, an individual may be designated specifically to oversee the RoPA. In other cases, if the organization has appointed a Data Protection Officer (DPO), whether internal or external, they can assume responsibility for managing the RoPA

At all times, there must be a dedicated individual overseeing compliance and maintaining the necessary records regarding data processing activities.

Records of processing activities example

There have been a few templates published by regulatory authorities to give companies a workbench for their compliance efforts as it relates to keeping a RoPA.

One of these examples of records of processing activities is RoPA by CNIL in France. This RoPA is stacked with all the fields mentioned under Article 30 GDPR. The UK’s ICO’s template is another record of processing activities example, but rather a long one.

What are the benefits of Record of Processing Activities (RoPA)?

Another regulatory burden that could’ve simply been an email sent from your DPO on request? Not quite. 

To put it bluntly, viewing your RoPA that way would be most unhelpful. The RoPA is your friend — a vital cog in your compliance wheel; in the following ways:

Present & future regulatory compliance: 

On the regulator side, authorities can quickly assess your organization’s processing activity to make considered decisions or offer guidance without the overwhelm of sifting through granular data.

Sequel to the GPRA which enforces RoPA, several legislations after that like the CCPA & CPRA did not mandate RoPAs, but practically speaking, strict compliance with the provisions of these laws without keeping one would be a long shot. 

Having a RoPA means one less worry for your privacy team in satisfying any of these new data privacy obligations. 

Internal utility: 

Away from the regulators, the RoPA serves as a single source of truth for companies to help manage and understand their data flow better. 

This helps spot data redundancies, minimize risks, and create a far more robust data privacy infrastructure that creates more business value. 

A privacy-conscious culture:

Your corporate culture is also set to benefit, as you stand to inculcate more privacy awareness in your organization, so teams are more in tune with how data is being processed. 

This helps them understand how to ethically support company-wide efforts in the direction of privacy strategy, data governance, and business analysis.

Brand trust & credibility:

RoPA presents an aerial view of your company-wide data operations to your customers and other stakeholders. This builds credibility and trust by letting them know that data protection is your cup of tea. 

As a spin-off, brand image is enhanced, as the company’s status as a trust-worthy partner — one where customers hardly ever have to constantly look over their shoulders in fear of a data breach — is reinforced. 

ccpa gdpr


The GDPR, however, exempts organizations boasting fewer than 250 employees if: 

  • Data processing activities are few and far between (“occasional”);
  • Their data processing activities pose little to no risk to the rights and freedom of data subjects (for instance, geolocation systems or video surveillance, etc); or 
  • Data being processed do not fall under a category of sensitive data relating to race, ethnicity, health, or relating to criminal conviction or offense. 

Given the ubiquity of certain data sets, as well as how often companies tend to process data as part of their standard procedures (companies process data to run their payroll, CRM systems, or even something as routine-ish as offering a service to customers), these ‘exemptions’ will operate more in theory than in practice. 

Couple that with the ambiguity that plagues the term “occasional” (i.e., How seldom is “occasional?” How often is “not occasional?”), and it becomes immediately obvious; Companies would be wise to err on the side of caution in keeping RoPA — without recourse to any seeming ‘exemptions’.


As earlier mentioned, the CCPA/CPRA does not mandate the RoPA, stricto sensu. However, it would go on to impose an obligation for companies to keep and maintain records of verifications of requests. 

With the California Privacy Protection Agency (CPPA), the enforcement arm of the CPRA, granted powers to make orders on record-keeping for business, it remains to be seen if RoPA is made mandatory.  

Peering beyond the letters of the law, since the CPRA/CPRA requires a full disclosure as to processing, sharing, or sale of personal data, it would be practically impossible to comply with the CCPA/CPRA without a RoPA, or a RoPA-style log of data activity at the very least.

Organizations for which it would be instructive to keep a RoPA are the same as those covered under the CCPA/CPRA:  businesses, service providers, and third parties, with the admixture of a fourth category created under the CPRA: contractors.

How to create a compliant RoPA?

Article 30 lays out the form of a RoPA. It should be in writing and in an electronic form, so it is amenable to changes and edits as may be necessary from time to time.

As such, Microsoft Excel Sheets and Google Spreadsheets are usually the first port of call for most privacy teams/DPOs. 

However, they are usually long, hectic, and hard to navigate. Luckily, you can use hoggo’s My Vendors and export a dedicated vendor RoPA which maps your data flows with and to your vendors. 

Whichever solution you go with, here’re a break down of the steps involved in creating a compliant RoPA:

Preliminary step: Data Mapping 

A comprehensive data audit or data mapping exercise helps you uncover what data your organization holds and where. In other words, it helps you map personal data flow and processing activities at all levels. 

Very often, companies would engage external consultants for the initial mapping of RoPA and deploy DPO-as-a-Service solutions for ongoing DPO duties.

Data Mapping is within the job description of your Data Protection Officer (DPO). But in the absence of a DPO, any employee with the necessary qualifications can perform this task. 

The mapping process involves identifying information systems and personal data to understand the data held and its locations within the organization; Involve key internal stakeholders across departments to ensure a wide coverage and to avoid information gaps in your findings.

Compile a survey/questionnaire 

Launch an inquiry into departments in your company that handle personal data. Keep things simple with your questioning. You could ask questions like: 

  • How do we use personal data?
  • Who do we collect personal data from?
  • What personal details do we have about them?
  • Who do we share this information with?
  • How long do we keep this data before deletion?
  • How do we protect personal information?

Interview Key Stakeholders 

Secure the buy-in of your higher-ups and other key stakeholders within the organization. Doing this achieves two things: 

  1. They understand the import of your data mapping exercise; and 
  2. They share more insight into how data is being processed by certain parts of your organization. 

For instance, IT staff could answer on technical security measures, and Information governance staff can reveal more about retention periods. Equally, legal & compliance staff can lay out the full repertoire of data-sharing arrangements struck with other third parties.

Review policies, procedures, and agreements

Besides the legal due diligence you will be carrying out, you can benchmark your actual processing practices against industry best practices. A few of the documents you should be looking at here are: 

  • Data protection policies
  • Data retention policies 
  • Privacy policies 
  • System use policies 
  • Data processor contracts
  • Data sharing agreements 
  • Data security policies

Document your findings

At risk of sounding like a broken record,  your documentation must be in writing, which may come in electronic or paper form. 

One rewarding perk of the electronic form is the ability to add, subtract, and edit your documents as necessary, which makes it the natural fit for companies with very frequent processing activity. 

In any case, you want a granular inventory of all your processing activities based on a data mapping exercise that is reviewed regularly. 

The test for granularity here is sufficient context. Delineate personal data into separate categories, stating their respective purposes and attributes. 

For example, data retention periods might differ across a vast range of categories of data. Reflecting this in your documentation will give the viewer as much structural and contextual meaning as possible. 

To achieve full compliance, steer clear from generic descriptions with no meaningful context to meet compliance requirements. For your continuous documentation needs, you can ditch the traditional survey and spreadsheets for a dedicated data mapping automation (SaaS) solution with these functionalities:

  • Central management of data from one secure dashboard; 
  • Integrates seamlessly with other systems;
  • Automated Data removal;
  • Seamless collaboration throughout all department;
  • DPO control panel + segregation of ownership of activities; and
  • Tracking changes in data.

Cruising to compliance, RoPA in hand

Out of the operational underbelly of every company flows rivers of ‘living’ data. This river containing data is a free-flowing asset, which, to be fair, is prone to veering off its intended course and seeping into other departments, third-party vendors, or even data owners themselves. 

For this reason, companies must build a water-tight data mapping framework, to be the single source of data truth where teams can monitor and manage data from. 

Alas, it doesn’t take being a DPO to unpack RoPA’s value beyond data privacy compliance, as companies would be wise in leveraging RoPA to pull double duty — both as compliance tool and corporate asset.

Peter Oladimeji

Peter is a Nigerian-based attorney with a bias for data privacy & intellectual property. When he's not exploring the curiosities of the in-betweens, he's recoiled in his couch, reminiscing the Manchester United of his childhood, or lost in maladaptive daydreams of the club’s return to former glories.