Indonesia's PDP Law: A Practical Software Compliance Checklist

Indonesia's Law No. 27 of 2022 on Personal Data Protection—commonly called the PDP Law or UU PDP—cannot be implemented by adding a privacy-policy page alone. It affects how software collects data, explains processing, records a legal basis, fulfils individual rights, limits access, works with vendors, transfers data, retains records, and responds to incidents.

For product and engineering teams, the practical challenge is translating legal obligations into data models, interfaces, permissions, logs, workflows, and evidence. This checklist provides a structured starting point for that work.

Important: This article is general operational and technical guidance, not legal advice. The correct obligations depend on your role, processing purpose, sector, contracts, and current implementing rules. Confirm the final design with qualified Indonesian legal counsel.

First, Know Your Role

The PDP Law distinguishes between a Personal Data Controller, which determines the purposes and exercises control over processing, and a Personal Data Processor, which processes data on behalf of a controller.

A business may be both, depending on the activity. A software company can be controller for its employee and customer-account data, while acting as processor for records a client stores in the platform.

This role affects contracts, instructions, responsibility, incident handling, and how requests from data subjects are routed. Record the role for each processing activity instead of assigning one label to the whole company.

1. Build a Personal-Data Inventory

You cannot protect data you cannot locate. Inventory personal data across production systems, SaaS tools, data warehouses, logs, support platforms, backups, spreadsheets, test environments, exports, and vendor services.

For each dataset, record:

• Data elements and whether they are general or specific personal data.
• Data-subject group, such as customer, employee, applicant, supplier, or website visitor.
• Business purpose and legal basis.
• Source and collection point.
• Controller, processor, system owner, and authorised users.
• Storage location and cross-border flow.
• Retention period and deletion method.
• Downstream systems, reports, and vendors.
• Security classification and key controls.

The law identifies specific personal data such as health information, biometric data, genetic data, criminal records, children's data, and personal financial data. These categories deserve stricter design review and access control.

Evidence to retain: the inventory, data-flow diagrams, ownership records, and a dated review history.

2. Connect Every Purpose to a Valid Basis

Do not treat consent as a universal answer. The PDP Law provides several bases for processing, including explicit valid consent, contractual necessity, legal obligations, vital interests, public-interest or public-authority tasks, and other legitimate interests subject to balancing the controller's interests with the data subject's rights.

Create a processing register that connects each purpose to its basis. “Improve our services” is usually too broad to guide engineering. Describe the operation: for example, “analyse failed checkout events for 30 days to identify technical defects.”

Where consent is used:

• Present a specific and understandable purpose.
• Avoid combining unrelated optional purposes.
• Record the notice version, choice, timestamp, channel, and relevant subject or account.
• Make withdrawal as operationally usable as collection.
• Propagate the change to downstream systems.
• Do not continue consent-dependent processing after a valid withdrawal unless another basis applies and is properly documented.

Evidence to retain: the processing register, balancing assessment where applicable, notice versions, and consent or withdrawal records.

3. Apply Purpose Limitation and Data Minimisation

Each field should have an owner and a reason to exist. Remove fields collected “just in case.” Avoid copying complete customer profiles into systems that need only an identifier and status.

Review:

• Forms and required fields.
• Analytics events and session-replay tools.
• Application, database, and infrastructure logs.
• Search indexes and caches.
• Customer-service transcripts.
• Machine-learning training and evaluation datasets.
• Non-production data.
• CSV and spreadsheet exports.

Mask or synthesise personal data in development and testing wherever possible. Debugging convenience is not a durable processing purpose.

Evidence to retain: field-level specifications, analytics schemas, log-redaction rules, and non-production data policy.

4. Design Workflows for Data-Subject Rights

The PDP Law provides rights concerning information, access, correction, processing, deletion or destruction, withdrawal, objection to certain automated decisions, restriction, claims, and—subject to the law's conditions—data portability.

The software does not need one giant “privacy” feature, but the organisation needs an end-to-end fulfilment process.

Design for:

• Identity verification proportionate to request risk.
• Searching across every system linked to the person.
• Case ownership, due dates, status, and approval.
• Export in a useful and secure format where applicable.
• Correction propagation to downstream copies.
• Restriction that stops prohibited use without destroying required evidence.
• Deletion that covers primary stores, derived data, search indexes, and scheduled backup expiry.
• Recording exceptions and the legal reason for them.
• Secure delivery and a complete audit trail.

Test the workflow with a real internal scenario. If a request depends on an engineer manually searching unknown databases, the process is not operationally ready.

5. Set Retention and Deletion Rules

“Keep forever” is not a retention policy. Define retention by data category and purpose, taking account of legal, contractual, tax, employment, dispute, and security requirements.

Implementation controls may include:

• Expiry fields on records.
• Scheduled deletion or anonymisation jobs.
• Lifecycle rules for object storage and backups.
• Deletion events consumed by downstream systems.
• Legal-hold flags that prevent premature deletion.
• Reports for failed deletions and orphaned copies.

Deletion should be verifiable. Record the policy and result without retaining the personal data that should have been removed.

6. Implement Security Appropriate to the Risk

