KEDInsights

Mengapa Kesiapan PDP Bank Sebenarnya Ujian Arsitektur Data

Oleh KED Consulting November 14, 2026 6 menit baca

Coba tanyakan kesiapan Pelindungan Data Pribadi (PDP) kepada sebuah bank di Indonesia hari ini, dan jawabannya kemungkinan besar terdengar familiar. Kebijakan privasi sudah diperbarui. Klausul persetujuan sudah direvisi. Pejabat pelindungan data pribadi sudah atau segera ditunjuk. Record of Processing Activities (ROPA) sedang difinalkan oleh tim kepatuhan.

Semua itu penting. Tetapi ada pertanyaan lain yang jauh lebih sederhana, dan justru lebih sulit dijawab.

Jika besok pagi seorang nasabah meminta salinan lengkap seluruh data pribadinya, berapa banyak sistem yang harus ditanya, dan apakah semuanya bisa dijawab dalam 3 x 24 jam?

Mulai 16 Januari 2027, pertanyaan itu berhenti menjadi latihan berpikir. Ia menjadi kewajiban.

Dokumen Lengkap, Data Tercecer

PP 33/2026, peraturan pelaksana UU Pelindungan Data Pribadi, diundangkan pada 16 Juli 2026 dan berlaku penuh enam bulan kemudian. Dengan 225 pasal, peraturan ini mengatur banyak hal, mulai dari dasar pemrosesan, hak subjek data, ROPA dan DPIA, hingga transfer data lintas negara.

Wajar jika banyak organisasi memperlakukannya sebagai proyek hukum. Bahasanya hukum, sanksinya administratif, dan dokumen yang diminta terdengar seperti pekerjaan tim kepatuhan.

Namun jika dibaca dari sudut operasional, kewajiban yang paling menantang justru bersifat teknis dan memiliki jam yang terus berdetak. Menurut ringkasan hukum atas PP tersebut, sebagian besar permintaan subjek data, seperti akses, koreksi, dan penarikan persetujuan, harus dipenuhi dalam 3 x 24 jam. Notifikasi kegagalan pelindungan data juga wajib dilakukan dalam 3 x 24 jam setelah kegagalan itu dipastikan.

Tujuh puluh dua jam bukan waktu untuk rapat koordinasi lintas divisi. Itu waktu untuk sistem yang sudah tahu jawabannya.

Di sinilah letak ketegangannya. Kepatuhan PDP ditulis oleh tim legal, tetapi akan diuji di arsitektur data.Kemampuan menemukan seluruh data seorang nasabah, menghapus atau membatasinya secara konsisten, dan menelusuri ke mana data itu pernah dikirim sepenuhnya bergantung pada inventaris aplikasi, peta integrasi, salinan data, dan kontrak vendor. Hal-hal ini jarang masuk ke dalam lingkup proyek kepatuhan.

Rencana Evakuasi dan Latihan Kebakaran

Setiap gedung perkantoran punya rencana evakuasi. Denah ditempel di dekat lift, jalur keluar diberi tanda, dan petugas lantai sudah ditunjuk. Di atas kertas, semuanya lengkap.

Pengelola gedung yang berpengalaman tahu bahwa rencana itu baru bermakna setelah latihan kebakaran. Saat latihan, barulah terlihat pintu darurat yang terkunci, tangga yang dipakai sebagai gudang, atau lantai yang alarmnya tidak terdengar.

ROPA adalah rencana evakuasi. Permintaan nasabah dengan tenggat 72 jam adalah latihan kebakarannya.

