Understanding Record of Processing Activities (ROPA) for Businesses

A RoPA (Record of Processing Activities) is a written record that maps every personal data processing activity in an organization.

It does two jobs at once: it is accountability evidence that the organization manages data in line with the UU PDP (Indonesia’s Personal Data Protection Law), and it is a data map that answers “what data, for what purpose, who has access.” That duty is anchored in Article 31 of the UU PDP No. 27 of 2022, and it applies to every Personal Data Controller and Personal Data Processor. No business size is exempt.

What Is a RoPA?

Technically, a RoPA is built as a line-by-line inventory: each row represents one processing activity (for example “employee onboarding” or “customer KYC verification”), with columns detailing the data, purpose, legal basis, and parties involved. This pattern mirrors the register of processing under GDPR Article 30, but adapted to an organization’s structure and the UU PDP vocabulary.

Because Article 31 does not mandate a standard format, a RoPA can be a spreadsheet, an internal database, or a module within a compliance management system. What is mandatory: every activity is recorded, every change is traceable, and the record can be shown to the supervisory authority on request.

In the context of data governance, a RoPA performs three main functions:

1. Accountability Evidence. The RoPA is physical proof that the organization has consciously mapped its activities and their risks.
2. Data Map. This document answers the fundamental questions: what data we hold, for what purpose, and where it lives. Without a clear map, cybersecurity efforts are unfocused.
3. Compliance Foundation. The RoPA underpins other compliance activities, including risk assessments and responses to data subject rights requests within statutory deadlines.

RoPA Requirements Under UU PDP 2022

Indonesia’s regulation explicitly requires this document through UU PDP 2022. Ignoring a RoPA is not an operational oversight; it is a legal violation with administrative consequences.

Article 31 Recording Obligation

Article 31 of the UU PDP requires Personal Data Controllers to record all personal data processing activities. This provision grants no exemption based on business size. Whether you are a startup or a large corporation, the recording obligation applies equally.

Article 32: Access to Records

Article 32(1) and (2) requires Controllers to give Data Subjects access to the data being processed along with its processing history. The deadline is tight: access must be granted no later than 3 × 24 hours after the request is received. Without an organized RoPA, meeting this SLA is nearly impossible manually.

RPP Draft: Expected Components in RoPA

As of August 2026, the Draft Government Regulation (RPP) implementing the Personal Data Protection (PDP) Law has not yet been enacted, even though the initialing process is complete and the text is now simply awaiting Presidential ratification.

Based on the draft RPP (Article 87, paragraph 2), the Record of Processing Activities (RoPA) must include at least the following 12 components:

#	Component	UU PDP Reference
1	Name and contact details of the Controller, Joint Controller, and/or Processor	Article 1(4)
2	Contact of the Personal Data Protection Officer (if any)	Articles 53–54
3	Source of collection and purpose of transfer of the personal data	Articles 22, 55–56
4	Legal basis for personal data processing	Articles 20–21
5	Purpose of personal data processing	Article 28
6	Type of personal data (general/specific)	Article 4
7	Category of personal data subjects	Article 1(6)
8	Parties other than the Controller that may access the personal data	Articles 51, 55–56
9	Fulfillment of personal data subject rights	Articles 5–14
10	Mapping of personal data flows	Article 31
11	Retention period	Articles 43–44
12	Technical and organizational steps to secure the personal data	Articles 38–39

DPO note: Through Constitutional Court Decision No. 151/PUU-XXII/2024 (30 July 2025), the criteria for the obligation to appoint a Personal Data Protection Officer under Article 53(1) of the UU PDP are interpreted alternatively (“and/or”): meeting any one condition is enough, not all three cumulatively. The “if any” practice in row 2 still applies.

For Personal Data Processors, the record must contain at least four components: name and contact of the Processor, scope of activities, details of data transfers, and a description of security measures (Article 87(4) of the draft regulation).

Administrative Sanctions

Article 57 of the UU PDP sets out administrative sanctions: written warnings, temporary suspension of processing activities, deletion or destruction of personal data, and/or administrative fines of up to 2% of annual revenue (Article 57(2)–(3)). Sanctions are imposed by the supervisory authority; only the procedure for imposing them awaits enactment of the implementing regulation.

Who Must Maintain a RoPA?

This obligation extends to the entire data processing ecosystem, encompassing both data controllers and data processors.

