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.

Records of processing are not only a GDPR requirement

A documented inventory of processing is no longer a GDPR-only obligation. Minnesota’s Consumer Data Privacy Act, in effect since 31 July 2025, expressly requires controllers to maintain a data inventory. Under Minn. Stat. 325M.16 a controller must establish and maintain reasonable data security practices “including the maintenance of an inventory of the data that must be managed to exercise these responsibilities.” That is a record and inventory obligation in the same family as a GDPR Article 30 RoPA, distinct from a Data Protection Impact Assessment.

Other US state privacy laws, along with regimes in Brazil, Canada, and beyond, drive their own data-mapping and record-keeping expectations, and a single RoPA built well usually satisfies them together. These obligations apply wherever your company is based: serving people in a covered jurisdiction can bring you into scope, not only companies established there.

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 right.

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.

Note: Outsourced DPO is also referred to as external DPO, virtual DPO, fractional DPO, or DPaaS. Local-language equivalents include externer Datenschutzbeauftragter (Germany), DPO externe (France), DPO esterno (Italy), DPD externo (Spain).

  • Same-business-day response
  • Professional indemnity and cyber insurance
  • Named DPO notified to the supervisory authority

FAQ

Frequently asked questions

Do we need a RoPA if we have fewer than 250 employees?

Almost certainly yes. GDPR Article 30(5) has a narrow exemption for organizations under 250 employees, but 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 has to be in a RoPA?

For controllers, Article 30(1) requires the controller and DPO contact details, the purposes of processing, the categories of data subjects and personal data, the categories of recipients including those in third countries, transfer safeguards, the envisaged retention time limits where possible, and a general description of security measures. Processors maintain a processor RoPA under Article 30(2).

What is the most common RoPA mistake?

A spreadsheet that was built once and has not been updated in over a year, customer and employee data conflated into one entry, missed transfers to non-EU processors and sub-processors, and vague retention periods such as as long as necessary. Investor due diligence and supervisory authority requests often expose these gaps.

Do we need special software?

No. GDPR does not prescribe a format, and for most tech companies under 500 employees a structured spreadsheet maintained by the DPO is the right approach. Privacy management platforms can help at scale but are often overkill for smaller companies.

Can you build and maintain it for us?

Yes. RoPA development and maintenance is included in our DPO services, covering the initial build through structured discovery interviews, annual review and ad hoc updates, and preparation for audits or due diligence. For non-clients we engage on a focused project basis for an initial build, audit response, or diligence.