Key Takeaway
Indonesia's UU PDP No. 27/2022 is the country's first comprehensive personal data protection law, modelled partly on GDPR and fully enforceable from October 2024. It binds any organisation processing Indonesian personal data, which makes consent records, retention limits and breach notification engineering requirements rather than legal paperwork.
Indonesia's Undang-Undang Perlindungan Data Pribadi (UU PDP) No. 27/2022 is the country's first comprehensive personal data protection law, modeled partly on the EU's GDPR. Fully enforceable from October 2024, it imposes binding obligations on any organization — public or private, domestic or foreign — that processes personal data of Indonesian citizens. For developers, this means existing systems must be retroactively assessed and updated to meet UU PDP's five core obligations: lawful basis for processing, informed consent management, data minimization, retention limits, and 72-hour breach notification.
UU PDP's Five Core Developer Obligations
Unlike Indonesia's previous sector-specific data regulations (OJK, BI, BPJS), UU PDP applies horizontally to all industries. The five obligations that most directly affect software engineers are: (1) establishing a lawful basis before collecting any personal data; (2) implementing granular, revocable consent management; (3) collecting only data strictly necessary for the stated purpose (data minimization); (4) enforcing retention limits with automated deletion; and (5) detecting and notifying breaches within 72 hours to both the supervisory authority and affected data subjects.
Lawful Basis and Consent Management Implementation
UU PDP recognizes six lawful bases: explicit consent, contractual necessity, legal obligation, vital interests, public interest, and legitimate interests. Every data collection point in your application must be mapped to one of these bases and documented. For consent-based processing, implement a double-opt-in consent flow with granular purpose selection (e.g. separate consents for marketing emails, analytics tracking, and third-party data sharing). Store consent records with timestamp, version of privacy policy accepted, and the IP/device from which consent was given.
Data Minimization and Purpose Limitation in Practice
Data minimization requires that you collect only the fields genuinely needed for the stated purpose. Audit your registration forms, API request bodies, and analytics event schemas — any field without a documented business justification is a liability. Purpose limitation means data collected for user authentication cannot be repurposed for targeted advertising without a new consent. Implement database-level column comments tagging each column with its data classification and legal basis to make future audits faster.
Build a centralized Data Processing Register (Register Pemrosesan Data) as a machine-readable JSON or YAML manifest in your repository. Each entry documents the data category, legal basis, retention period, third-party processors, and whether cross-border transfer occurs. UU PDP Article 31 obliges the controller to record all of its personal data processing activities, and a register like this is the practical way to meet it while significantly speeding up regulatory audit responses.
Technical Safeguards: Encryption, RLS, and Pseudonymization
UU PDP Article 35 requires Pengendali Data (Data Controllers) to implement appropriate technical safeguards proportionate to the risk level of the data being processed. For most applications processing NIK (national ID), financial account numbers, health data, or biometrics, this means encryption at rest (AES-256), encryption in transit (TLS 1.3), pseudonymization or tokenization for analytics pipelines, and access control enforced at the database level using Row-Level Security.
PostgreSQL RLS for Data Isolation and Python Pseudonymization
Row-Level Security (RLS) in PostgreSQL enforces data access policies at the storage engine level, ensuring that application bugs or misconfigured queries cannot accidentally expose another user's personal data. Combined with pseudonymization — replacing PII fields with HMAC-SHA256 tokens derived from a secret key — your analytics and reporting pipelines can operate on data without ever touching raw personal information. The code block below shows both techniques in a unified implementation.
-- PostgreSQL Row-Level Security for UU PDP data isolation
-- Each tenant/user can only access their own personal data
ALTER TABLE user_personal_data ENABLE ROW LEVEL SECURITY;
-- Policy: users can only read their own rows
CREATE POLICY user_data_isolation ON user_personal_data
FOR ALL
TO app_user
USING (owner_id = current_setting('app.current_user_id')::uuid);
-- Pseudonymization function (Python) — store real data separately
-- ---------------------------------------------------------------
# pseudonymize.py
import hashlib
import hmac
import os
PSEUDONYM_SECRET = os.environ['PSEUDONYM_SECRET'].encode()
def pseudonymize(value: str) -> str:
"""
One-way HMAC-SHA256 pseudonym — consistent per value,
cannot be reversed without the secret key.
Compliant with UU PDP data minimization principle.
"""
return hmac.new(PSEUDONYM_SECRET,
value.encode('utf-8'),
hashlib.sha256).hexdigest()
def pseudonymize_record(record: dict, pii_fields: list[str]) -> dict:
"""Replace PII fields with pseudonyms before storing in analytics DB."""
result = dict(record)
for field in pii_fields:
if field in result and result[field]:
result[field] = pseudonymize(str(result[field]))
return result
# Example usage
raw = {'user_id': 'USR-001', 'nik': '3271012345670001',
'email': 'user@example.com', 'amount': 50000}
safe = pseudonymize_record(raw, pii_fields=['nik', 'email'])
# safe = {'user_id': 'USR-001', 'nik': '<hash>', 'email': '<hash>', 'amount': 50000}
-- Audit log table for data access tracking (UU PDP Article 31)
CREATE TABLE personal_data_access_log (
id BIGSERIAL PRIMARY KEY,
accessed_by UUID NOT NULL,
table_name TEXT NOT NULL,
record_id UUID NOT NULL,
operation TEXT CHECK (operation IN ('SELECT','UPDATE','DELETE')),
accessed_at TIMESTAMPTZ DEFAULT NOW(),
purpose TEXT NOT NULL,
legal_basis TEXT NOT NULL -- consent / contract / legal_obligation / vital_interest
);Audit Logging for Data Access Events
UU PDP requires that personal data access events be traceable and auditable. Every SELECT, UPDATE, or DELETE on tables containing personal data must be logged with: the identity of the accessor, the legal basis claimed, the timestamp, and the business purpose. Use PostgreSQL triggers or application-level middleware to capture these events, and store logs in a write-once, append-only audit table or a WORM (Write Once Read Many) compliant object storage bucket.
Data Subject Rights and the Request Handling API
UU PDP grants Indonesian data subjects six core rights: access (view all data held about them), rectification (correct inaccurate data), erasure (right to be forgotten), portability (receive data in machine-readable format), restriction of processing, and objection to automated decision-making. Developers must build API endpoints or UI workflows to fulfill these requests, and the deadlines are measured in hours: correcting data (Article 30), giving access to the data and its processing trail (Article 32), stopping processing after consent is withdrawn (Article 40), and delaying or restricting processing (Article 41) must each be done within 3 x 24 hours of receiving the request. Designing these workflows early is far cheaper than retrofitting them into a mature codebase.
Implementing the Right to Erasure (Hak Penghapusan)
Erasure requests are technically complex because personal data is often scattered across multiple systems: primary databases, analytics warehouses, backups, email logs, and third-party processors. Build a Data Subject Request (DSR) orchestration service that: (1) identifies all data stores holding the subject's data using their user ID; (2) issues deletion commands to each system with a deadline; (3) notifies third-party sub-processors to delete; and (4) confirms completion to the data subject. Backups are exempt from immediate deletion but must not be restored for that individual's data.
UU PDP Article 56 sets a tiered test for transferring personal data outside Indonesia. First, you must ensure the recipient's country offers protection equal to or higher than UU PDP. Failing that, adequate and binding safeguards must be in place. Failing both, you need the data subject's consent. The law names no qualifying countries, and no official list of them had been published as of October 2026, so the assessment is yours to make and document; skipping a step is subject to administrative sanctions under Article 57. This affects common practices like sending logs to Datadog US, user data to Salesforce, or analytics to Google Analytics — each needs a documented transfer assessment showing which of the three grounds it relies on.
Penalties and Enforcement Landscape
UU PDP penalties are structured across three tiers: administrative sanctions under Article 57 (a written warning, temporary suspension of processing, deletion or destruction of the personal data, and administrative fines capped at 2% of annual revenue or receipts, with no fixed rupiah amount); criminal penalties under Articles 67 and 68 (up to 5 years and Rp 5 billion for unlawfully obtaining, collecting or using someone else's personal data, up to 4 years and Rp 4 billion for unlawfully disclosing it, and up to 6 years and Rp 6 billion for creating false personal data or falsifying it); and corporate liability under Article 70, where a company can only be fined, but up to ten times the maximum fine, on top of additional penalties such as forfeiture of profits, suspension of the business or revocation of its permits.
Breach Detection and 72-Hour Notification Requirements
UU PDP Article 46 requires a written notice within 3 x 24 hours whenever personal data protection fails, which the law's elucidation defines as any loss of confidentiality, integrity or availability, accidental or deliberate. The notice goes to both the affected data subjects and the supervisory agency (the lembaga that Article 58 leaves the President to establish). There is no high-risk threshold, and the article does not say when the clock starts, so plan from the moment of discovery. The notice must at least state which personal data was exposed, when and how, and what you are doing to handle and recover from it; in certain cases you must also inform the public. Build automated breach detection into your SIEM pipeline — anomaly detection on data egress volume, failed authentication spikes, and unusual after-hours database access patterns are strong breach signals. Prepare a breach notification runbook with pre-approved templates and designated incident commanders before an incident occurs.
Vendor and Sub-Processor Management
Every third-party service that processes your users' personal data on your behalf (cloud providers, email service providers, analytics platforms, customer support tools) is a sub-processor under UU PDP. Maintain a sub-processor register with Data Processing Agreements (DPAs) or equivalent contractual safeguards for each vendor. When a vendor is removed from your stack, formally terminate the DPA and confirm data deletion — this is part of your data lifecycle management obligation.
Implement automated PII detection in your CI/CD pipeline using tools like Presidio (Microsoft) or AWS Macie to scan code commits and database migrations for accidental PII inclusion in logs, analytics events, or error messages. Finding a `console.log(user.nik)` in production logs is both a UU PDP violation and a reputational risk.
Building a Privacy-by-Design Engineering Culture
UU PDP compliance is not a one-time project — it requires embedding privacy considerations into every product decision. Privacy Impact Assessments (PIAs) should be mandatory for any new feature that collects or processes personal data. Threat modeling sessions should explicitly include data privacy risks alongside security risks. Engineers should be empowered to raise privacy concerns during code review without requiring legal approval for every decision.
Building a UU PDP Compliance Roadmap
A practical UU PDP compliance roadmap for engineering teams spans three phases: Discovery (data inventory audit, risk assessment, gap analysis against UU PDP requirements), Implementation (technical safeguards: encryption, RLS, pseudonymization, consent management, DSR APIs), and Operationalization (ongoing: breach response procedures, staff training, third-party audits, Data Protection Officer designation if processing sensitive data at scale). Most mid-sized companies need 6–12 months to complete all three phases.
Key terms in this article include UU PDP, Pengendali Data, Pseudonymization, and RLS.