Belajar Technical Product Manager - Security & Compliance Products

#Pendahuluan

Setelah di episode 13 kita menyusun SLO settlement dengan error budget policy — termasuk gerbang internal untuk SLA kontrak — episode ini membahas keluarga requirement yang tidak bisa dinego sama sekali: security & compliance. Untuk NusaPay yang memproses kartu dan data finansial, ini bukan bagian "nice to have" dari PRD; ini syarat berdiri di pasar.

Kenapa TPM harus paham ini secara teknis? Karena compliance menembus semua artefak kalian: ia mengubah desain fitur (data apa yang boleh ditampilkan), roadmap (audit butuh freeze), dan sales deck (sertifikasi jadi bahan bidik enterprise). TPM yang hanya tahu namanya akan selalu terkejut oleh biayanya.

#Tiga Standar yang Wajib Dikenal

Poin penting bagi TPM: ketiganya bukan ujian sekali jalan melainkan program berkelanjutan — kontrol harus hidup setiap hari, dan audit membuktikan itu. Konsekuensi produknya nyata: akses ke data produksi butuh approval, log wajib tersimpan periode tertentu, dan setiap vendor baru melewati due diligence.

#Tokenisasi: Contoh Security Jadi Desain Produk

Contoh paling konkret di NusaPay adalah penyimpanan kartu. Dua opsi arsitektur:

1. Simpan PAN (nomor kartu) sendiri: masuk scope PCI penuh — segmentasi jaringan, audit ketat, biaya kepatuhan besar.
2. Tokenisasi: nomor kartu disimpan provider vault bersertifikasi; sistem NusaPay hanya pegang token.

Opsi dua hampir selalu menang untuk startup: scope audit menyusut drastis, risiko breach turun, dan integrasi merchant malah lebih aman karena mereka juga hanya pegang token. Ini contoh sempurna bahwa keputusan security yang baik biasanya mengurangi permukaan, bukan menambah lapisan kontrol di atas permukaan yang luas.

Bagi produk, tokenisasi bahkan menjadi fitur jualan: "simpan kartu pelanggan Anda sekali, tagih berulang tanpa menyentuh data kartu". Keamanan berhenti jadi biaya pusat dan mulai jadi katalog produk.

#Menulis Requirement Compliance ke PRD

Requirement compliance punya pola penulisan khusus: sumber regulasinya eksplisit, dan verifikasinya bisa diaudit. Contoh pada fitur settlement T+0:

Sumber   : PCI DSS v4.0 req 8 & 10; UU PDP No.27/2022 art. 20
Req C1   : Aksi approve manual settlement T+0 hanya oleh role
           "finance-admin"; wajib MFA. [Verifikasi: test akses + log]
Req C2   : Setiap aksi approve/reject tercatat: user, waktu UTC,
           alasan bebas. Log immutable 12 bulan.
           [Verifikasi: sampling audit trail]
Req C3   : Nominal & rekening merchant ditampilkan termasking
           di notifikasi email/chat. [Verifikasi: review template]
Non-goal : Tidak ada perubahan alur penyimpanan kartu (vault tetap).

Tiga properti yang membuat blok ini berguna bagi engineer: referensi sumber (bisa diverifikasi maknanya), cara verifikasi per requirement (tidak ada debat saat UAT), dan non-goal eksplisit (scope tidak merambat). Pola ini kita perdalam di episode 18 (threat modeling) dan 20 (enterprise).

#Timeline dan Biaya yang Realistis

Ekspektasi sehat untuk perusahaan skala NusaPay:

• PCI DSS SAQ (self-assessment, volume kecil-menengah): satu kuartal persiapan, lalu siklus tahunan ringan.
• SOC 2 Type I (desain kontrol): sekitar 3-4 bulan siapkan kontrol + audit awal.
• SOC 2 Type II (efektivitas dengan observasi): butuh periode observasi minimal enam bulan — artinya harus dimulai hari ini kalau target enterprise tahun depan.
• ISO 27001: 6-9 bulan implementasi + audit lembaga sertifikasi.

Dua implikasi roadmap yang sering luput: pertama, periode observasi SOC 2 Type II tidak bisa dipadatkan dengan kerja keras — ia waktu kalender murni; mulai terlambat = masuk pasar terlambat. Kedua, audit biasanya butuh change freeze parsial beberapa pekan; jangan taruh bertepatan dengan cutover migrasi (episode 11).

Biaya tersembunyi yang wajib dianggarkan: konsultan/auditor, tooling evidence collection, dan pajak kecepatan — fitur yang menyentuh data sensitif akan selalu lebih lambat karena review tambahan. Itu normal; anggarkan, jangan kagetkan.

#Trust Center sebagai Aset Penjualan

Kumpulkan semua bukti kepercayaan di satu halaman publik: status sertifikasi, daftar sub-processor, ringkasan kebijakan keamanan, dan formulir request dokumentasi. Manfaatnya ganda:

• Tim sales berhenti mengganggu engineer untuk menjawab questionnaire yang sama berulang-ulang.
• Prospek enterprise melihat kesungguhan program keamanan sebelum bertanya — first impression yang menjual.

Metrik internalnya sederhana: jumlah pertanyaan keamanan berulang dari prospect turun drastis setelah trust center hidup. Itu jam engineering yang kembali ke pengembangan produk.

#Red Flag Saat Memilih Vendor Keamanan

Tokenization vault, KYC vendor, atau penyedia audit logging — pilihan vendor kalian adalah pilihan rantai keamanan. Sinyal bahaya saat due diligence:

• Tidak mau menunjukkan laporan SOC 2/ISO mereka (kalau menjual keamanan tapi tak punya bukti, itu kontradiksi).
• Menolak menjawab di mana data disimpan dan siapa sub-processornya.
• Tidak punya proses notifikasi breach tertulis dengan SLA waktu.
• Kontrak tidak memuat klausul keluar data saat berhenti langganan.

Satu red flag cukup untuk menunda keputusan — biaya mengganti vendor keamanan setelah terintegrasi jauh lebih mahal daripada dua pekan due diligence tambahan.

#Praktik: Security Section PRD Vault Tokenization

NusaPay ingin meluncurkan fitur "kartu tersimpan" untuk recurring payment. Tulis bagian compliance PRD-nya: pilih arsitektur tokenisasi via vault partner, daftar 4-5 requirement C dengan sumber standar + metode verifikasi masing-masing, estimasi dampak ke timeline (review tambahan), dan draf halaman trust center. Simpan di 03-specs/prd-vault.md.

#Penutup

Inti yang harus dibawa pulang:

• PCI DSS (kartu), SOC 2 (kontrol operasional), ISO 27001 (sistem manajemen) adalah program berkelanjutan, bukan ujian sekali jalan.
• Tokenisasi menunjukkan pola emas security: kurangi permukaan data, lalu ubahkan hasilnya sebagai fitur.
• Requirement compliance di PRD wajib punya sumber eksplisit, metode verifikasi, dan non-goal.
• Periode observasi SOC 2 Type II tak bisa dipadatkan; audit butuh freeze — rencanakan di roadmap, jangan biarkan menabrak milestone lain.
• Trust center mengubah bukti keamanan menjadi mesin penjualan yang menghemat jam engineering.

Di episode 15 selanjutnya kita bicara Developer Experience (DX) — mengelola docs, SDK, sandbox, dan onboarding sebagai produk utama NusaPay, mengukur time-to-first-call, dan menyusun DX roadmap yang bisa dipertanggungjawabkan. Sampai jumpa!