UU PDP (Indonesia Data Protection) Compliance

Law No. 27 of 2022 — Undang-Undang Pelindungan Data Pribadi (UU PDP) — is Indonesia's comprehensive personal data protection law. Spanning 76 articles across 16 chapters, UU PDP establishes data-subject rights, controller obligations, breach-notification requirements, and cross-border transfer rules. The two-year transition period ended on 17 October 2024, meaning all provisions are now in force.

DPA status

UU PDP mandates a Data Protection Authority (DPA), but the DPA has not yet been constituted — the Presidential Regulation establishing it is pending. Until the DPA is stood up, the Ministry of Communication and Digital Affairs (MOCDA / Kominfo) holds the notification-recipient role for breach reporting and cross-border transfer notifications. This page reflects the current state; check official government channels for updates on DPA constitution.

caution

This page is engineering guidance for teams building governed AI on AxonFlow. It is not legal advice. Validate the regulatory mapping with your legal and compliance teams before relying on it for UU PDP compliance or supervisory interactions.

Key UU PDP provisions for AI systems

Article 46 — Breach notification (3 x 24 hours)

Article 46 paragraph (1) requires data controllers to notify both the data subject and the DPA (currently MOCDA) in writing within 3 x 24 hours (72 hours) of discovering a personal data breach. The notification must include:

• what personal data was breached
• when and how the breach was discovered
• remediation steps taken or planned

This is a strict timeline. For AI systems processing Indonesian personal data (NIK, NPWP, bank accounts, phone numbers), the breach window starts at discovery — not at confirmation. Engineering teams need audit trails granular enough to reconstruct what data was exposed and when.

Article 56 — Cross-border data transfer

Article 56 establishes a tiered framework for transferring Indonesian personal data across borders:

1. Adequacy: the destination country has data protection laws deemed equivalent by the DPA
2. Appropriate safeguards: binding contractual clauses or other safeguards approved by the DPA
3. Consent: explicit data-subject consent for the transfer

Both prior- and post-transfer notification to the DPA (currently MOCDA) is required. For AI systems that route data through foreign LLM providers or cloud infrastructure, every cross-border data movement should be logged with the transfer basis.

Cross-border transfer decision tree:

  Does the destination country have UU PDP adequacy?
    ├── Yes → Transfer permitted (log: basis = "adequacy")
    └── No → Are appropriate safeguards in place?
              ├── Yes → Transfer permitted (log: basis = "safeguards")
              └── No → Has the data subject given explicit consent?
                        ├── Yes → Transfer permitted (log: basis = "consent")
                        └── No → Transfer NOT permitted

Cross-border transfer attestation

Most regulated Indonesian deployments rely on Pasal 56(b) — a binding legal instrument (a Data Processing Agreement) with the foreign processor — rather than an adequacy determination or per-subject consent. AxonFlow carries the transfer basis on cross-border audit records through the transfer_basis field: when a cross-border transfer is tagged with a basis, the OJK audit export reports that value verbatim. For Pasal 56(b)-backed transfers there are two recognized, semantically equivalent values:

• pasal_56b_dpa — the explicit Pasal 56(b) tag, the preferred form for Indonesia-deployment auditor surfacing
• safeguards — the generic safeguards label, retained for backward compatibility

Both are recognized values and are surfaced verbatim in the OJK audit export — AxonFlow never auto-translates one into the other — so an auditor sees exactly the basis recorded at decision time. When a reviewer asks "where do I see the Pasal 56(b) attestation in the audit record?", the answer is the transfer_basis = "pasal_56b_dpa" value on each cross_border_transfers export record. To correlate that attestation with downstream warehouse activity in your SIEM, see the Decision Mode SIEM Correlation Recipe (Enterprise).

Automatic stamping (platform-managed). You no longer need a calling integration to tag each transfer at decision time. When the platform team declares a transfer basis in configuration (AXONFLOW_DEFAULT_TRANSFER_BASIS, with an optional per-org override and a per-request override taking precedence), the orchestrator auto-stamps transfer_basis, together with the derived data_residency destination country, onto the canonical decision record at the moment a request is forwarded to an LLM. The OJK cross_border_transfers export reads that same canonical record, so Pasal 56(b) attestation is turnkey: set the basis once and every cross-border forward carries it. A configured value is validated against the recognized Pasal 56 forms (adequacy, safeguards, pasal_56b_dpa, consent); an unrecognized value is rejected rather than written. With no basis configured the field is left unset and the row is not reported as a cross-border transfer (the safe default), so a deployment that asserts no cross-border basis surfaces nothing in the export.

