Indonesia's PDP Law: A Technical Checklist for Web Apps

Why the PDP Law Is an Engineering Problem, Not Just a Legal One

Law No. 27 of 2022 on Personal Data Protection (UU PDP) gave organisations two years to adjust after it was enacted on 17 October 2022, so its obligations now apply. Its implementing regulation, Government Regulation No. 33 of 2026, was signed on 16 July 2026 and takes effect on 16 January 2027, according to Hukumonline's analysis.

Many businesses respond by updating the privacy policy and stopping there. The catch is that most PDP obligations can only be met by your systems: recording consent, deleting data on time, sending a breach notice within hours. A privacy policy promising things your app can't do becomes evidence of non-compliance. This post turns the articles that touch web apps most often into a technical checklist.

Note: this is technical guidance, not legal advice. For lawful bases, data protection officer duties, and sector-specific rules, talk to a lawyer.

1. Consent and Transparency

The law lists several lawful bases for processing (Article 20), one of which is explicit, valid consent for specific purposes. If you rely on consent, Article 21 requires you to tell users, among other things, the purpose, the types of data, the retention period, and their rights.

What to build:

One consent checkbox per purpose, unticked by default. "Process my order" and "send me promotions" are separate consents.
A consents table recording who, which purpose, which policy version, when, and from where (web, app, WhatsApp). Without it you can't prove consent was ever given.
A withdraw button as easy to use as the opt-in. Article 40 requires processing to stop within 3 × 24 hours of withdrawal.

Fix: store privacy policy versions as data, not just a web page. When the text changes, you know exactly who agreed to the old version.

2. Data Minimisation and Retention

Article 27 requires processing to be limited and specific to its purpose; the official explanation adds that collection must match the purpose set at the time of collection. That matches an old engineering rule: OWASP says the best way to protect sensitive information is not to store it at all.

What we often find in audits: sign-up forms asking for national ID number, birth date, and full address for a service that only needs an email; and server logs quietly keeping phone numbers and form contents for years.

For every form field, write down the business reason. No reason, no field.
Set a retention period per data type, then run a scheduled job that deletes or anonymises data past it.
Scrub personal data from application logs, error messages, and analytics tools.

Fix: a retention period that only lives in a document means nothing. What counts is a job that actually runs and leaves a record.

3. Technical Security

Article 35 requires controllers to design and apply operational technical measures to protect data, at a security level that fits the nature and risk of the data. Article 39 requires preventing unauthorised access. The law names no specific technology, so the yardstick is reasonable practice for your data's risk.

Our minimum checklist:

HTTPS everywhere, admin panel and internal APIs included.
Encryption at rest for databases and backups, plus column-level encryption for specific data such as personal financial or health data.
Passwords hashed with a password-hashing algorithm, never encrypted.
Role-based access: support staff don't need every customer column.
Secrets (API keys, database credentials) in a secret manager or environment variables, never in the repository.
Encrypted backups with tested restores.

Much of this already sits in our production deployment checklist; the PDP Law turns good practice into an obligation.

4. User Rights: Access, Correction, Deletion

The law sets very concrete deadlines for some user requests. Controllers must correct data within 3 × 24 hours of a request (Article 30), give access within the same window (Article 32), and delete data in certain cases, such as when the user asks (Article 43).

Three days is not enough if the process is "email the admin, admin asks a developer, developer runs a manual query".

A profile page where users see and fix their own data.
A data export in a readable format such as JSON or CSV.
An account deletion flow that reaches every place the data lives: main database, email marketing tool, CRM, file storage. Keep a record that the deletion happened.
A request queue with timestamps so the 3 × 24-hour deadline can be tracked.

Fix: build a data map first. You can't delete data from a system you don't know holds it. Our 5 API integration mistakes post is relevant here, since every integration is another copy of the data.

5. Records, Third Parties, and Data Transfers

Article 31 requires recording all personal data processing, and Article 37 requires supervising every party that processes data under your control. For a web app, that includes your cloud provider, email service, payment gateway, analytics, and AI providers.

List every vendor that receives personal data, what they receive, and where their servers are.
Make sure vendor contracts cover personal data processing, not just the service.
For data sent outside Indonesia, Article 56 requires the receiving country to offer equal or higher protection, or adequate and binding safeguards. Work out the mechanism with a lawyer.
Keep an audit log of who accessed or changed personal data, and when.

If you use the WhatsApp Business API or AI services, they belong on this list too.

6. Breach Notification

Article 46 is the one that catches teams off guard: if personal data protection fails, the controller must notify the data subjects and the authority in writing within 3 × 24 hours. The notice must at least cover what data was exposed, when and how, and the steps taken to handle and recover. In some cases the public must be told as well.

You can't answer "what, when, and how" in three days without logs.

Detection: alerts for suspicious admin logins, spikes in data exports, and repeated access errors.
Enough logging: access to personal data recorded with time and actor, stored separately from the app server.
An incident runbook: who decides, who investigates, who writes the notice, with a letter template ready.
Practice: run a simulation at least once, so the runbook isn't read for the first time during a real incident.

Fix: count back from the deadline. If investigation takes two days, you have one day left to draft and send the notice.

The Cost of Ignoring It

The law sets administrative sanctions: written warnings, temporary suspension of processing, deletion or destruction of data, and fines of up to 2% of annual revenue or receipts (Article 57). It also has criminal provisions for unlawfully obtaining, disclosing, or using personal data. Beyond sanctions, lost customer trust is often the bigger bill.

Quick Checklist

Consent per purpose, recorded with policy version, and withdrawable.
Every data field has a business reason and a retention period; automatic deletion runs.
No personal data leaking into logs or analytics.
HTTPS, encryption at rest, password hashing, role-based access.
Users can view, correct, export, and delete their data.
A data map and a list of vendors receiving personal data.
An audit log of personal data access.
An incident runbook and a 3 × 24-hour notice template, rehearsed.

If you're planning a new app, put these into your project spec from day one. Retrofitting them later always costs more.

The AY Labs Approach

We treat the PDP Law as a feature requirement, not a document attachment. On new projects we map which personal data is truly needed before designing the database, then build consent records, automatic retention, and user-rights flows into the app itself. For systems already running, we start with a technical audit: where personal data lives, who can reach it, and whether your logs could answer an Article 46 notice. We work alongside your legal counsel, because legal calls stay with them. If you want to know how ready your app is before Regulation 33/2026 takes effect, we're happy to take a look.