Law No. 27 of 2022 on Personal Data Protection, usually called UU PDP, was enacted on 17 October 2022 with a two-year transition that ended on 17 October 2024. Most companies we talk to know the law exists but not what it asks of the software: the database holding customer phone numbers, the log files full of NIK numbers, the staging server with a copy of production. Policies can be written in a month, but changing how an application collects, stores, and deletes data takes longer, so start there. This article covers the engineering side and is not legal advice. Involve a lawyer for interpretation of your own case.
What the Law Covers, in Plain Terms
UU PDP applies to anyone processing personal data of people in Indonesia, including organisations abroad whose processing has legal effects here. Personal data is anything about a person who can be identified, directly or when combined with other data. A phone number counts on its own.
The law splits personal data into two groups. General personal data includes name, gender, nationality, religion, marital status, and data that identifies a person when combined. Specific personal data carries more risk, and the law expects more care with it. It covers:
- Health data, such as clinic records or medical check-up results.
- Biometric data, such as face templates in an attendance app.
- Genetic data.
- Criminal records, including stored SKCK scans.
- Children's data, which needs consent from a parent or guardian.
- Personal financial data, such as account numbers and salary.
A payroll module holds financial data and a school app holds children's data, often without anyone having noticed. If yours does, everything below weighs heavier.
Controllers, Processors, and Where Your Vendors Fit
The controller (pengendali data pribadi) decides why and how data is processed, which usually means your company. The processor (prosesor data pribadi) processes it on the controller's behalf. That includes your cloud provider, your email, SMS, and WhatsApp vendors, and your software house if it hosts the app or can see production data while fixing bugs.
The controller stays responsible for what its processors do, so each one needs a written agreement covering what data they handle and why, the security they apply, a ban on any other use, how fast they report incidents, and what happens to the data when the contract ends. Many contracts between Indonesian companies and their developers say nothing about personal data. Fix that at the next renewal.
Transfers outside Indonesia are allowed under conditions, such as equal or higher protection at the destination or adequate safeguards in the contract. If your servers run in a Singapore region or you call an overseas AI API, write it down and ask your lawyer which basis applies.
Lawful Basis and Consent You Can Prove
Every processing activity needs a lawful basis. Consent is only one. Others include performing a contract with the person, a legal obligation, and legitimate interest. An online shop needs no consent to use an address for delivery, because that is the contract. Promotional WhatsApp blasts are different, and consent is the usual basis there.
When you rely on consent, the burden of proof is yours, and a pre-ticked box will not carry it. Keep a consent record per user and per purpose: what they agreed to, which version of the notice they saw, when, and through which channel. Record withdrawal the same way, and stop processing for that purpose.
Collecting less is the cheapest control you have, and this is where many projects go wrong. A registration form asks for NIK, date of birth, mother's maiden name, and a KTP photo because someone thought it might be useful later. Every field has to be protected and eventually deleted. If nobody can say what it is for, remove it.
What the Law Asks of the Application
The table maps the main obligations to concrete work. Treat it as the start of a backlog, not a full compliance checklist.
| Requirement | What it means in the app | Example implementation |
|---|---|---|
| Record of processing | Know what personal data you hold, where, why, and who can see it | Data inventory per table and column with purpose, lawful basis, access, and retention period |
| Lawful basis and consent | Prove what each user agreed to and when | A consents table with user ID, purpose, notice version, timestamp, channel, and withdrawn_at |
| Retention and deletion | Delete or anonymise data once the purpose ends | Scheduled job that anonymises accounts inactive for the agreed period and logs each run |
| Security of processing | Prevent unauthorised access, change, and disclosure | TLS everywhere, encrypted disks and backups, field-level encryption for NIK and financial data |
| Accountability | Show who viewed, exported, or changed personal data | Read-only audit log of admin views, exports, and edits, stored apart from the main database |
| Data subject rights | Answer access, correction, and deletion requests | Admin tool that exports one person's data and deletes or anonymises it across tables |
| Breach notification | Notify data subjects and the authority within 3 x 24 hours | Alerting, a written runbook, and named people who decide and send notices |
Logs, Backups, and the Staging Database
The leaks we have cleaned up after rarely came through the production database. They came through application logs printing full request bodies with NIK and phone numbers, Excel exports sent to personal Gmail accounts, and staging servers holding a full copy of production behind a default password.
Mask in the logs: NIK becomes 3273********0001, a phone number 0812****5678. Do it once in the logging layer rather than trusting every developer to remember. Staging and development databases get a masking script that swaps names, NIK, phone numbers, and addresses for fake values before the copy leaves production. With the Faker libraries for PHP, Python, or JavaScript this is a day or two of work.
Encrypt in transit with TLS, including between app and database on separate servers, and at rest with disk encryption and encrypted backups. For NIK, bank account numbers, and health notes, add application-level encryption so a stolen dump is not readable on its own. Deleted data only leaves the backups when they expire, so set backup retention to match your policy.
Handling Requests From Data Subjects
The rights that create real work for the application are these:
- Access: confirmation that you process their data, and a copy of it.
- Correction: fixing data that is wrong or incomplete.
- Deletion: having their data deleted or destroyed, subject to retention duties in other laws.
- Withdrawing consent: stopping processing that relied on it.
- Objecting to automated decisions: decisions based solely on automated processing, including profiling, that significantly affect them.
Some of these come with short response deadlines, so confirm them with your lawyer and design for days, not weeks. Build an admin function that finds one person's records across users, orders, support tickets, chat history, and file storage, then exports or anonymises them. Transaction records often have to be kept for accounting, so for invoices you anonymise the person and keep the transaction. Verify identity before acting, or the deletion feature becomes a new way to hurt users.
When Something Leaks: The 3 x 24 Hour Clock
If personal data protection fails, the controller must notify the affected people and the supervisory authority in writing within 3 x 24 hours. The notice covers what data was exposed, when and how it happened, and what you are doing to contain it and recover. Seventy-two hours is very little time when nobody knows who is in charge.
Write the runbook before you need it: who is called first, who decides whether the incident is reportable, who brings in the lawyer, who drafts the message to users, and how logs are preserved. Rehearse once a year with an invented scenario, such as a staging database found on a public IP. The first run usually shows that audit logs only go back seven days, or that nobody has the cloud root password.
If you cannot say where a customer's phone number is stored, you cannot delete it when they ask, and you cannot tell them when it leaks.
DPO, Sanctions, and the Implementing Rules
You must appoint a personal data protection officer (pejabat or petugas pelindungan data pribadi) when processing serves public services, involves regular and systematic monitoring at large scale, or involves large-scale processing of specific data or criminal records. A lending platform or a hospital system qualifies. A distributor with a sales app probably does not, but someone should still own the topic.
Administrative sanctions range from written warnings and temporary suspension of processing to deletion of data and fines of up to 2 percent of annual revenue. Separately, the law has criminal provisions for unlawfully collecting, disclosing, or using personal data that does not belong to you, with prison terms and fines that run into billions of rupiah.
The law calls for a supervisory agency formed by the President and an implementing government regulation (PP). Both have been slow in coming, so check the latest status of the agency and the implementing rules before you finalise policies and breach procedures. Our honest view is that waiting for them is a poor reason to delay the engineering, since everything here follows from the law itself.
Where to Start
Scale the effort to the data. If your website is a company profile with a contact form, you do not need a compliance project or a software house for this. Turn on HTTPS, publish a short privacy notice, limit who reads the form submissions, and delete old ones yearly. For an app holding customer accounts, transactions, or specific data, work through these steps:
- 1Build the data inventory: every system holding personal data, spreadsheets and backups included, with purpose, lawful basis, access, and retention for each table or file.
- 2Cut what you do not need. Remove unused fields, stop storing KTP photos where the NIK number alone is enough, and purge old data nobody uses.
- 3Close the obvious leaks: mask NIK and phone numbers in logs and non-production databases, take staging off the public internet, and retire shared admin accounts.
- 4Add consent records with timestamps and versioned privacy notices, plus a way for users to withdraw.
- 5Put role-based access and an audit log on admin screens and exports, and encrypt sensitive columns and backups.
- 6Build the retention jobs and the admin tool for access, correction, and deletion requests.
- 7Sign data processing agreements with your cloud provider, your software house, and your messaging vendors.
- 8Write the breach runbook, assign the people, and rehearse it once a year.
On new systems we put the data inventory and log masking into the first sprint, when they are cheap. For existing applications we usually start with a two to three week review of the code, logs, and infrastructure, and turn the findings into a backlog that your team or ours can work through.
Key takeaways
- UU PDP (Law No. 27 of 2022) has applied in full since 17 October 2024, and it reaches into how your software stores and deletes data.
- Specific personal data such as health, biometric, children's, and financial data raises the bar.
- Keep provable consent records with timestamps and notice versions, and collect fewer fields in the first place.
- Logs, exports, and staging copies leak more often than production: mask NIK and phone numbers everywhere outside production.
- Have processor agreements with every vendor and a tested breach runbook that can meet the 3 x 24 hour deadline.
