Checklist UU PDP untuk Aplikasi Web: Menerjemahkan Pasal Menjadi Fitur

Mengapa UU PDP Adalah Urusan Engineering, Bukan Hanya Legal

Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP) memberi masa penyesuaian dua tahun sejak diundangkan pada 17 Oktober 2022, sehingga kewajibannya kini sudah berlaku. Aturan pelaksananya, Peraturan Pemerintah Nomor 33 Tahun 2026, menurut ulasan Hukumonline ditetapkan pada 16 Juli 2026 dan mulai berlaku 16 Januari 2027.

Banyak bisnis merespons dengan memperbarui kebijakan privasi, lalu berhenti. Masalahnya, sebagian besar kewajiban UU PDP hanya bisa dipenuhi oleh sistem: mencatat persetujuan, menghapus data tepat waktu, atau mengirim notifikasi kebocoran dalam hitungan jam. Kebijakan privasi yang menjanjikan sesuatu yang tidak bisa dilakukan aplikasi Anda justru menjadi bukti ketidakpatuhan. Post ini menerjemahkan pasal-pasal yang paling sering bersinggungan dengan aplikasi web menjadi checklist teknis.

Catatan: ini panduan teknis, bukan nasihat hukum. Untuk menentukan dasar pemrosesan, kewajiban pejabat pelindungan data, dan kepatuhan sektoral, konsultasikan dengan ahli hukum.

1. Persetujuan dan Transparansi

UU PDP menyebut beberapa dasar pemrosesan yang sah (Pasal 20), salah satunya persetujuan yang sah secara eksplisit untuk tujuan tertentu. Jika Anda memakai dasar persetujuan, Pasal 21 mewajibkan Anda menyampaikan, antara lain, tujuan pemrosesan, jenis data, jangka waktu retensi, dan hak pengguna.

Yang perlu dibangun:

• Checkbox persetujuan per tujuan, tidak dicentang secara default. Persetujuan untuk "memproses pesanan" dan "mengirim promo" adalah dua hal berbeda.
• Tabel consents yang menyimpan siapa, tujuan apa, versi teks kebijakan, waktu, dan sumber (web, aplikasi, WhatsApp). Tanpa catatan ini, Anda tidak bisa membuktikan persetujuan pernah diberikan.
• Tombol menarik persetujuan yang sama mudahnya dengan memberi persetujuan. Pasal 40 mewajibkan pemrosesan dihentikan paling lambat 3 × 24 jam setelah persetujuan ditarik.

Solusi: simpan versi kebijakan privasi sebagai data, bukan hanya halaman. Saat teks berubah, Anda tahu persis pengguna mana yang menyetujui versi lama.

2. Minimalisasi Data dan Retensi

Pasal 27 mewajibkan pemrosesan yang terbatas dan spesifik, sesuai tujuan. Penjelasan pasalnya menyebut pengumpulan data harus terbatas sesuai tujuan yang ditentukan saat pengumpulan. Ini sejalan dengan prinsip engineering lama: OWASP menyebut cara terbaik melindungi informasi sensitif adalah tidak menyimpannya sama sekali.

Yang sering kami temui di audit: formulir pendaftaran yang meminta NIK, tanggal lahir, dan alamat lengkap untuk layanan yang hanya butuh email; serta log server yang diam-diam menyimpan nomor telepon dan isi formulir selama bertahun-tahun.

• Untuk setiap kolom di formulir, tulis alasan bisnisnya. Tidak ada alasan, hapus kolomnya.
• Tentukan masa retensi per jenis data, lalu buat scheduled job yang menghapus atau menganonimkan data yang lewat masa itu.
• Bersihkan data pribadi dari log aplikasi, pesan error, dan tool analitik.

Solusi: masa retensi yang hanya tertulis di dokumen tidak berarti apa-apa. Yang dihitung adalah job yang benar-benar berjalan dan tercatat.

3. Keamanan Teknis

Pasal 35 mewajibkan pengendali data menyusun dan menerapkan langkah teknis operasional untuk melindungi data, dengan tingkat keamanan yang disesuaikan dengan sifat dan risiko datanya. Pasal 39 mewajibkan pencegahan akses tidak sah. UU tidak menyebut teknologi tertentu, jadi ukurannya adalah praktik yang wajar untuk risiko data Anda.

Checklist minimum kami:

• HTTPS di semua halaman, termasuk panel admin dan API internal.
• Enkripsi data saat disimpan (encryption at rest) di database dan backup; enkripsi tingkat kolom untuk data spesifik seperti data keuangan pribadi atau kesehatan.
• Password di-hash dengan algoritma yang dirancang untuk password, bukan dienkripsi.
• Hak akses berbasis peran: staf CS tidak perlu melihat semua kolom pelanggan.
• Rahasia (API key, kredensial database) di secret manager atau environment variable, tidak pernah di repository.
• Backup yang terenkripsi dan diuji pemulihannya.

Banyak poin ini sudah ada di checklist deployment server produksi kami; UU PDP membuatnya menjadi kewajiban, bukan lagi sekadar praktik baik.

4. Hak Pengguna: Akses, Koreksi, dan Hapus

UU PDP memberi tenggat yang sangat konkret untuk beberapa permintaan pengguna. Pengendali data wajib memperbaiki data paling lambat 3 × 24 jam sejak permintaan diterima (Pasal 30), memberi akses dalam waktu yang sama (Pasal 32), dan menghapus data dalam kondisi tertentu, misalnya saat pengguna memintanya (Pasal 43).

