If your product touches users in Indonesia, the country's Personal Data Protection Law — UU PDP, Law 27/2022 — is now fully in force. The two-year transition ended in October 2024, and the law is extraterritorial: it applies to you even if your company sits in Singapore, Australia or Berlin, as long as you process the data of people in Indonesia.
Most engineering teams treat "privacy" as a checkbox near launch. UU PDP is closer to GDPR than to a checkbox, and a lot of what it requires lands directly on the codebase. Here's the developer-level version — what it actually means for what you build.
(Not legal advice — talk to an Indonesian lawyer for your specific case. This is the engineering-side map.)
The five things that hit your code
1. A lawful basis and real consent (Art. 26). You need a lawful basis for every processing activity, and for most consumer products that means consent — real consent, not a pre-ticked box. Practically: granular opt-ins (don't bundle "marketing" with "create account"), a record of what was consented to and when, and a way to withdraw it that actually stops the processing. If you can't show the consent log, you can't prove compliance.
2. Transparent privacy notices. Users must be told what you collect and why, in plain language, before you collect it. That's a product surface, not a PDF nobody reads — wire it into signup and data-collection points.
3. Nine data-subject rights → you need endpoints for them. UU PDP grants users rights including access, correction, deletion, and portability of their data. In engineering terms: you need to be able to export a user's data and delete it on request, reliably, across every service and backup that holds it. If "delete my account" leaves data scattered in logs, analytics and a warehouse, that's a problem. Design for export/delete from day one — retrofitting it is painful.
4. Breach notification within 3×24 hours. If you have a qualifying breach, Art. 46 requires written notice to the affected users and the authority within three days, including what was breached, when and how, and your remediation. You cannot meet a 3-day clock if you have no idea what happened — so this is really a requirement for logging, monitoring and an incident process that exist before the breach.
5. Data minimization. The cheapest way to comply is to not hold data you don't need. Every extra field is extra liability — especially anything payment-adjacent or sensitive. "We might use it later" is how you end up over-exposed.
The ones that hit your architecture and org
- Cross-border transfer. If you host or process Indonesian data outside Indonesia, you need appropriate safeguards. Know where your data physically lives and where it flows.
- DPO and DPIA. Large-scale or sensitive processing can require appointing a Data Protection Officer and running a Data Protection Impact Assessment for high-risk features. Build the DPIA habit into how you scope risky features.
- Per-tenant isolation. For multi-tenant products, isolating each customer's data cleanly isn't just good architecture — it makes access control, deletion and breach scoping dramatically easier to honor.
Why take it seriously
Administrative fines can reach up to 2% of annual revenue, and the law also carries criminal liability. The dedicated PDP Agency is being stood up (targeted for 2026); for now enforcement sits with Komdigi. The point isn't to panic — it's that "we'll add privacy later" is now an expensive default in this market.
A pragmatic build checklist
- Granular, logged, withdrawable consent — not a single bundled checkbox
- A privacy notice wired into collection points, in plain language
- A working export-user-data path and a working delete-user-data path across all stores
- Logging and monitoring good enough to detect and describe a breach within 3 days
- Collect the minimum; drop fields you don't actually use
- Know where data is hosted and how it crosses borders
- DPIA for high-risk features; DPO if your scale/sensitivity triggers it
Common mistakes I see
- "Delete account" that only flips an
is_activeflag and leaves the data everywhere - Consent stored as a single boolean with no record of scope or timestamp
- No way to assemble everything you hold about one user (so you can't honor access/portability)
- Treating compliance as a launch-week task instead of an architecture decision
If you'd rather not own all of this in-house, studios that build UU-PDP-aware products for the Indonesian market — for example H-Studio — can bake it into the architecture from the start. But the checklist above is the same whoever builds it.
FAQ
Does UU PDP apply if my company isn't in Indonesia?
Yes — it's extraterritorial. If you process data of people in Indonesia, it applies regardless of where you're based.
How fast do I have to report a breach?
Within 3×24 hours (three days) to the affected users and the authority, with details of what happened and your response.
Do I need a DPO?
Not always — but large-scale or sensitive-data processing can require one. Check your thresholds.
What's the penalty for ignoring it?
Administrative fines up to 2% of annual revenue, plus possible criminal liability — on top of the reputational hit.
Takeaway
UU PDP turns three things into engineering requirements: real consent you can prove, the ability to export and delete a user's data on demand, and enough observability to report a breach in three days. Build those in early, collect less data, and know where it lives. It's far cheaper as an architecture decision than as a launch-week scramble — or a 2%-of-revenue fine.
How are you handling UU PDP in your stack? Comparing notes in the comments.
Sources: DLA Piper – Indonesia data protection · ASEAN Briefing – Indonesia PDP Law guide
