Records of Processing Activities (RoPA) Services

Records of Processing Activities, often called RoPA, is the GDPR Article 30 requirement to maintain a documented inventory of all personal data processing activities. The requirement applies to most companies subject to GDPR. Failure to maintain RoPA is one of the most common findings in supervisory authority investigations.

This page covers what RoPA requires, common mistakes, and how to build and maintain it efficiently.

Who needs RoPA

GDPR Article 30(1) requires controllers to maintain RoPA. Article 30(2) requires processors to maintain processor RoPA.

Article 30(5) creates an exemption for organizations with fewer than 250 employees, but the exemption is narrow and rarely applicable in practice. It does not apply if processing is likely to result in a risk to data subjects, processing is not occasional, or processing includes special category data or criminal convictions.

Most tech companies should assume the exemption does not apply and maintain RoPA regardless of size.

What RoPA must contain

For controllers, Article 30(1) requires:

  • The name and contact details of the controller, joint controller if applicable, the controller's representative, and the DPO.

  • The purposes of the processing.

  • A description of the categories of data subjects and the categories of personal data.

  • The categories of recipients to whom the personal data has been or will be disclosed, including recipients in third countries or international organizations.

  • Where applicable, transfers of personal data to a third country or international organization, including identification of the country or organization and documentation of suitable safeguards.

  • Where possible, the envisaged time limits for erasure of the different categories of data.

  • Where possible, a general description of the technical and organizational security measures.

  • For processors, Article 30(2) requires similar content with adaptations for the processor role including the categories of processing carried out on behalf of each controller.

Common mistakes

The RoPA exists in spreadsheet form but has not been updated in over a year. Processing activities change. RoPA must change with them.

The RoPA conflates categories. Customer data and employee data are separate categories with separate lawful bases, retention, and security measures. They should be separate entries.

The RoPA misses transfers. Many companies forget to document personal data flowing to non-EU processors and sub-processors.

The retention periods are vague ("as long as necessary") rather than specific.

Security measures are described in generic terms rather than mapped to the actual measures in place.

The processor RoPA does not exist when the company is acting as processor for some processing activities and controller for others.

The RoPA has not been reviewed since the program was originally built. Investor due diligence and supervisory authority requests often expose this.

Building RoPA

Step 1: Identify all processing activities. Interview product, engineering, sales, marketing, HR, legal, and finance teams. Each function processes some personal data.

Step 2: Categorize by purpose. Group processing by purpose. Common categories for tech companies include product service provision, customer support, marketing, sales operations, employee management, fraud and security, analytics and product improvement, vendor management, and legal compliance.

Step 3: Identify data subjects and data categories for each. What types of people are involved (customers, prospects, employees, etc.) and what categories of data are processed.

Step 4: Identify lawful basis and Article 9 condition if applicable. For each processing activity, document the GDPR Article 6 lawful basis and Article 9 condition for special category data.

Step 5: Identify recipients. Where does the data go? Internal teams, third-party processors, sub-processors, joint controllers.

Step 6: Identify transfers. Are any recipients outside the EEA? What transfer mechanism applies?

Step 7: Document retention. How long is the data kept and what triggers deletion?

Step 8: Document security measures. Technical and organizational measures appropriate to the risk.

Step 9: Build the RoPA document. Spreadsheet, dedicated tool, or other structured format. The format does not matter; the content does.

Step 10: Establish review cycle. RoPA is a living document. Review at least annually and update for any significant processing change.

Tools and formats

GDPR does not prescribe a format. RoPA can be a spreadsheet, a dedicated privacy management tool entry, or a structured document.

Privacy management platforms like OneTrust, TrustArc, BigID, Securiti, and DataGrail offer RoPA modules. These can be useful at scale but are often overkill for smaller companies.

For most tech companies under 500 employees, a structured spreadsheet maintained by the DPO is the right approach. Costs nothing, easy to update, simple to share with auditors and regulators.

How Engage Compliance helps

RoPA development and maintenance is included in our DPO services for clients. Specific work includes:

  • Initial RoPA build through structured discovery interviews with internal stakeholders.

  • Annual RoPA review and update.

  • Ad hoc updates when processing changes significantly.

  • RoPA preparation for supervisory authority requests or audits.

  • RoPA preparation for investor due diligence or M&A diligence.

  • Controller and processor RoPA where the company has both roles.

For non-clients with a specific RoPA need (initial build, audit response, due diligence), we engage on focused project basis.

Get started

If you need RoPA built, updated, or audited, book a consultation.