UU PDP No. 27/2022: The Developer's Compliance Guide for Indonesia's Data Protection Law

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.

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 28)
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 within 14 working days. 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.

Penalties and Enforcement Landscape

UU PDP penalties are structured across three tiers: administrative sanctions (warnings, mandatory compliance remediation, temporary processing suspension, and fines up to 2% of annual revenue or Rp 20 billion, whichever is higher); criminal penalties for intentional unlawful data processing (up to 6 years imprisonment for natural persons); and aggravated penalties for processing special categories of data (biometrics, health data, financial data, children's data) without proper safeguards.

Breach Detection and 72-Hour Notification Requirements

UU PDP Article 46 requires notifying both the supervisory authority (KOMDIGI) and affected data subjects within 72 hours of discovering a breach that poses a high risk to individuals. 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.

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.

Related Articles

• DevSecOps: Building a Secure CI/CD Pipeline
• Clean Code Principles for Maintainable Software