Kalimat ‘data adalah aset’ terdengar bagus sampai data itu bocor
CRM menyimpan nama, nomor telepon, email, histori pembelian, complaint, dan kadang profil yang jauh lebih detail. Identity platform bisa memproses KTP, wajah, atau data verifikasi. Semakin kaya data, semakin besar value untuk personalization, fraud prevention, dan service. Tetapi semakin besar juga konsekuensi kalau aksesnya salah.
Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi memberi framework pengendali dan prosesor data pribadi. Untuk bisnis, distinction ini penting karena memakai vendor SaaS tidak otomatis memindahkan seluruh tanggung jawab.
Pengendali menentukan tujuan pemrosesan
UU PDP mendefinisikan Pengendali Data Pribadi sebagai pihak yang menentukan tujuan dan melakukan kendali pemrosesan. Kalau bisnis mengumpulkan data customer untuk loyalty, CRM, atau transaction, bisnis biasanya punya role penting sebagai pengendali pada process tersebut.
Vendor yang memproses atas instruksi bisa berada pada role prosesor sesuai konteks kontrak dan aktivitas.
Menunjuk prosesor tidak berarti tanggung jawab hilang
Pasal 51 UU PDP menyatakan pemrosesan oleh prosesor berdasarkan perintah pengendali termasuk dalam tanggung jawab pengendali. Jika prosesor memproses di luar perintah dan tujuan yang ditetapkan, tanggung jawab dapat berubah sesuai ketentuan.
Ini alasan kontrak data processing dan scope vendor penting.
Pengendali wajib melindungi dan memastikan keamanan
Pasal 35 sampai 39 UU PDP mengatur kewajiban langkah teknis-operasional, confidentiality, supervision, protection dari unauthorized processing, dan prevention of unauthorized access.
Jadi keamanan data bukan sekadar best practice opsional. Ia masuk kewajiban hukum pada framework tersebut.
CRM membuat data mudah dipakai, tetapi juga mudah tersebar
Sales export customer list ke Excel, marketing upload ke ad platform, agency meminta CSV, customer service buka dashboard, dan finance punya data transaksi. Setiap copy membuat attack surface baru.
Data governance perlu tahu siapa boleh akses, untuk tujuan apa, dan berapa lama.
Verihubs menunjukkan verification vendor memproses data yang sensitif
Verihubs current menawarkan ID Check, OCR, face recognition, liveness, deepfake detection, watchlist, and KYB. Ini adalah class data dan processing yang membutuhkan governance lebih ketat.
Vendor claim seperti ISO 27001 atau benchmark tertentu membantu procurement, tetapi business tetap perlu memahami scope sertifikasi dan data flow.
VIDA memperlihatkan fraud prevention makin multi-signal
VIDA meluncurkan ID FraudShield pada Mei 2026 dengan biometric verification, device analysis, dan real-time fraud detection menurut perusahaan. Ini meningkatkan kemampuan risk detection, sekaligus menunjukkan jumlah signal yang bisa diproses semakin banyak.
Semakin banyak signal, semakin penting purpose limitation dan retention policy.
Security vendor juga bukan magic shield
Managed security, endpoint protection, monitoring, and incident response dapat mengurangi risk. Tetapi vendor tidak bisa mengamankan data yang business sendiri export sembarangan atau share credential lewat chat.
Security control dan operational behavior harus nyambung.
Siapa bertanggung jawab ketika vendor bocor?
Jawabannya bergantung pada role, instruction, contract, dan bagaimana processing terjadi. UU PDP membedakan pengendali dan prosesor, dan prosesor wajib memproses berdasarkan perintah pengendali.
Bisnis harus tahu data flow sebelum incident, bukan setelah press statement diperlukan.
Contract dengan SaaS perlu membahas data
Jenis data, purpose, security measure, subprocessors, breach notification, location, retention, deletion, audit, and exit perlu diperiksa sesuai risk.
Terms of service generik mungkin cukup untuk tool low-risk. Untuk identity atau customer data critical, procurement perlu lebih dalam.
Least privilege adalah control paling praktis
Sales tidak harus export seluruh database. Agency tidak perlu access semua customer. Intern tidak perlu admin. Batasi role dan cabut access ketika orang pindah team.
Data breach sering diperbesar oleh privilege yang terlalu luas.
Data minimization membuat risk lebih kecil
Kalau bisnis hanya butuh nomor telepon untuk update delivery, jangan otomatis meminta tanggal lahir, alamat rumah, dan pekerjaan. Data yang tidak dikumpulkan tidak bisa bocor dari sistem kita.
Collect karena ada purpose, bukan karena field-nya tersedia.
Encryption penting, tetapi access governance tetap wajib
Data terenkripsi at rest tidak membantu jika attacker login sebagai user valid dan bisa download data. MFA, session control, anomaly detection, and permission tetap penting.
Security adalah layer, bukan checkbox tunggal.
Incident response perlu melibatkan legal dan customer communication
Ketika breach terjadi, tim harus menentukan scope, containment, legal obligation, notification, dan evidence. Panic communication bisa salah, tetapi diam terlalu lama juga risk.
Playbook sebaiknya disiapkan sebelum incident.
Data memang aset, tetapi aset selalu punya liability
CRM dan identity technology membuat perusahaan bisa mengenal customer lebih baik. Verihubs dan VIDA menunjukkan verification serta fraud stack semakin sophisticated. UU PDP menempatkan security dan accountability pada pengendali maupun prosesor sesuai role.
Prinsip paling sehat adalah sederhana: kumpulkan seperlunya, batasi access, pilih vendor dengan hati-hati, dokumentasikan purpose, dan siapkan response.
Data pelanggan menjadi aset hanya selama bisnis mampu menjaga trust orang yang datanya dipakai.
Inventory data pribadi perlu dimulai dari mapping
Bisnis perlu tahu data apa yang dikumpulkan, di system mana, siapa owner, siapa vendor, dan ke mana data ditransfer. Tanpa map, security team tidak tahu scope.
Data flow diagram sederhana sering lebih useful daripada privacy policy yang panjang.
Data classification membantu menentukan control
Nomor telepon customer punya risk berbeda dari biometric, KTP, financial record, atau password credential. Security dan access sebaiknya mengikuti sensitivity.
Semua data tidak perlu control paling mahal, tetapi data sensitif tidak boleh diperlakukan seperti spreadsheet marketing biasa.
Vendor subprocessor perlu diperhatikan
SaaS bisa memakai cloud, email provider, analytics, verification, atau support tool lain. Pengendali perlu tahu jika data diteruskan ke pihak lain sesuai relevance dan contract.
UU PDP juga mengatur keterlibatan sub-prosesor oleh prosesor dalam kondisi tertentu.
Retention harus punya akhir
Data lama sering disimpan ‘just in case’. Semakin lama disimpan, semakin besar exposure. Tentukan kapan data dihapus atau dianonimkan sesuai purpose dan kewajiban.
Storage murah bukan alasan menyimpan semua selamanya.
Access review perlu berkala
Employee pindah role tetapi access lama masih aktif adalah problem umum. Review user dan permission setiap beberapa bulan untuk system customer critical.
Offboarding harus menutup SaaS, VPN, email, CRM, and shared drive.
Export data perlu dikontrol
CRM yang aman bisa kehilangan manfaat jika user bebas export satu juta record ke laptop pribadi. Batasi export, watermark atau log activity sesuai tool, dan edukasi team.
Security harus melihat data setelah keluar dari system utama.
Breach response harus menjaga evidence
Log, timeline, affected account, and data scope perlu dipertahankan untuk investigation. Jangan buru-buru menghapus semua hal sebelum forensic review.
Containment dan evidence preservation perlu berjalan seimbang.
Customer communication harus faktual
Jangan bilang ‘tidak ada data bocor’ sebelum investigation cukup. Sebaliknya, jangan menakuti customer dengan spekulasi. Pisahkan fakta, langkah containment, dan action yang perlu user lakukan.
Trust paling cepat rusak ketika statement berubah-ubah.
Privacy dan security bukan hal yang sama
System bisa sangat secure tetapi data dikumpulkan tanpa purpose yang sehat. Sebaliknya, privacy policy bagus tidak membantu jika password admin bocor.
Governance perlu dua-duanya: legal basis/purpose dan technical control.
Data sebagai aset seharusnya punya cost accounting mental
Setiap dataset baru membawa cost security, retention, consent, access, and incident risk. Kalau business value kecil, mungkin lebih baik tidak dikumpulkan.
Data minimization adalah strategi ekonomi sekaligus privacy.
Data breach bukan cuma masalah hacker eksternal
Insider, wrong recipient, public link, misconfiguration, lost laptop, dan vendor error juga bisa menyebabkan exposure. Threat model perlu mencakup human mistake.
Security awareness dan access review sama pentingnya dengan firewall.
Backup data pribadi juga perlu policy
Backup memperpanjang keberadaan data. Jika record dihapus dari aplikasi utama tetapi masih tersimpan lama di backup, retention policy perlu menjelaskan bagaimana lifecycle-nya.
Privacy dan resilience harus dirancang bersama.
Vendor due diligence perlu mengikuti sensitivity
Tool newsletter dengan email basic tidak sama dengan identity provider yang memproses biometrik. Questionnaire dan contract depth sebaiknya risk-based.
Procurement tidak perlu memperlakukan semua SaaS seperti bank, tapi jangan juga semua dianggap sama ringan.
Data breach cost muncul di banyak tempat
Forensic, legal, notification, reset credential, customer support, downtime, vendor review, dan reputasi dapat berjalan bersamaan. Itu sebabnya prevention investment perlu dibandingkan dengan operational impact.
Privacy risk akhirnya menjadi business risk.
Trust adalah aset yang paling sulit dipulihkan
Customer biasanya tidak tahu architecture perusahaan. Mereka hanya tahu pernah memberikan data karena percaya pada layanan.
Kalau bisnis ingin menyebut data sebagai aset, responsibility menjaga trust harus dianggap bagian dari value asset tersebut.
Data protection perlu masuk product design
Feature baru yang ingin mengumpulkan data tambahan sebaiknya ditanya sejak awal: purpose apa, apakah benar perlu, siapa access, berapa lama disimpan, dan apa risk-nya.
Privacy by design lebih murah daripada membersihkan data berlebihan setelah produk terlanjur scale.
Log access juga data sensitif
Audit log membantu investigation, tetapi log bisa berisi identifier, IP, device, atau activity. Retention dan access-nya juga perlu governance.
Security telemetry bukan area bebas privacy.
Board atau owner perlu menerima ringkasan data risk
Management tidak perlu membaca semua technical detail. Mereka perlu tahu data paling sensitif, vendor kritis, incident readiness, dan remediation yang belum selesai.
Accountability menjadi nyata ketika risk punya owner dan deadline.
Responsibility data tidak bisa dipindahkan hanya dengan mencentang terms vendor. Bisnis tetap perlu tahu data apa yang dikumpulkan, untuk apa, siapa yang memproses, dan bagaimana incident ditangani.
Perusahaan yang paling siap biasanya tidak menunggu insiden untuk mencari siapa data owner-nya. Mereka sudah punya daftar system, vendor, access, escalation, dan contact legal atau security yang bisa bergerak ketika ada indikasi exposure.
Data governance yang sederhana tetapi dijalankan konsisten lebih aman daripada policy tebal yang tidak pernah diterjemahkan menjadi access rule, retention, dan review vendor.
Dan itu perlu dibuktikan rutin.
Cek bukti sebelum percaya pada narasi
Saat membaca Data Pelanggan Jadi Aset: Tapi Siapa yang Bertanggung Jawab Kalau Bocor?, pembaca perlu memisahkan klaim, fakta terverifikasi, dan asumsi. Contoh entity seperti CRM/SaaS brands, Verihubs, VIDA, cybersecurity brands berguna sebagai pintu masuk, tetapi keputusan tidak boleh berhenti pada nama brand. Periksa sumber primer, tanggal informasi, ruang lingkup layanan, serta limitation yang dinyatakan. Untuk UMKM, disiplin ini penting karena biaya salah keputusan biasanya muncul setelah kontrak, pembelian, atau perubahan proses sudah berjalan. Evidence yang bisa ditelusuri lebih bernilai daripada kalimat promosi yang terdengar pasti tetapi tidak memberi metode verifikasi. Untuk artikel UKMS-HUMANIS-094, lensa ini dipakai sebagai quality gate agar analisis tetap terhubung dengan keputusan pembaca, bukan menjadi filler.