A Controller is any person or body that determines the purpose of processing; its RoPA covers the big picture of business operations. A Processor (IT vendors, cloud providers, marketing agencies) must also maintain its own record of activities under Article 52, not merely rely on the Controller’s RoPA.

GDPR Comparison: The <250-Employee Exemption

By comparison, GDPR Article 30(5) exempts organizations with fewer than 250 employees, except for risky or regular processing. This exemption exists because the GDPR, in force since 25 May 2018, was originally designed to reduce the administrative burden on small businesses.

GDPR Article 30 also has extraterritorial reach: any organization outside the EU/EEA that offers goods or services to people there, or monitors their behavior, falls within scope under Article 3, meaning it still needs a RoPA for that processing.

No similar exemption exists in Indonesia’s UU PDP, enacted on 17 October 2022. Article 31 applies universally without a threshold, on the principle that the processing activity, not the size of the organization, determines the documentation requirement.

Jurisdiction Comparison

Framework	RoPA Required?	Notes
UU PDP (Indonesia)	Yes, mandatory	Article 31, universal, no size exemption
GDPR (EU/EEA)	Yes, mandatory	Article 30; <250-employee exemption with conditions; extraterritorial via Article 3

RoPA vs. Other Privacy Documents

A RoPA is often confused with other privacy documents, and the confusion is not harmless: building the wrong document means you believe you have met a legal obligation when you have not.

The table below summarizes the four documents most commonly swapped for one another, and the single paragraph after it explains how each one differs at its core.

Document	Main Function	Trigger	Output	Legal Status
RoPA	Inventory of processing activities	Any new business process	Processing catalog	Mandatory (Article 31)
DPIA	Privacy impact analysis	High-risk processing	Risk mitigation report	Conditionally mandatory (Article 34)
Privacy Notice	Public information for data subjects	Any data collection	Public document	Required at collection (Article 21)
Data Inventory	List of technical data assets	Any new system	Technical list	Not required by law

The key differences among the four lie in their perspectives and intended audiences. While both the RoPA and Data Inventory involve data mapping, the Data Inventory is essentially a list of technical assets.

If the RoPA is a list of business activities detailing which processes handle data, including the legal basis, purpose, and recipients, then the Data Inventory is a technical record specifying which systems store particular data and on which servers, serving IT and cybersecurity needs.

Meanwhile, a Privacy Notice is a public document for Data Subjects (based on Article 21) that answers the question, “What happens to my data?” whereas the RoPA is an internal document addressing, “What do we process, and is it all lawful?”

As for the DPIA (Article 34), the difference lies in the time dimension: the RoPA is a map of all activities maintained on an ongoing basis, whereas the DPIA is a one-off risk analysis for a specific high-risk processing activity (involving specific data, systematic monitoring, or new technologies), the results of which, including mitigation measures, are subsequently recorded in the RoPA.

How to Build a RoPA in 5 Steps

To make this concrete, we’ll follow a fictional case: Kopi Sari Rasa, an online coffee shop with 60 employees that processes customer data (orders, payments, delivery), employee data (payroll, health claims), and website visitor data (analytics cookies). Its CRM is hosted in Singapore, so there is a cross-border data flow.

1. Identify processing activities

Purpose: Find every business process that touches personal data.

Method: three complementary approaches.

• Cross-department workshop (90–120 minutes, the duration we typically recommend for organizations of 30–100 employees): invite the heads of finance, marketing, IT, and HR to list the processes that use personal data. Ask each participant to bring a list of the systems and forms they use. Important: don’t ask “do you process personal data?”, because everyone will say no. Ask “what systems do you use, and for what?”
• Email and form audit: ask IT to pull a list of digital forms (Google Forms, Typeform, internal CRM) and API integrations that send or receive customer data in the last 6 months. Many activities hide here, for example, a customer-satisfaction survey that quietly sends data to a marketing spreadsheet, or an email plugin storing customer addresses on a third-party server.
• Vendor interviews: IT vendors, cloud providers, and marketing agencies usually process data on your behalf. Their activities must also go into your RoPA, in addition to the vendor’s own internal RoPA.

For Kopi Sari Rasa, this process produced 23 activities, far more than the 12 initially expected, because hidden activities surfaced, such as sending order data to an accounting app and third-party analytics cookies on the website.

Output: a raw list of 20–50 activities (depending on organization size), usually kept as a separate sheet before being formalized. Don’t prune too early; it is better to have too many than too few at this stage.

2. Categorize data and subjects

