Pengenalan Kepentingan yang Sah (Legitimate Interest)
Pasal 20(f) UU PDP memungkinkan pemrosesan data pribadi untuk kepentingan yang sah yang ditempuh oleh pengendali data atau pihak ketiga. Legitimate interest adalah dasar hukum yang paling fleksibel dan sekaligus paling kompleks. Tidak seperti persetujuan yang bersifat subyektif (subjek data boleh menolak tanpa alasan), atau kewajiban hukum yang bersifat mandatory, legitimate interest memerlukan evaluasi mendalam dan seimbang antara kepentingan pengendali data dan hak-hak fundamental subjek data.
Kepentingan yang sah bukanlah kepentingan apapun—kepentingan harus:
(1) benar-benar dimiliki oleh pengendali atau pihak ketiga (bukan hipotesis),
(2) relevan dengan konteks bisnis atau sosial yang sah, dan
(3) tidak tertimpa secara jelas oleh kepentingan atau hak fundamental subjek data. Jika dalam evaluasi ditemukan bahwa hak subjek data lebih berat daripada kepentingan pengendali, tidak dapat menggunakan legitimate interest sebagai dasar hukum—harus mencari dasar hukum lain (persetujuan atau pemenuhan perjanjian).
Contoh Legitimate Interest yang Sah
Penggunaan legitimate interest yang umumnya valid mencakup:
(1) fraud prevention dan security—pemprosesan log login dan deteksi anomali untuk mencegah unauthorized access,
(2) network security—pemrosesan data traffic untuk mengidentifikasi serangan DDoS dan malware,
(3) direct marketing ke existing customers—mengirim penawaran khusus kepada pelanggan yang telah membeli sebelumnya (dengan hak objeksi),
(4) customer relationship management (CRM) analytics—menganalisis pola pembelian untuk meningkatkan layanan,
(5) intra-group data sharing—transfer data antar subsidiary dalam grup yang sama untuk operational efficiency, dan
(6) legal claims dan enforcement—mempertahankan data untuk pembelaan dalam litigasi atau investigasi regulasi.
Contoh Legitimate Interest yang Tidak Sah
Sebaliknya, legitimate interest tidak dapat digunakan untuk:
(1) pemrosesan data sensitif (kesehatan, biometrik, genetika) tanpa alasan khusus—biasanya memerlukan explicit consent,
(2) profiling yang menghasilkan automated decision yang merugikan (misalnya, automated credit denial tanpa review manusia) tanpa ada safeguard,
(3) surveillance atau tracking yang ekstensif atas dasar "marketing research" ketika dampaknya merugikan privasi subjek data secara signifikan,
(4) penjualan data ke pihak ketiga tanpa konteks apapun bahwa subjek data mengetahui atau mengharapkan hal ini, dan
(5) kombinasi data dari berbagai sumber yang tidak terkait untuk menciptakan profil komprehensif tentang subjek data ketika tidak ada basis kontraktual atau legal untuk kombinasi tersebut.
| KONSEP KUNCI | Legitimate interest bukanlah blanket permission untuk memproses data demi "efisiensi bisnis" atau "inovasi produk." Setiap penggunaan legitimate interest harus didukung oleh Legitimate Interest Assessment (LIA) yang terstruktur, terdokumentasi, dan dapat dipertahankan dalam audit atau litigasi. Tanpa LIA yang solid, organisasi berisiko tinggi diputuskan melakukan pemrosesan tanpa dasar hukum yang sah oleh LPDP atau pengadilan. |
Kerangka Legitimate Interest Assessment (LIA)
LIA adalah proses evaluasi terstruktur untuk menentukan apakah pemrosesan data dapat didasarkan pada legitimate interest. LIA terdiri dari tiga tahap yang saling terkait:
(1) Purpose Test—identifikasi dan artikulasikan kepentingan sah yang spesifik,
(2) Necessity Test—evaluasi apakah pemrosesan benar-benar diperlukan untuk mencapai kepentingan tersebut dan apakah ada alternatif yang kurang invasif, dan
(3) Balancing Test—menimbang kepentingan pengendali data terhadap hak dan kebebasan fundamental subjek data.
Tahap 1: Purpose Test
Tahap pertama adalah mengidentifikasi apa kepentingan yang sah yang ingin dicapai. Kepentingan harus diartikan dengan spesifik, bukan secara general. Misalnya, "meningkatkan customer experience" terlalu umum—lebih spesifik adalah "mengidentifikasi produk yang mungkin relevan bagi customer berdasarkan purchase history mereka untuk mengurangi friction dalam product discovery proses." Kepentingan harus juga legitimate, artinya tidak bertentangan dengan hukum atau nilai-nilai publik. Kepentingan yang murni profit-seeking tanpa manfaat bagi subjek data atau publik lebih sulit untuk dipertahankan.
Tahap 2: Necessity Test
Tahap kedua adalah mengevaluasi apakah pemrosesan data benar-benar diperlukan (necessary) untuk mencapai kepentingan yang telah diidentifikasi. Pertanyaan yang harus dijawab: Apakah tujuan dapat dicapai tanpa memproses data pribadi? Bisakah tujuan dicapai dengan data yang telah dianonimasi? Apakah diperlukan data real-time atau bisa menggunakan data agregat? Apakah semua data yang ingin diproses benar-benar diperlukan atau hanya sebagian kecil saja? Jika sebagian besar dari kegiatan dapat dicapai dengan data yang kurang invasif, maka not all of the processing dapat dibenarkan atas dasar legitimate interest yang sama.
Tahap 3: Balancing Test
Tahap ketiga adalah balancing test—menimbang kepentingan pengendali data terhadap hak, kebebasan, dan ekspektasi subjek data. Pertanyaan kunci: Apakah subjek data dapat wajar mengharapkan bahwa data mereka akan diproses dengan cara ini? Apa dampak pemrosesan terhadap subjek data? Apakah ada risiko diskriminasi atau harm? Apa posisi subjek data relatif terhadap pengendali (apakah mereka vulnerable, seperti anak-anak atau orang tua?)? Apa jenis data yang diproses (sensitif atau bukan)? Jika kepentingan pengendali adalah profit dari iklan yang ditargetkan secara ketat, sementara dampak terhadap subjek data adalah jenis data sensitif dikombinasikan dan profiled untuk automated decisions, balancing test akan cenderung gagal.
Tabel berikut menunjukkan contoh LIA untuk berbagai skenario pemrosesan:
| Skenario Pemrosesan | Purpose Test (Kepentingan) | Necessity Test (Kebutuhan) | Balancing Test (Kesimpulan) |
|---|---|---|---|
| Analisis fraud pada transaksi e-commerce | Melindungi bisnis dan customer dari fraud financial loss | Perlu data: transaksi history, IP, device, payment method; alternatif: biaya fraud insurance tapi kurang efektif | PASS: kepentingan strong, data terbatas pada fraud signals, subjek data juga untung (proteksi), dampak minimal |
| Marketing email ke existing customers | Direct marketing dan revenue growth dari repeat purchases | Perlu: email, purchase history; alternatif: iklan paid tapi mahal | PASS: kepentingan legitimate, customer sudah dikenal, dampak minimal, hak objeksi tersedia |
| Tracking user behavior di website untuk "analytics" | Improve user experience dan conversion | Perlu: click tracking, session duration; alternatif: aggregated analytics tanpa individual tracking | BORDERLINE: perlu LIA mendalam; jika tracking ekstensif (across-site, long retention), balancing cenderung gagal. Harus ada granular consent atau minimize tracking. |
| Intra-group data transfer ke parent company | Centralized analytics dan operational efficiency | Perlu: full dataset transfer; alternatif: anonymize atau aggregate, atau limited subset | PASS IF: transfer hanya untuk purposes yang sudah disclosed, subject telah diberitahu atau reasonable expectation, data minimized |
| Automated profiling untuk credit decisioning | Risk assessment dan fraud prevention | Perlu: financial data, behavior signals; alternatif: require human review of declined applications | FAIL/RISKY: automated decision tanpa human review berisiko merugikan; balancing test akan fail kecuali ada strong safeguard dan objection mechanism |
| Genetic data research buat pharmaceutical company | Drug development dan public health benefit | Perlu: full genetic profiles; alternatif: anonymized atau aggregated data | FAIL: data sangat sensitif, benefit mostly untuk company bukan individual, privacy expectation sangat tinggi; explicit consent wajib |
Dokumentasi Legitimate Interest Assessment
Dokumentasi LIA adalah bukti compliance yang kritis. Organisasi harus menyimpan dokumen LIA untuk setiap kegiatan pemrosesan yang mengandalkan legitimate interest. Dokumen LIA harus mencakup:
(1) deskripsi kegiatan pemrosesan dan tujuan spesifik,
(2) analisis purpose test—penjelasan mengapa kepentingan dianggap sah dan legitimate,
(3) analisis necessity test—penjelasan mengapa pemrosesan diperlukan dan apakah ada alternatif kurang invasif,
(4) analisis balancing test—evaluasi hak dan kebebasan subjek data, dampak pemrosesan, ekspektasi yang reasonable, dan faktor mitigasi,
(5) kesimpulan—apakah legitimate interest dapat digunakan atau harus diganti dengan dasar hukum lain, dan
(6) tanggal dokumentasi dan reviewer (nama dan jabatan orang yang melakukan LIA).
LIA harus dilakukan oleh tim yang memiliki pemahaman tentang aspek hukum, teknis, dan bisnis pemrosesan. Tidak boleh hanya dikerjakan oleh marketing atau engineering teams tanpa input dari legal dan data protection teams. LIA harus juga direview secara periodik (minimal tahunan) ketika ada perubahan signifikan dalam operasi pemrosesan atau peraturan yang relevan.
Faktor-Faktor dalam Balancing Test
Balancing test mempertimbangkan berbagai faktor yang mempengaruhi outcome keseimbangan antara kepentingan pengendali dan hak subjek data:
(1) Sifat data yang diproses—data biasa (nama, email) memiliki dampak lebih rendah daripada data sensitif (kesehatan, lokasi real-time).
(2) Scope pemrosesan—pemrosesan terbatas pada data minimal lebih mudah dibenarkan daripada pemrosesan komprehensif atas semua data yang tersedia.
(3) Reasonable expectation—apakah subjek data dapat wajar mengharapkan pemrosesan ini dalam konteks? Customer mengirim produk mungkin mengharapkan email follow-up, tetapi mungkin tidak mengharapkan tracking lokasi berbulan-bulan setelah purchase.
(4) Severity of impact—apakah pemrosesan dapat menyebabkan harm fisik, finansial, atau emosional kepada subjek data?
(5) Vulnerability—apakah subjek data termasuk kelompok vulnerable (anak, orang tua, immigrant)?
(6) Reasonable expectation of data usage—apakah ada notice atau transparency tentang pemrosesan?
(7) Existence of safeguards—apakah ada security measures, retention limits, atau objection mechanisms yang mengurangi risiko?
| PENTING | Balancing test bukanlah exercise teoretis—organisasi harus mampu menunjukkan dengan data konkret dan analisis mendalam bahwa kepentingan mereka outweigh hak subjek data. Jika saat diaudit atau digugat subjek data menunjukkan bahwa dampak atas diri mereka adalah signifikan, sementara kepentingan pengendali adalah marginal (misalnya, profit dari iklan yang hanya menghasilkan 0.5% additional revenue), balancing test akan gagal. Dokumentasi harus menunjukkan bahwa evaluasi dilakukan dengan serius, bukan hanya checklist belaka. |
Data Subject Right to Object (Hak Keberatan)
Ketika pemrosesan didasarkan pada legitimate interest, subjek data memiliki hak untuk mengajukan keberatan atas pemrosesan tersebut kapan saja, sesuai Pasal 34 UU PDP. Berbeda dengan persetujuan yang dapat ditarik tanpa alasan, keberatan terhadap legitimate interest harus didasarkan pada alasan tertentu—yaitu, bahwa hak atau kebebasan subjek data tertimpa oleh pemrosesan. Pengendali data harus mengevaluasi keberatan dan, jika alasan subjek data lebih kuat dari kepentingan pengendali, harus menghentikan pemrosesan.
Praktik terbaik adalah menyediakan mekanisme yang mudah untuk subjek data mengajukan keberatan—baik melalui email, form online, atau channel lain. Organisasi harus merespons keberatan dalam jangka waktu yang masuk akal (biasanya 30 hari) dengan mempertimbangkan alasan subjek data dan mengevaluasi ulang legitimate interest. Jika menolak keberatan, organisasi harus memberikan penjelasan transparan mengapa kepentingan mereka tetap outweigh hak subjek data.
Legitimate Interest dan Special Categories of Data
Untuk data spesifik atau sensitif (kesehatan, biometrik, genetika, anak, dll), penggunaan legitimate interest sangat terbatas. Pasal 20 mengindikasikan bahwa kategori data ini umumnya hanya dapat diproses berdasarkan explicit consent atau dasar hukum lain yang lebih kuat (kepentingan vital, kewajiban hukum). Pengecualian untuk data kesehatan dalam Pasal 20(c) memungkinkan pemrosesan atas dasar kewajiban hukum (misalnya, untuk compliance dengan UU Kesehatan), tetapi bukan atas dasar legitimate interest murni.
Oleh karena itu, jika ingin memproses data sensitif berdasarkan legitimate interest, organisasi harus:
(1) melakukan LIA yang sangat mendalam dan ekstensif,
(2) menunjukkan bahwa dampak terhadap privasi dan hak fundamental subjek data sudah diminimalisir sejauh mungkin,
(3) menyediakan hak objeksi yang mudah diakses dan meaningful, dan
(4) mempertimbangkan apakah explicit consent mungkin lebih tepat sebagai dasar hukum untuk kategori data ini.
Perubahan Legitimate Interest Atau Penambahan Purpose Baru
Jika organisasi awalnya memproses data berdasarkan legitimate interest untuk tujuan A, tetapi kemudian ingin memperluas untuk tujuan B yang berbeda, harus melakukan LIA terpisah untuk tujuan B. Tidak dapat mengasumsikan bahwa jika legitimate interest valid untuk tujuan A, otomatis valid juga untuk tujuan B. Setiap tujuan baru harus melewati analisis purpose, necessity, dan balancing test tersendiri.
Selain itu, organisasi harus memberitahukan kepada subjek data tentang tujuan baru dan memberikan kesempatan untuk mengajukan keberatan. Jika banyak subjek data mengajukan keberatan atas tujuan baru, ini menjadi sinyal bahwa balancing test mungkin harus dievaluasi ulang—jika sebagian besar subjek data menunjukkan bahwa mereka tidak menginginkan pemrosesan ini, ini menunjukkan bahwa kepentingan pengendali tidak seimbang.
Tabel berikut menunjukkan checklist untuk implementasi legitimate interest yang robust:
| Elemen Compliance | Deskripsi | Evidence/Dokumentasi Minimal | Owner/Tanggung Jawab |
|---|---|---|---|
| LIA Documentation | Tertulis, terstruktur, covering 3-prong test | LIA form signed by DPO + legal review | Data Protection Officer + Legal Counsel |
| Necessity Analysis | Identifikasi bahwa data/processing adalah necessity | Data minimization review + alternatives evaluation | Data Engineer + DPO |
| Balancing Test | Evaluasi impact dan safeguards | Risk assessment + fairness review | DPO + Business Analyst |
| Safeguards Implementation | Technical/organizational controls untuk mitigasi | Encryption audit + access logs + retention schedule | Data Engineer + Security Team |
| Transparency/Notice | Komunikasi ke subject data tentang processing | Privacy notice update + notification copy | Legal + Marketing |
| Objection Mechanism | Easel way untuk subject data to object | Objection form + response template + audit log | Customer Service + DPO |
| Periodic Review | LIA direview min. annually atau saat ada change | Review log + dated LIA updates | DPO + stakeholder owner |