Penalties

UU PDP penalties are substantial:

Violation type	Administrative penalty	Criminal penalty
Failure to maintain reasonable security safeguards	Up to 2% of annual revenue	—
Failure to notify breach within 3 x 24 hours	Up to 2% of annual revenue	—
Unlawful personal data processing	—	Up to 5 years imprisonment + IDR 5 billion (individual) / IDR 50 billion (corporate)
Falsifying personal data for personal gain	—	Up to 6 years imprisonment + IDR 6 billion (individual) / IDR 60 billion (corporate)

A concrete example: lending platform processing NIK and NPWP

A P2P lending platform (LPBBTI) processes loan applications that contain NIK (national identity number), NPWP (tax identification number), bank account details, and Indonesian phone numbers. The platform uses an AI credit-scoring model and a customer-service copilot.

What UU PDP asks the platform to demonstrate:

• Article 4 (personal data categories): NIK and NPWP are personal data; the platform must identify and protect them in every processing pipeline.
• Article 46 (breach notification): if the AI system leaks or exposes NIK/NPWP data, the platform has 3 x 24 hours (72 hours) to notify MOCDA and affected data subjects.
• Article 56 (cross-border transfer): if the credit-scoring model is hosted by a foreign cloud provider, every data transfer must be logged with the legal basis (adequacy, safeguards, or consent).

How it maps to AxonFlow tiers:

Enterprise endpoints for Indonesian compliance are served through a shared OJK compliance module at /api/v1/ojk/*, covering OJK, BI, and UU PDP frameworks through a single API surface with framework-specific parameters.

Need	Community	Evaluation	Enterprise
NIK detection (16-digit, province-code prefixed)	System policies (sys_pii_indonesia_nik) — pattern-based, ~0.7 confidence	Same	Same + province-code validation (~0.95 confidence)
NPWP detection (legacy 15-digit + new 16-digit)	System policies (sys_pii_indonesia_npwp_legacy, sys_pii_indonesia_npwp_new)	Same	Same + check-digit validation
Indonesian mobile (+62) detection	System policies (sys_pii_indonesia_phone)	Same	Same
Bank-account detection (BCA, Mandiri, BRI, BNI)	System policies — context-anchored patterns	Same	Same + enhanced validation
Policy enforcement on every LLM + MCP call	Yes	Yes	Yes
Full audit trail for breach reconstruction (Art. 46)	Yes (3-day retention)	Same (14-day)	Same + 10-year retention
HITL on decisions involving personal data	Can emit; no queue	HITL approval queue	Production HITL queue + portal
Breach notification template (Art. 46 fields)	Not provided	Not provided	POST /api/v1/ojk/breach/notify — generates Art. 46 compliant notification with 72h deadline
Cross-border transfer logging (Art. 56)	Not provided	Not provided	data_residency + transfer_basis fields in audit logs
Retention posture proof	Not provided	Not provided	GET /api/v1/ojk/audit/retention — per-data-type retention status
OJK readiness dashboard (UU PDP framework)	Not provided	Not provided	GET /api/v1/ojk/audit/readiness with framework: "UU_PDP"

What Community covers

Community is a credible starting point for UU PDP-relevant engineering work:

• audit logging with enough granularity to reconstruct what personal data was processed, when, and by which AI component — critical for Article 46 breach investigations
• system and tenant policy enforcement on every LLM and MCP call, providing the "reasonable security safeguards" Article 46 references
• Indonesia-relevant PII protection: NIK (16-digit, province-code prefixed), NPWP (both 15-digit legacy and 16-digit post-2024 formats), Indonesian mobile (+62), and bank-account patterns for the four major banks — 8 detection patterns total

Community PII detection is pattern-based with approximately 0.7 confidence. The patterns validate structural format (digit count, prefix ranges, context anchors for bank accounts and NPWP) but do not perform province-code lookups or check-digit validation. This is a meaningful detection layer — but it is not a substitute for application-level data classification in high-sensitivity pipelines.

UU PDP breach notification workflow

For Enterprise users, the breach notification workflow is:

1. Discover — audit trail surfaces the anomaly or data exposure
2. Assess — use OJK readiness check to evaluate the scope of affected data
3. Generate — POST /api/v1/ojk/breach/notify generates the Art. 46 notification template with all required fields and the 72-hour deadline calculated from discovery timestamp
4. Review — HITL approval gate for compliance and legal review before external notification
5. Send — notification delivered to MOCDA (until DPA is constituted) and affected data subjects
6. Evidence — POST /api/v1/ojk/audit/export captures the complete breach-response trail

Industry playbook

P2P lending platforms (LPBBTI)

The concrete flow above. Every loan application contains NIK + NPWP. AxonFlow's PII detection catches these before they reach the credit-scoring model unredacted; the audit trail captures the governance chain from application intake through scoring and disbursement.

E-commerce and marketplace platforms

Platforms processing customer orders, payment details, and delivery addresses handle NIK (for age-verified purchases) and Indonesian phone numbers at scale. UU PDP's breach-notification timeline means the platform needs granular audit logs to reconstruct exposure scope within hours, not days.

Healthtech and insurtech

Applications processing KTP-derived data (NIK), medical records, and insurance claims face stricter UU PDP requirements because health data is classified as specific personal data under Article 4 paragraph (2). AxonFlow's PII detection and audit trail provide the foundational governance layer.

Cross-border SaaS providers

Foreign SaaS providers serving Indonesian customers must comply with Article 56 cross-border transfer rules. AxonFlow's data_residency and transfer_basis audit-log fields (Enterprise) provide the transfer-logging foundation; the cross-border decision tree above is the compliance logic the engineering team implements.

For the cross-framework view of regulated API families, use the Enterprise Compliance API Surface.

Enterprise Operating Workflow

The licensed workflow surface below is included here so engineers can evaluate both the community baseline and the production operating model from one page.

AxonFlow Enterprise supports UU PDP (Law No. 27 of 2022) compliance workflows through the OJK module, with specific focus on breach notification (Art. 46) and cross-border transfer logging (Art. 56). These workflows are especially relevant for AI systems processing Indonesian personal data — NIK, NPWP, bank accounts, phone numbers — where the breach-notification timeline and cross-border transfer rules create concrete engineering requirements.

Requires Enterprise license.

DPA status

The UU PDP Data Protection Authority (DPA) has not yet been constituted. Until the DPA is stood up, the Ministry of Communication and Digital Affairs (MOCDA / Kominfo) holds the notification-recipient role. The breach-notification endpoint reflects this: recipient is set to "MOCDA" by default. This will be updated when the DPA is constituted.

caution

This guide is engineering guidance for teams operating governed AI on AxonFlow. It is not legal advice. Validate the regulatory mapping with your legal and compliance teams before relying on it for UU PDP compliance.

What the module covers for UU PDP

The OJK module serves UU PDP compliance through the UU_PDP framework selection:

Route	Method	UU PDP usage
/api/v1/ojk/breach/notify	POST	Generate Art. 46 breach notification with 72h deadline
/api/v1/ojk/audit/export	POST	Export breach-response evidence with framework: "UU_PDP"
/api/v1/ojk/audit/export/{id}	GET	Track breach-evidence export status
/api/v1/ojk/audit/retention	GET	Verify retention for breach-investigation window
/api/v1/ojk/audit/readiness	GET	Readiness check for UU PDP posture
/api/v1/ojk/dashboard	GET	Combined view including breach-notification status

Breach notification workflow (Art. 46)

Article 46 paragraph (1) requires written notification to the data subject and the DPA (currently MOCDA) within 3 x 24 hours of discovering a personal data breach. The workflow in AxonFlow Enterprise:

Step 1: Discover the incident

The audit trail surfaces the anomaly. Common detection paths:

• PII detection logs show unredacted NIK/NPWP in an unexpected output
• Policy-violation logs show a bypass or misconfiguration
• External report triggers an investigation scoped by audit-trail timestamps

Step 2: Scope the impact

Use the audit export with tight date windows to reconstruct what data was exposed:

curl -X POST http://localhost:8080/api/v1/ojk/audit/export \
  -H "Content-Type: application/json" \
  -d '{
    "start_date": "2026-03-15T00:00:00Z",
    "end_date": "2026-03-15T23:59:59Z",
    "data_types": ["pii_redactions", "policy_violations", "llm_calls"],
    "format": "json",
    "framework": "UU_PDP",
    "filters": {
      "severity": "high"
    }
  }'

Step 3: Generate the breach notification

curl -X POST http://localhost:8080/api/v1/ojk/breach/notify \
  -H "Content-Type: application/json" \
  -H "X-User-ID: compliance-lead-1" \
  -d '{
    "data_types_involved": ["nik", "npwp"],
    "discovery_timestamp": "2026-03-15T14:30:00Z",
    "estimated_subjects_affected": 450,
    "remediation_steps": [
      "Disabled the affected AI agent pending investigation",
      "Rotated API credentials for the compromised connector",
      "Added emergency PII-block policy for NIK and NPWP patterns"
    ]
  }'

The response includes:

• notification_id — unique tracking identifier
• notification_deadline — "2026-03-18T14:30:00Z" (72 hours from discovery)
• recipient — "MOCDA" (current notification recipient)
• status — "draft" (pending review before delivery)
• data_types_involved — echoed back for confirmation
• estimated_subjects_affected — echoed back
• remediation_steps — echoed back

Step 4: Review and approve

Route the draft notification through an HITL approval gate so legal and compliance teams review before external delivery. The notification_id links the approval decision to the breach record in the audit trail.

Step 5: Deliver and track

After approval, the notification is marked as sent. Track status through the dashboard or by querying the export with the notification_id.

Step 6: Preserve evidence

Generate a comprehensive export covering the full breach-response timeline:

curl -X POST http://localhost:8080/api/v1/ojk/audit/export \
  -H "Content-Type: application/json" \
  -d '{
    "start_date": "2026-03-15T00:00:00Z",
    "end_date": "2026-03-19T00:00:00Z",
    "data_types": ["all"],
    "format": "json",
    "framework": "UU_PDP"
  }'

Cross-border transfer logging (Art. 56)

For AI systems that route Indonesian personal data through foreign LLM providers or cloud infrastructure, cross-border data movements are described by two fields on the audit entry:

• data_residency — ISO 3166-1 alpha-2 country code of the destination (e.g., "US", "SG", "IN")
• transfer_basis — the legal basis under Pasal 56:
  • "adequacy" — Pasal 56(a): destination has equivalent protection
  • "safeguards" — Pasal 56(b): binding legal instrument (generic label)
  • "pasal_56b_dpa" — Pasal 56(b): the explicit DPA tag, preferred for auditor surfacing; semantic equivalent of "safeguards"
  • "consent" — Pasal 56(c): explicit data-subject consent

safeguards and pasal_56b_dpa are recognized interchangeably and surfaced verbatim in the export — AxonFlow never auto-translates between them — so the audit record shows exactly the basis the caller recorded. The transfer_basis column is available once the enterprise audit-fields migration is applied; the OJK export reads cross-border audit entries back for the cross_border_transfers data type when they carry a non-empty transfer_basis.

Verifying cross-border compliance

Export cross-border transfer records for a compliance review. start_date and end_date use YYYY-MM-DD (date-only):

curl -X POST http://localhost:8080/api/v1/ojk/audit/export \
  -H "Content-Type: application/json" \
  -H "X-Tenant-ID: your-tenant" \
  -d '{
    "start_date": "2026-01-01",
    "end_date": "2026-03-31",
    "data_types": ["cross_border_transfers"],
    "format": "json",
    "framework": "UU_PDP"
  }'

Each cross_border_transfers record carries transfer_basis, data_residency, destination_country, and timestamp — the evidence needed for both prior- and post-transfer notification to MOCDA under Art. 56. To filter for DPA-backed (Pasal 56(b)) transfers, select records where transfer_basis is "pasal_56b_dpa" or "safeguards". To correlate these attestations with downstream cloud-warehouse activity in your SIEM, see the Decision Mode SIEM Correlation Recipe.

Recommended operating pattern

Cadence	Action	Detail
Weekly	Review readiness for UU PDP posture	GET /api/v1/ojk/audit/readiness
Monthly	Review cross-border transfer log	Export with data_types: ["cross_border_transfers"]
Quarterly	Verify retention posture	GET /api/v1/ojk/audit/retention
On incident	Generate breach notification within 72h	POST /api/v1/ojk/breach/notify
On incident	Scope impact via targeted export	POST /api/v1/ojk/audit/export with incident date filters
Post-incident	Preserve full breach-response evidence	Full-scope export covering discovery through remediation

Related docs

• Compliance Overview
• Enterprise Compliance API Surface
• OJK AI Governance Compliance
• BI Payment System Compliance
• PII Detection
• Human-in-the-Loop