Purpose: Flag a risk classification for each activity, because classification drives the legal obligations that follow: specific data puts a heavier burden on the Controller.

Method: For each row from step 1, fill in two additional columns:

Column	Classification	Legal Basis
Data type	General / Specific (health, financial, biometric, children)	Article 4 UU PDP
Subject category	Customer / Employee / Vendor / Public	Article 1(6)

Distinguish the two columns carefully: data type is about the content of the data (general vs. specific), while subject category is about who owns the data (customer, employee, and so on). One activity can combine both, for example, payroll processing handles specific data (salary, health history for claims) belonging to the employee subject category.

Activities involving specific data require an additional DPIA under Article 34, because specific-data processing is classified as high risk. Activities involving cross-border transfers require extra records in step 3. For Kopi Sari Rasa, customer payment data and employee health-claim data were immediately flagged as specific, and both became DPIA candidates.

Output: two classification columns filled in the RoPA spreadsheet, with visual markers (colors/icons) for high-risk activities, so later audits can prioritize the riskiest rows.

3. Document each activity

Purpose: Fill in the 12 draft-regulation components per activity. The full list of 12 components is covered in section 2.3 above; here we focus on how to fill each component with a concrete example rather than repeating the table.

Method: Use draft Article 87(2) as a checklist. For each activity, complete the 12 columns in a spreadsheet or database. Here is how two Kopi Sari Rasa activities would be filled in, so you can see how each component is actually completed:

Component	Activity A: Customer order processing	Activity B: Employee payroll
Name & contact of Controller/Processor	PT Kopi Sari Rasa	PT Kopi Sari Rasa
DPO contact (if any)	(not yet appointed)	(not yet appointed)
Source of collection & purpose of transfer	Website checkout form; data sent to payment gateway	HR portal; salary data sent to bank and tax app
Legal basis	Contract performance (Article 20(2)(b))	Legal obligation (Article 20(2)(c))
Purpose of processing	Process and deliver customer orders	Pay salaries and report taxes
Data type	General (name, address, order history)	General (name, salary) + specific (health claims)
Subject category	Customer	Employee
Recipients	Payment gateway, courier, fulfilment team	Bank, tax app, health insurer
Subject rights fulfillment	Via account page; requests to support	Requests to HR
Flow mapping	Website → CRM database → payment gateway → courier	HR portal → company server → bank
Retention period	5 years after the last order	Per the employee-records retention schedule
Security steps	TLS encryption, restricted fulfilment-team access	Separate HR access, two-factor authentication

Notice how the two activities produce different entries in almost every column, and that is exactly how it should be. The most common mistake in this step is copying the same content into every row. A good RoPA is one where each row differs because it reflects reality.

Output: a complete RoPA with 12 columns per activity. One row per activity makes filtering and auditing easy.

4. Validate with legal team and DPO

Purpose: Catch inconsistencies before they become audit findings. A RoPA drafted by the operations team almost always contains legal assumptions that are wrong: this is where the legal team earns its keep.

Method:

• Send the draft to the legal team for review with a 5-business-day target. Ask them to flag three specific things: activities without a clear legal basis (for example, processing customer data without one of the Article 20 bases), data that exceeds its purpose (Article 28, for example, using order data for email marketing without a separate basis), and cross-border transfers that lack protection mechanisms (Article 56).
• Involve the Personal Data Protection Officer (if any, per Articles 53–54) for independent validation. If there is no PDPO, ask the reviewing lawyer to play that role.
• Hold a review meeting (60–90 minutes) to discuss findings and decide on changes. Don’t let the review run through email ping-pong without a written decision.

At Kopi Sari Rasa, the review surfaced two important findings: the email-marketing activity was registered under “legitimate interest” when it should have been explicit consent, and the transfer to the Singapore CRM had not recorded a protection mechanism as required by Article 56(2)–(4). Both were fixed before the document was approved.

Output: an approved/signed RoPA, with documentation of who reviewed it and when; the review trail itself has value during an audit.

5. Store it and set update triggers

Purpose: Keep the RoPA current. A stale RoPA is as dangerous as having none: it is worse, because it creates the illusion of compliance.

Method:

• Store it in a central repository (shared cloud drive, internal wiki, or compliance module) with version control, not a local file on one person’s laptop. A central repository ensures everyone reads the same version.
• Build an automatic trigger list based on the 7 events in “When Should You Update Your RoPA?” below. Wire the list into regular operations meetings so triggers don’t depend on one person’s memory.
• Schedule a regular review every 6 months, even without changes, because business activities change faster than we realize.
• Assign a PIC (person in charge) for updates so responsibility does not drift. One named owner beats “everyone is responsible.”