Bayangkan sebuah skenario hipotetis. Seorang nasabah bank berukuran menengah meminta salinan seluruh datanya sekaligus menarik persetujuan untuk pemasaran. Datanya ada di core banking dan aplikasi mobile. Bagian itu mudah. Tetapi datanya juga ada di CRM, di platform kartu kredit yang dikelola prosesor pihak ketiga, di perusahaan jasa penagihan, di data warehouse, di beberapa lingkungan pengujian yang memakai salinan data produksi, di spreadsheet kampanye unit pemasaran, dan mungkin di model credit scoring yang dilatih tahun lalu. Sebagian lokasi ini tidak pernah tercatat di ROPA, karena ROPA disusun dari wawancara dengan pemilik proses, bukan dari pemindaian sistem.

Tidak ada yang berbohong dalam skenario ini. ROPA-nya hanya menggambarkan arsitektur yang dimaksudkan, bukan arsitektur yang benar-benar berjalan.

Sinyal yang Mulai Terlihat

Tanda bahwa regulator memahami jarak ini sudah muncul. Regulator menekankan tiga pilar kepatuhan, yaitu regulasi, organisasi, dan perangkat pendukung. Termasuk juga mendorong agar ROPA dan DPIA dipakai untuk memetakan pemrosesan dan mengelola risiko, tidak sekadar memenuhi dokumentasi. Ini prinsipnya menyoroti akuntabilitas di sepanjang siklus hidup data, termasuk saat data nasabah digunakan pihak lain, serta pengawasan AI yang memakai data pribadi.

Pada saat yang sama, perangkat penegakannya sedang dibangun. Pada 4 November, Komdigi menyatakan bahwa rancangan Perpres pembentukan lembaga pengawas PDP sudah diajukan kepada Presiden dan satuan tugas transisi telah dibentuk. Sampai lembaga itu berdiri, Komdigi tetap menjalankan fungsi pengawasan. Kasus Fore Kopi memperlihatkan bagaimana hal ini berjalan dalam praktik. Perusahaan melaporkan dugaan kegagalan pelindungan data yang memengaruhi 5,7 juta akun pelanggan kepada Komdigi pada 28 Oktober, setelah menghentikan akses ilegal dalam 24 jam. Fore memang bukan bank. Tetapi kasus ini menunjukkan bahwa jalur pelaporan sudah aktif, bahkan sebelum lembaganya resmi terbentuk.

Data global memberi gambaran tentang kesiapan organisasi secara umum. Survei ISACA terhadap lebih dari 1.800 profesional privasi menemukan hanya 46 persen yang sangat atau sepenuhnya yakin timnya mampu mematuhi regulasi privasi baru. Median ukuran tim privasi justru turun dari delapan menjadi lima orang. Tim yang mengecil diminta memikul kewajiban yang membesar.

Lalu ada persoalan data yang berpindah tanpa tercatat. Laporan IBM Cost of a Data Breach 2026, yang mempelajari 602 organisasi yang mengalami kebocoran data, menemukan shadow AI terlibat dalam 43 persen insiden, lebih dari dua kali lipat dibanding tahun sebelumnya. Lebih dari dua pertiga organisasi belum memiliki tata kelola untuk membatasinya. Studi ini bersifat global dan lintas industri, sehingga angkanya tidak bisa langsung diterapkan pada perbankan Indonesia. Namun arahnya relevan. Data nasabah semakin mudah mengalir ke tempat yang tidak pernah masuk inventaris.

Pertanyaan untuk CIO, Bukan Hanya untuk Legal

Jika PDP adalah ujian arsitektur, beberapa implikasinya cukup jelas bagi pimpinan teknologi.

Akuntabilitas perlu ditata ulang. Tim legal dan kepatuhan tetap menafsirkan aturan. Tetapi kemampuan memenuhi permintaan dalam 72 jam adalah kapabilitas layanan yang dimiliki fungsi TI, sama seperti ketersediaan sistem atau waktu pemulihan bencana.

Repositori enterprise architecture perlu berbicara tentang data pribadi. Banyak bank sudah memiliki katalog aplikasi dan peta integrasi. Jarang sekali katalog itu mencatat data pribadi apa yang disimpan setiap aplikasi, dari mana asalnya, dan ke mana dikirim. Tanpa itu, ROPA dan dokumen arsitektur akan terus bercerita hal yang berbeda.

