How to Build a ROPA That Works Under Indonesia’s PDP Law

A ROPA is a written record of every way your company processes personal data, from why you collect it to who can access it. It exists to prove that an organisation actually knows what happens to the data it holds, rather than just claiming to on paper.

That knowledge gap is real: a survey by Indonesia’s Services Dialogue (ISD) and the Digital Economy Ecosystem Development Agency at Kadin, Indonesia’s chamber of commerce, found that 81.3% of the digital businesses surveyed had no data protection officer at all. For a foreign company entering the Indonesian market, that’s a useful warning sign that local vendors and partners may be less compliance-ready than you’d assume.

Building a ROPA correctly the first time is what decides whether it becomes a document you can actually rely on, or one that just sits in a folder no one opens. This guide walks through both, starting with why Indonesian law requires one at all.

What Is a ROPA, and Why Does Indonesian Law Require One?

The obligation comes from Article 31 of Indonesia’s Law No. 27 of 2022 on Personal Data Protection (the “PDP Law”), which requires every data controller to keep a record of all personal data processing it carries out. This applies regardless of company size, and, importantly for a foreign audience, the PDP Law also applies extraterritorially, so a company can fall within its scope simply by processing the personal data of people in Indonesia, with no local entity at all.

Ignoring this obligation is not a paperwork risk. According to Rajah & Tann Asia’s analysis of the PDP Law’s implementing regulation, administrative fines can reach 2% of a company’s gross annual revenue, and that figure is based on gross revenue rather than net profit.

That implementing regulation, Government Regulation No. 33 of 2026 (“GR 33”), was signed on 16 July 2026 and takes effect on 16 January 2027 after a six-month transition. As of the most recent legal update available, GR 33 had still not been formally published on the government’s official gazette, though copies had circulated among practitioners since late August 2026, so it is worth confirming its status with local counsel before treating any specific article number as final.

Required Fields in a ROPA Template

A solid ROPA template covers five groups of information: controller identity, processing details, data flow, retention and security, and data subject rights. The table below breaks down what each group should capture, so you have something concrete to build from rather than a list of legal terms.

Group	Fields to Capture	Example Entry
Controller Identity	Controller/processor name and contact, DPO details (if appointed)	Acme Indonesia PT, dpo@acme-example.com
Processing Details	Lawful basis, purpose of processing, categories of data	New hire onboarding; based on employment contract; general data
Data Flow	Source of collection, third-party access, transfer destinations	HR intake form; payroll vendor; no cross-border transfer
Retention & Security	Retention period per data category, security measures	5 years after employee exit; encryption, restricted access
Data Subject Rights	Mechanism for handling access, correction, and deletion requests	Requests routed through HR email; 72-hour response target

According to Rajah & Tann Asia, GR 33 confirms a ROPA must function as both a register of processing activities and a data-flow map, so the “data flow” group above is not optional detail. For the full field-by-field legal breakdown, our complete ROPA guide covers each requirement in more depth.

How to Build a ROPA: 5 Practical Steps

Building a ROPA that holds up follows five steps in order: assemble a cross-functional team, inventory every processing activity, fill in the template per activity, flag risk and sensitive processing, then validate and schedule updates. Each step is explained below.

1. Assemble a Cross-Functional Team and Set the Scope

A ROPA built by one department alone, whether that’s IT or legal, will almost always miss activities only another team knows about. Bring in representatives from HR, finance, marketing, and operations for a short working session to map out every process that touches personal data.

Decide the scope up front too: is this ROPA for the whole organisation, or does it start with the business unit handling the most customer data. A clear scope keeps the project from stalling halfway through because it feels too large to finish.

2. Inventory Every Processing Activity

List every process that touches personal data, from the obvious ones like website checkout to the ones that slip through, like a marketing spreadsheet exported from a CRM. The UK’s data protection authority, the ICO, recommends a similar approach: send a short questionnaire to each business unit first, then follow up with interviews to dig out the details a questionnaire alone won’t surface.

Don’t ask “do you process personal data?”, because almost everyone will say no even when the honest answer is yes. Ask what systems people use day to day instead, then trace what data flows through them.

3. Fill In the Template for Each Activity

For every activity on your list, complete all five field groups from the template above, one activity at a time. Avoid copying the same entry into multiple rows to save time, since the small details that look interchangeable are usually the ones an auditor asks about first.

Payroll and marketing email, for instance, rely on different lawful bases and send data to different recipients. Those differences need to show up in the row for each activity rather than being flattened into one generic entry.

4. Flag Risk and Sensitive Processing

Mark any activity involving specific categories of data, such as health, financial, biometric, or children’s data. These activities may trigger an additional Data Protection Impact Assessment (DPIA) requirement, beyond simply being logged in the ROPA.

Flag any cross-border data transfer too, no matter how small. Rows like these need extra attention once you move into legal validation.

5. Validate, Store, and Schedule Updates

Send the draft ROPA to legal counsel or your data protection officer for review, with a firm deadline, five working days is a reasonable target. Ask reviewers to focus on three things: activities with no clear lawful basis, data being used beyond its original purpose, and cross-border transfers that lack a documented safeguard.

Store the final version in a shared, version-controlled location rather than a single laptop. Schedule a review at least every six months as a baseline, even if nothing has obviously changed.

Common Mistakes When Building a ROPA

There are at least 5 mistakes that most often keep a ROPA from doing its job. Spotting these patterns early saves a lot of rework down the line.

1. Involving only legal or only IT, when the most accurate operational details usually sit with the team that touches the data every day.
2. Copying the same entry across multiple rows, which strips out the specific detail that matters most during an audit.
3. Treating the first version as the finished product. Business activities keep changing, and a ROPA that isn’t updated becomes more misleading than having no ROPA at all.
4. Missing unofficial systems, such as personal spreadsheets or SaaS tools bought directly by one department without IT’s knowledge.
5. Skipping legal validation of each activity’s lawful basis, so processing that actually needs explicit consent ends up logged under “legitimate interest” instead.

Manual vs. Software: Which Approach Fits Your Company?

The right choice depends on how many processing activities you have and how often they change, not on personal preference. The table below compares both approaches across four factors companies typically weigh.

Factor	Manual (Spreadsheet)	Software / GRC Platform
Initial build time	Slower, since every field is entered and checked by hand	Faster, since templates and validation flows are already built in
Maintenance load	Grows as activities and systems are added	Stays fairly flat, since updates can be triggered automatically
Human error risk	Higher, especially when similar rows get copied without review	Lower, thanks to built-in format checks and update reminders
Readiness for a surprise audit	Depends on how disciplined the team is about keeping the file current	Stronger, since version history and changes are logged automatically

For a company with few, stable processing activities, a well-maintained spreadsheet is genuinely enough. Once the number of activities grows or data subject requests start arriving regularly, automating through a GRC platform tends to be more realistic than adding to a manual workload.

Conclusion

Building a ROPA properly is less about ticking a legal box than about gaining real visibility into where personal data actually flows through your organisation. A clear template, a consistent five-step process, and the habit of keeping the document current are what decide whether a ROPA is genuinely useful or just an archive nobody reopens.

Given how much of the Indonesian market is still catching up on data protection documentation, starting with a simple template beats waiting for ideal conditions that never quite arrive. A ROPA is a living document, not a one-time project, so the habit of reviewing it regularly matters more than getting the first draft perfect.

If the manual process above sounds like more than your team has time for, Adaptist Privee includes a Record of Processing Activities module that maps your data processing automatically, with built-in update reminders and audit-ready documentation. Contact us to see how it fits your organisation’s structure and processes.

FAQ