Output: a living RoPA, not a one-off document, but a system that evolves with the organization’s activities. At Kopi Sari Rasa, the first trigger came just 3 months after drafting: they added a loyalty-program feature that collects points data, and the new row was added within a week.

When Should You Update Your RoPA?

A RoPA is not a one-time document. Each event below changes the reality of processing, and when reality changes, a record that does not change with it becomes misleading. Here is each trigger and why it matters:

• Change in the purpose of processing. When data collected for one purpose (say, order delivery) is used for another (say, behavior analysis), the RoPA row must be updated and the new purpose must have its own legal basis. Article 28 requires processing to stay within the purposes already communicated.
• New data category added. Starting to collect location or health data? The activity row grows or shifts from general to specific data, and as we saw in step 2, that shift can trigger a DPIA obligation.
• Replacement or addition of a vendor/processor. Every new Processor is a new recipient and must be recorded in the recipients column with its contact details. A new vendor also means checking that data protection is covered in the contract.
• New cross-border data transfer. Moving data to a controller/processor outside Indonesia triggers Article 56: the Controller must ensure the destination country has an equivalent level of protection, or ensure adequate and binding protection, or obtain the data subject’s consent. Such an activity must never be recorded merely as an “internal transfer.”
• Cybersecurity incident. After an incident, the recorded data flows and security steps need review, for example, if the incident revealed that data was exposed without protection, the security-steps column must be revised.
• Regulatory change. Enactment of the Government Regulation implementing the UU PDP will almost certainly change component details or related obligations. A well-kept RoPA records a “last reviewed” date so regulatory changes can be mapped.
• Merger, acquisition, or organizational restructuring. A new controller, database consolidation, or a changed recipient hierarchy is a major change to nearly every column, and notifying data subjects of the data transfer is itself required under Article 48.

Our recommended practice: schedule a review twice a year as a safety net, and don’t wait for a trigger to look at the trigger list itself. The list grows with the business.

When Is a Manual RoPA Enough?

A spreadsheet RoPA remains valid for organizations meeting the following conditions:

• Fewer than 50 employees
• Single, stable processing activity
• No cross-border data transfers
• Fewer than 5 data subject requests per month

This figure was selected because each threshold marks a point where the pace of change can still be managed by a single person without system assistance.

With fewer than 50 employees, the volume of activities can generally still be tallied manually; stable activities mean data rows rarely change; the absence of cross-border transfers eliminates the need to track data across jurisdictions; and with fewer than five subject requests per month, the 3×24-hour SLA mandated by Article 32 remains achievable through manual spreadsheet searches.

Note: These thresholds do not constitute a formal rule under the Personal Data Protection (PDP) Law. Article 31 does not differentiate record-keeping methods based on organizational size. However, once any of these thresholds is exceeded, spreadsheets become inadequate, and automated updating becomes mandatory.

Benefits of a Well-Maintained RoPA

A well-organized RoPA delivers three measurable benefits:

1. Legal compliance. The RoPA is the first and easiest piece of accountability evidence an authority checks. When an inspection comes, an organization with a complete RoPA can present a single document that answers every basic question (what, why, where to, how long); one without it must gather answers across departments while racing a deadline. This benefit directly prevents the administrative sanctions of Article 57.
2. Audit efficiency. Audit preparation drops from months to weeks because most of the data auditors ask for (processing trails, legal bases, recipients) is already laid out row by row. The team no longer has to guess or chase other people for information that should already be documented.
3. Fast subject-right response. The Article 32 SLA is 3×24 hours. Without a data map, locating all copies of a person’s data can take days; with a RoPA, you immediately know which systems hold the subject’s data, who the recipients are, and how long it is kept, so access, correction, and deletion requests can be handled within hours.

Conclusion

A RoPA is not merely a bureaucratic document. Article 31 of UU PDP 2022 makes it a universal legal obligation, and in practice it is the foundation of the entire compliance program: the data map on which the Data Inventory, the Privacy Notice, and the DPIA all stand. For simple activities, a structured spreadsheet is sufficient.

For activities that keep growing (like Kopi Sari Rasa with more than 50 employees and cross-border data flows), automation becomes necessary to maintain compliance without sacrificing operational efficiency.

FAQ