Vendor ada di dalam tenggat waktu. Jika prosesor kartu atau perusahaan penagihan butuh lima hari kerja untuk merespons, bank sudah gagal sebelum mulai. Klausul kontrak dan integrasi teknis dengan pihak ketiga menjadi bagian dari kepatuhan.

AI menambah lapisan yang belum banyak dipetakan. Ringkasan hukum PP 33/2026 menyebut pemrosesan berisiko tinggi, termasuk penerapan teknologi baru seperti AI, sebagai pemicu DPIA. Bagaimana menghormati penarikan persetujuan ketika data seseorang sudah dipakai melatih model masih belum punya jawaban sederhana.

Empat Langkah yang Bisa Dimulai Sebelum Januari

Sembilan minggu tidak cukup untuk merombak arsitektur data. Tetapi cukup untuk mengetahui posisi yang sebenarnya.

1. Jalankan latihan kebakaran 72 jam. Minta sepuluh karyawan yang juga nasabah untuk mengajukan permintaan akses dan salinan data melalui kanal resmi. Ukur berapa lama prosesnya, berapa sistem dan tim yang terlibat, dan berapa lokasi data yang ditemukan tetapi tidak tercatat di ROPA. Hasilnya akan lebih jujur daripada asesmen kesiapan mana pun.

2. Bangun ROPA dari sistem, tidak hanya dari wawancara. Jalankan pemindaian data discovery di data warehouse, file share, dan lingkungan non-produksi, lalu cocokkan hasilnya dengan katalog aplikasi enterprise architecture. Mulailah dari domain dengan volume data nasabah terbesar, kemudian perluas.

3. Perlakukan persetujuan sebagai event, bukan sekadar kolom di database. Ketika nasabah menarik persetujuan, perubahan itu harus mengalir ke seluruh sistem hilir dan mitra. Langkah awal yang praktis adalah memetakan sistem mana yang saat ini membaca status persetujuan dan mana yang tidak pernah membacanya. Untuk vendor, tetapkan tenggat respons dalam kontrak yang masih menyisakan waktu bagi bank.

4. Letakkan AI di peta. Inventarisasi use case AI yang memakai data pribadi, baik untuk pelatihan maupun di dalam prompt, termasuk alat yang dipakai karyawan tanpa persetujuan resmi. Use case berisiko tinggi menjadi kandidat pertama untuk DPIA.

Ukuran keberhasilannya juga perlu berubah. Alih-alih melaporkan persentase dokumen yang selesai, laporkan waktu rata-rata untuk menemukan seluruh data satu nasabah dan persentase sistem yang sudah tercakup pemindaian otomatis. Dua angka ini jauh lebih jujur bercerita kepada direksi dan komite pemantau risiko.

Pertanyaan yang Sebenarnya

Tanggal 16 Januari 2027 akan datang dan berlalu. Pada hari itu, sebagian besar bank akan memiliki dokumen yang rapi.

Ujian yang sesungguhnya datang kemudian, dengan cara yang jauh lebih biasa. Seorang nasabah mengisi formulir, mengirim email, atau datang ke cabang dan bertanya, "Data apa saja yang Anda simpan tentang saya?"

Pada saat itu, ROPA yang paling rapi pun tidak bisa menjawab sendiri. Yang menjawab adalah arsitektur.

Maka mungkin pertanyaan paling berguna bukan lagi "Apakah kita sudah patuh?" Pertanyaan yang lebih jujur adalah "Berapa jam yang kita butuhkan untuk benar-benar mengenal nasabah kita sendiri?"

Langkah berikutnya

Ubah wawasan menjadi tindakan.

Diskusikan tantangan teknologi Anda dengan para ahli kami — tanpa biaya, tanpa komitmen.