When Is a PIA Mandatory in Indonesia? 7 Legal Triggers

A PIA is a structured review that checks whether a personal data processing activity carries high risk to the people it affects, done before that activity goes live rather than after. In Indonesia, the same process is also called a DPIA or Penilaian Dampak Pelindungan Data Pribadi, three names for one requirement.

The need for this review is only growing as new technology spreads through business operations. Cisco’s own 2025 AI Readiness Index found that 83% of organisations worldwide plan to deploy AI agents within the next year, and a good share of that rollout will touch the personal data of people in Indonesia without anyone flagging it as a PIA trigger.

The trouble is that companies often treat “when is a PIA mandatory” as a vague judgment call, when Indonesian law actually spells it out. This article breaks down each trigger, with concrete examples of where it shows up in practice.

What Is a PIA?

The obligation comes from Article 34(1) of Indonesia’s Law No. 27 of 2022 on Personal Data Protection (the “PDP Law”), which requires a data controller to carry out an impact assessment whenever its processing carries high risk. As with the PDP Law’s other obligations, this applies extraterritorially, so a foreign company can trigger the requirement simply by processing the personal data of people in Indonesia, even without a local entity.

A PIA is meant to happen before a system or feature launches, not as a review written after something has already gone wrong. That timing is what separates a PIA from an incident report: one prevents harm, the other only explains it.

7 Triggers That Make a PIA Mandatory Under Article 34

Article 34(2) of the PDP Law lists 7 categories of processing that are automatically treated as high risk, so a PIA becomes mandatory the moment any one of them applies. Skipping this obligation carries real cost too, since Indonesia’s Article 57 sets administrative fines of up to 2% of gross annual revenue, a figure that Government Regulation No. 33 of 2026 confirms is based on gross revenue rather than net profit.

1. Automated Decisions With a Significant Effect

This applies when a system decides without human review and that decision carries legal weight or a significant effect on the person involved. An automated system that rejects a loan application based purely on an algorithmic credit score is a clear example.

2. Processing of Specific Categories of Data

This covers health, biometric, genetic, or children’s data, categories the PDP Law treats as inherently more sensitive. The more sensitive the data, the greater the potential harm if something goes wrong.

3. Large-Scale Processing

This applies once the volume of data, number of people affected, or scope of processing is large relative to the size of the organisation. GR 33 confirms that “large-scale” is judged contextually, weighing data volume, the number of data subjects, duration, data type, purpose, and geographic scope, rather than a fixed numerical threshold.

4. Systematic Evaluation, Scoring, or Monitoring

This includes credit scoring, automated performance reviews, or continuous monitoring of employee productivity. It’s the systematic, repeated nature of the monitoring that triggers this category, not a one-off check.

5. Matching or Combining Data From Different Sources

This applies when data from two or more systems is combined to build a fuller profile of a person, for example merging transaction history with social media activity. Combining sources like this can surface things about someone that no single source would reveal on its own.

6. Use of New Technology

This covers technology not yet in widespread use, such as artificial intelligence or facial recognition. GR 33 specifies that “new technology” includes artificial intelligence, machine learning, smart technology, and the internet of things as its own separate trigger.

7. Processing That Restricts Data Subject Rights

This applies when a system’s design makes it harder for someone to exercise their rights, such as an account deletion flow built to be deliberately confusing. This runs directly against the PDP Law’s guarantee that people can access, correct, and delete their own data.

5 Business Scenarios That Almost Always Require a PIA

The legal triggers above only become useful once mapped onto situations a business actually runs into. Here are 5 scenarios that consistently trigger the PIA requirement.

1. A fintech startup launches automated credit scoring based on a user’s transaction history, meeting both the automated-decision and new-technology triggers at once.
2. A digital health platform shares users’ medical history with pharmacy partners for a loyalty programme, meeting both the specific-data and data-combining triggers.
3. A national retailer installs facial-recognition CCTV across every store, meeting the large-scale, systematic-monitoring, and new-technology triggers simultaneously.
4. An HR team rolls out employee monitoring software that logs keystrokes or tracks location, falling under systematic evaluation and monitoring.
5. A personal finance app makes account and data deletion deliberately difficult to complete, falling under the data-subject-rights restriction trigger.

When Is a PIA Not Required?

A PIA isn’t mandatory when none of the 7 triggers above apply and the processing is routine, low-risk activity. The UK’s ICO takes a similar view: a single risk factor can sometimes be enough on its own, but two or more factors together are a much stronger signal that an assessment is needed.

As a rough guide, a PIA usually isn’t required for basic internal HR data on a small team, or for a newsletter with a clear subscribe and unsubscribe flow. It’s still good practice to document why a given activity was judged low risk, even when a PIA isn’t legally required, since that record is useful if an auditor ever asks.

Conclusion

When a PIA is mandatory in Indonesia isn’t really a guessing game, since Article 34(2) of the PDP Law already lays out 7 concrete triggers to check against. The real challenge is spotting those triggers in everyday work, particularly when a product or marketing team ships a new feature without realising it now falls into a high-risk category.

The earlier these triggers get caught, the cheaper they are to address, compared with waiting for an incident or a regulator’s letter to force the issue. Checking against this list at the start of a project costs far less than fixing the same gap after the system is already running.

FAQ