Belajar Technical Product Manager - Data Privacy Product

#Pendahuluan

Setelah di episode 18 kita menyusun threat model fitur kartu tersimpan dengan STRIDE dan abuse case, episode ini membahas sisi lain dari perlindungan yang sama: privasi data pengguna. Kalau security melindungi data dari penyerang, privasi memastikan data tidak disalahgunakan oleh sistem sendiri — termasuk oleh kita.

Kenapa ini penting untuk NusaPay? Karena kita memegang data finansial ratusan ribu end-customer merchant: nama, nomor rekening, pola belanja. Regulasi (UU PDP di Indonesia, GDPR untuk merchant dengan pelanggan Eropa) memberi hak nyata pada subjek data — dan TPM-lah yang menerjemahkan hak itu menjadi fitur, bukan sekadar halaman kebijakan yang tak dibaca.

#Dua Regulasi dalam Bahasa Produk

Kalian tidak perlu jadi pengacara; cukup pahami inti kewajiban dan padanan fiturnya:

Perbedaan penting konteks payment: NusaPay punya kewajiban hukum menyimpan catatan transaksi bertahun-tahun (anti pencucian uang) — jadi "hak hapus" tidak berarti menghapus ledger. Yang bisa dihapus adalah profil marketing, data perilaku, dan PII non-transaksional. Mengetahui garis batas antara "wajib simpan" dan "bisa hapus" inilah pekerjaan produk — bukan tebak-tebakan saat DSAR datang.

#Prinsip Privacy by Design

Tujuh prinsip klasiknya bisa diringkas jadi empat kebiasaan desain:

1. Proactive, bukan remedial: privasi dipikirkan di discovery, bukan ditambal sebelum rilis. Pertanyaan tetapnya: data apa persisnya yang fitur ini butuh?
2. Minimization: kalau fitur jalan tanpa field tertentu, hapus field itu dari skema. Data yang tidak dikumpulkan tidak bisa bocor.
3. Purpose limitation: data yang dikumpulkan untuk KYC tidak boleh diam-diam dipakai untuk scoring marketing. Setiap pemakaian baru = dasar pemrosesan baru.
4. Default ramah privasi: setting awal selalu opsi paling privat; sharing opt-in, bukan opt-out.

#Consent Ledger: Bukti yang Bisa Diaudit

Consent bukan checkbox; ia rekam jejak yang harus bisa dibuktikan saat regulator bertanya. Desain minimalnya:

{
  "subject_id": "enduser_88f2",
  "purpose": "marketing_promo",
  "granted": true,
  "timestamp": "2026-09-01T04:12:33Z",
  "source": "merchant-checkout-web",
  "policy_version": "2026-06",
  "ip_hash": "a91f...c2"
}

Empat properti yang membuatnya kuat: granular per tujuan (bukan satu tombol "setuju semua"), ada versi kebijakan yang disetujui, jejak waktu dan kanal, dan mudah dicabut — penarikan consent juga event yang tercatat. Untuk TPM, consent ledger adalah komponen platform: sekali dibangun, semua fitur berikutnya tinggal mendaftarkan purpose baru.

#DSAR Self-Service

Data Subject Access Request secara manual (email masuk → engineer query database → balas manual) adalah bom operasional: lambat, mahal, rawan salah kirim. Solusinya self-service:

• End-user atau merchant mengajukan request dari dashboard; identitas diverifikasi.
• Sistem mengekspor data sesuai peta data (data map) — inventaris "data siapa ada di tabel mana" yang wajib kalian pastikan ada.
• Request erasure masuk antrian dengan aturan retensi: PII non-transaksional dihapus/anonimkan, catatan transaksional dipertahankan sesuai kewajiban, status dilaporkan balik ke pemohon.

Metrik produknya: median waktu pemenuhan DSAR (target hari, bukan bulan) dan volume tiket support bertopik data. Angka ini juga yang ditanya enterprise buyer saat due diligence.

#Retention: Jadwal Kematian untuk Data

Setiap kategori data butuh jawaban eksplisit: disimpan berapa lama, lalu dibuang bagaimana?

Log transaksi      : wajib regulasi -> arsip 10 tahun (immutable)
PII verifikasi KYC : 5 tahun pasca hubungan berakhir -> anonimisasi
Log aplikasi       : 30 hari panas -> tiering murah -> hapus 180 hari
Data marketing     : sampai consent ditarik -> purge otomatis
Sandbox data       : 90 hari rotasi penuh

Dua keputusan produk di balik matriks ini: automation purge (retensi yang bergantung manusia mengingat akan gagal) dan anonimisasi vs penghapusan — data agregat yang sudah dianonim sering masih bernilai analitik tanpa beban privasi.

#Trust sebagai Keunggulan Kompetitif

Untuk platform pembayaran, reputasi privasi adalah aset komersial: merchant menitipkan relasi dengan customer mereka. Cara mengubah kepatuhan menjadi nilai jual:

• Halaman trust yang menjelaskan kontrol dalam bahasa manfaat ("data end-customer Anda tidak kami pakai untuk iklan").
• Laporan transparansi berkala (jumlah DSAR, insiden, uptime).
• Fitur yang terlihat: masking default, kontrol consent yang jelas — user akhirnya merasakan bedanya.

Kompetitor bisa meniru fitur pembayaran dalam kuartal; reputasi trust yang terbangun bertahun tidak bisa diduplikasi dengan budget marketing mana pun.

#Praktik: Privacy Design Kartu Tersimpan

Lanjut studi kasus: tulis privacy design section untuk fitur recurring payment — daftar data yang dikumpulkan plus justifikasi tiap field, purpose yang didaftarkan ke consent ledger, entri matriks retention untuk token & metadata, dan alur DSAR bila end-customer minta hapus. Simpan di 05-quality/privacy-vault.md.

#Penutup

Inti yang harus dibawa pulang:

• Security melindungi dari penyerang; privasi memastikan tidak ada penyalahgunaan internal — dua disiplin, satu tujuan: trust.
• Pahami regulasi lewat padanan fiturnya; kenali garis batas "wajib simpan" vs "bisa hapus" di domain payment.
• Empat kebiasaan by design: proactive, minimization, purpose limitation, default privat — mulai dari pertanyaan "field ini untuk apa?".
• Consent ledger dan DSAR self-service adalah infrastruktur platform, bukan proyek sekali pakai.
• Retensi tanpa automation gagal; trust yang terjaga menjadi moat kompetitif jangka panjang.

Di episode 20 selanjutnya kita bicara Compliance & Enterprise Tech — requirement teknis pembeli enterprise seperti SSO/SAML, SCIM, audit log, RBAC, data residency, dan SLA, plus cara menyusun enterprise spec serta implikasi pricingnya. Sampai jumpa!