Tiga hari kalender tidak cukup jika prosesnya adalah "email ke admin, admin tanya developer, developer menjalankan query manual".

• Halaman profil tempat pengguna melihat dan memperbaiki datanya sendiri.
• Fitur ekspor data dalam format yang bisa dibaca, misalnya JSON atau CSV.
• Alur hapus akun yang menelusuri semua tempat data berada: database utama, layanan email marketing, CRM, dan penyimpanan file. Simpan juga catatan bahwa penghapusan sudah dilakukan.
• Antrian permintaan dengan stempel waktu, agar tenggat 3 × 24 jam bisa dipantau.

Solusi: buat peta aliran data (data map) lebih dulu. Anda tidak bisa menghapus data dari sistem yang tidak Anda ketahui menyimpannya. Panduan 5 kesalahan integrasi API kami relevan di sini, karena setiap integrasi adalah salinan data baru.

5. Pencatatan, Pihak Ketiga, dan Transfer Data

Pasal 31 mewajibkan perekaman seluruh kegiatan pemrosesan data pribadi, dan Pasal 37 mewajibkan pengawasan terhadap setiap pihak yang memproses data di bawah kendali Anda. Untuk aplikasi web, "pihak" ini termasuk penyedia cloud, layanan email, payment gateway, tool analitik, dan penyedia AI.

• Daftar semua vendor yang menerima data pribadi, jenis data yang diterima, dan lokasi servernya.
• Pastikan kontrak dengan vendor mengatur pemrosesan data pribadi, bukan hanya layanan.
• Untuk data yang dikirim ke luar Indonesia, Pasal 56 mewajibkan Anda memastikan negara penerima punya tingkat pelindungan setara atau lebih tinggi, atau ada pelindungan yang memadai dan mengikat. Diskusikan mekanismenya dengan ahli hukum.
• Simpan audit log siapa mengakses atau mengubah data pribadi, dan kapan.

Jika Anda memakai WhatsApp Business API atau layanan AI, keduanya juga masuk daftar ini.

6. Notifikasi Kegagalan Pelindungan Data

Pasal 46 adalah pasal yang paling sering membuat tim kewalahan: jika terjadi kegagalan pelindungan data pribadi, pengendali wajib memberi tahu subjek data dan lembaga secara tertulis paling lambat 3 × 24 jam. Isinya minimal data apa yang terungkap, kapan dan bagaimana, serta upaya penanganan dan pemulihannya. Dalam hal tertentu, masyarakat juga wajib diberi tahu.

Anda tidak bisa menjawab "data apa, kapan, dan bagaimana" dalam tiga hari jika tidak punya log.

• Deteksi: alert untuk login admin yang mencurigakan, lonjakan ekspor data, dan error akses yang berulang.
• Log yang cukup: akses ke data pribadi tercatat dengan waktu dan pelaku, disimpan di tempat yang terpisah dari server aplikasi.
• Runbook insiden: siapa yang memutuskan, siapa yang menyelidiki, siapa yang menulis notifikasi, lengkap dengan template suratnya.
• Latihan: jalankan simulasi setidaknya sekali, agar runbook tidak pertama kali dibaca saat insiden nyata.

Solusi: hitung mundur dari tenggat. Jika investigasi butuh dua hari, Anda hanya punya satu hari untuk menyusun dan mengirim pemberitahuan.

Risiko Jika Diabaikan

UU PDP mengatur sanksi administratif berupa peringatan tertulis, penghentian sementara pemrosesan, penghapusan atau pemusnahan data, dan denda administratif paling tinggi 2% dari pendapatan atau penerimaan tahunan (Pasal 57). Ada juga ketentuan pidana untuk perolehan, pengungkapan, dan penggunaan data pribadi secara melawan hukum. Di luar sanksi, kehilangan kepercayaan pelanggan sering kali lebih mahal.

Checklist Ringkas

• Persetujuan per tujuan, tercatat dengan versi kebijakan dan bisa ditarik.
• Setiap kolom data punya alasan bisnis dan masa retensi; penghapusan otomatis berjalan.
• Data pribadi tidak bocor ke log dan analitik.
• HTTPS, enkripsi saat disimpan, hashing password, akses berbasis peran.
• Pengguna bisa melihat, memperbaiki, mengekspor, dan menghapus datanya.
• Peta aliran data dan daftar vendor yang menerima data pribadi.
• Audit log akses data pribadi.
• Runbook insiden dan template notifikasi 3 × 24 jam, sudah dilatih.

Jika Anda sedang menyiapkan aplikasi baru, masukkan poin-poin ini sejak awal ke spesifikasi proyek. Menambahkannya setelah sistem berjalan selalu lebih mahal.

Pendekatan AY Labs

Kami memperlakukan UU PDP sebagai kebutuhan fitur, bukan lampiran dokumen. Di proyek baru, kami memetakan data pribadi apa yang benar-benar dibutuhkan sebelum mendesain database, lalu membangun pencatatan persetujuan, retensi otomatis, dan alur hak pengguna sebagai bagian dari aplikasi. Untuk sistem yang sudah berjalan, kami mulai dari audit teknis: di mana data pribadi tersimpan, siapa yang bisa mengaksesnya, dan apakah log Anda cukup untuk menjawab pertanyaan Pasal 46. Kami bekerja berdampingan dengan konsultan hukum Anda, karena keputusan hukum tetap ada di tangan mereka. Jika Anda ingin tahu seberapa siap aplikasi Anda sebelum PP 33/2026 berlaku, kami siap membantu memeriksanya.