The PDP Law requires controllers to protect personal data and prevent unauthorised access. Translate that obligation into a risk-based control set.

At minimum, assess:

• Least-privilege access and regular access reviews.
• Strong authentication for privileged and remote access.
• Encryption in transit and at rest, with managed keys.
• Secret storage and rotation.
• Tenant and customer-data isolation.
• Secure development, dependency management, and vulnerability remediation.
• Audit logging for reads, exports, changes, and administrative actions.
• Monitoring for unusual access and bulk extraction.
• Backup protection and restore testing.
• Incident response exercises.

Security logs themselves can contain personal data. Limit their content, access, and retention while preserving useful evidence.

7. Assess High-Risk Processing Before Launch

Article 34 requires a personal-data-protection impact assessment for processing with high potential risk. The law lists examples including automated decisions with legal or significant effect, processing specific personal data, large-scale processing, systematic monitoring, matching or combining datasets, new technology, and processing that limits the exercise of rights.

Integrate this assessment into product discovery and architecture review, not the final release checklist.

Document:

• Purpose, necessity, and proportionality.
• Data flow and affected people.
• Misuse, error, discrimination, access, and security risks.
• Controls and residual risk.
• Reviewers, decision, conditions, and review date.

8. Control Processors and Vendors

A contract is necessary, but vendor governance also needs technical enforcement.

Before onboarding a processor, verify the service, data locations, subprocessors, security controls, deletion capability, incident notification, audit evidence, and support for rights requests. Provide documented instructions and limit access to what the service needs.

Maintain a vendor register connected to the data inventory. When a vendor is retired, confirm access revocation, data return or deletion, token removal, and downstream subprocessor handling.

9. Review Cross-Border Transfers

Article 56 establishes requirements for a controller transferring personal data outside Indonesia. The controller must assess the destination's level of protection and, where the specified conditions are not met, provide adequate and binding protection or obtain the data subject's consent in accordance with the law.

Map transfers created by cloud regions, support access, analytics, email, backups, content delivery, and subprocessors. “Our server is in Indonesia” does not by itself prove that no cross-border processing occurs.

Record the destination, recipient, data, purpose, transfer mechanism, assessment, and review date. Obtain legal advice for the selected mechanism and current implementing requirements.

10. Prepare for Breach Notification

Article 46 requires written notification no later than 3 x 24 hours to affected data subjects and the institution when a personal-data-protection failure occurs. The notice must include at least what data was disclosed, when and how it occurred, and the handling and recovery measures taken by the controller.

Meeting that window requires preparation:

• A clear incident definition and internal reporting route.
• On-call legal, security, privacy, communications, and business owners.
• Data inventory and logs sufficient to determine scope.
• Preserved evidence and a decision timeline.
• Approved notification workflow and secure contact data.
• Processor contracts with sufficiently fast notification duties.
• Exercises that test nights, weekends, and incomplete information.

Do not wait for perfect certainty before starting the response process. Record what is known, what is not yet known, and who is deciding the next step.

11. Determine Whether a Data Protection Officer Is Required

Article 53 requires appointment of an official or officer performing the personal-data-protection function in specified circumstances, including certain public-service processing, large-scale systematic monitoring, or large-scale processing of specific personal data or criminal-record data. A Constitutional Court decision has affected the wording of Article 53(1)(b), so organisations should use the current legal text and counsel when assessing the threshold.

Even where a formal appointment is not required, assign accountable privacy ownership across legal, security, product, and engineering.

12. Maintain Audit-Ready Evidence

Compliance is difficult to demonstrate if decisions exist only in meetings and chat messages.

Maintain:

• Data inventory and processing register.
• Policies, standards, and assigned owners.
• Notices, consent records, and legal-basis assessments.
• Impact assessments and security reviews.
• Rights-request records and response evidence.
• Vendor and transfer assessments.
• Access reviews, security tests, training, and incident exercises.
• Retention and deletion reports.
• Incident decisions and notifications.
• Change history for material processing.

Evidence should be current, access-controlled, and proportionate. Collecting unnecessary personal data “for compliance” creates another risk.

A Practical Implementation Sequence

First 30 days: assign ownership, map critical data and vendors, identify high-risk processing, confirm incident contacts, and stop obvious overcollection or unsafe access.

Days 31–60: create the processing register, legal-basis record, retention schedule, rights-request workflow, vendor review, and cross-border transfer map.

Days 61–90: automate deletion and request fulfilment where practical, strengthen logging and monitoring, test breach response, close high-risk gaps, and establish quarterly review.

Prioritise systems containing specific personal data, large datasets, financial records, children's data, employee data, or information exposed to many internal and external users.

Make Privacy a Software Capability

UU PDP compliance is not a document project. It is an operating capability supported by software: knowing where data is, controlling why it is used, enforcing who may access it, responding to people, deleting it on schedule, and producing evidence.

If your current systems make those actions manual or invisible, DualByte's IT consulting service can help turn legal and risk requirements into a phased technical roadmap. Final legal interpretation should remain with qualified counsel.

Official Sources

• BPK Regulation Database: Law No. 27 of 2022 on Personal Data Protection
• Official PDF of Law No. 27 of 2022