Third-Party Risk Management 2026: 9 Kontrol Vendor IT
Third-Party Risk Management 2026 harus diperlakukan sebagai bagian dari IT governance, bukan sekadar proses pengadaan. Organisasi semakin bergantung pada cloud provider, software-as-a-service, data centre, payment gateway, managed service provider, konsultan, pengembang aplikasi, penyedia API, dan vendor keamanan.
Ketergantungan tersebut mempercepat transformasi digital, tetapi juga memperluas permukaan risiko. Risiko tidak hilang ketika aktivitas dialihkan kepada vendor.
Organisasi tetap dapat menanggung dampak ketika pihak ketiga mengalami:
- Kebocoran data;
- Ransomware;
- Penghentian layanan;
- Kegagalan subkontraktor;
- Pelanggaran regulasi;
- Kegagalan pemulihan;
- Kebangkrutan;
- Perubahan layanan secara sepihak.
CISA menempatkan supply chain risk management sebagai bagian terintegrasi dari keamanan dan ketahanan. NIST Cybersecurity Framework 2.0 juga memasukkan cybersecurity supply chain risk management dalam fungsi Govern.
Di sektor keuangan Uni Eropa, DORA membentuk kerangka pengawasan terhadap penyedia layanan ICT pihak ketiga yang dinilai kritis dan mendorong pengelolaan risiko pihak ketiga secara lebih terstruktur.
Mengapa Vendor IT Menjadi Risiko Strategis?
Vendor modern jarang bekerja secara mandiri. Satu aplikasi SaaS dapat memakai cloud provider, identity provider, analytics service, customer support platform, open-source library, dan beberapa subprosesor data.
Akibatnya, organisasi tidak hanya bergantung pada vendor yang menandatangani kontrak, tetapi juga pada rantai pihak lain yang mungkin tidak terlihat secara langsung.
Kelemahan umum third-party risk management adalah penilaian hanya dilakukan sekali saat onboarding. Kuesioner keamanan dikirim, dokumen sertifikasi dikumpulkan, kontrak ditandatangani, lalu vendor dianggap aman selama bertahun-tahun.
Pendekatan tersebut tidak memadai karena layanan, kepemilikan perusahaan, subprosesor, teknologi, lokasi data, dan profil ancaman dapat berubah.
Berikut sembilan kontrol vendor IT yang dapat diterapkan.
1. Inventaris dan Klasifikasi Vendor
Organisasi harus mempunyai satu inventaris vendor IT yang konsisten. Inventaris minimal mencatat:
- Nama vendor;
- Pemilik hubungan;
- Layanan yang diberikan;
- Sistem yang terhubung;
- Data yang diakses;
- Lokasi pemrosesan;
- Subkontraktor;
- Nilai dan periode kontrak;
- Tanggal evaluasi terakhir.
Vendor kemudian diklasifikasikan berdasarkan kritikalitas. Faktor penilaiannya mencakup sensitivitas data, hak akses, dampak penghentian layanan, volume transaksi, kemampuan penggantian, ketergantungan proses kritis, dan persyaratan regulasi.
Vendor kritis harus menerima due diligence, monitoring, dan pengujian yang lebih ketat dibandingkan vendor berisiko rendah.
2. Due Diligence Berbasis Risiko
Due diligence tidak boleh hanya berupa kuesioner dengan jawaban “ya” atau “tidak”. Organisasi perlu meminta bukti yang sesuai dengan tingkat risiko.
Bukti tersebut dapat meliputi:
- Kebijakan keamanan;
- Hasil audit;
- Laporan penetration test;
- Sertifikasi;
- Arsitektur layanan;
- Prosedur incident response;
- Business continuity plan;
- Data flow;
- Vulnerability management;
- Daftar subprosesor.
Tim penilai juga harus memeriksa kesenjangan antara jawaban vendor dan kondisi layanan. Sebagai contoh, sertifikasi keamanan yang dimiliki perusahaan induk belum tentu mencakup produk yang dibeli.
Laporan audit yang telah kedaluwarsa juga tidak membuktikan kondisi kontrol saat ini. Ruang lingkup, tanggal, pengecualian, dan temuan laporan harus diperiksa.
3. Persyaratan Keamanan Sejak Pengadaan
Kontrol vendor harus dimasukkan sebelum keputusan pembelian, bukan setelah kontrak hampir ditandatangani.
Request for proposal dan evaluasi teknis perlu memuat persyaratan mengenai:
- Manajemen akses;
- Enkripsi;
- Logging;
- Data residency;
- Secure development;
- Backup;
- Pemulihan;
- Vulnerability management;
- Integrasi identitas;
- Dukungan insiden;
- Penghapusan data;
- Penggunaan subkontraktor.
Dengan memasukkan persyaratan lebih awal, organisasi mempunyai posisi negosiasi yang lebih kuat. Ketika kontrol baru diminta setelah vendor terpilih, biaya perubahan biasanya lebih tinggi dan pilihan alternatif sudah terbatas.
4. Klausul Kontrak yang Dapat Ditegakkan
Kontrak harus mengubah komitmen keamanan menjadi kewajiban yang jelas. Klausul penting meliputi:
- Standar keamanan;
- Target layanan;
- Pemberitahuan insiden;
- Batas waktu pelaporan;
- Dukungan investigasi;
- Penyediaan log;
- Hak audit;
- Pengelolaan subkontraktor;
- Lokasi data;
- Kerahasiaan;
- Kepatuhan;
- Pemulihan;
- Pengembalian data;
- Penghapusan data;
- Penghentian layanan.
Hindari klausul yang terlalu umum seperti “vendor akan menerapkan praktik keamanan yang wajar” tanpa definisi, bukti, parameter, atau konsekuensi.
Kontrak juga perlu menentukan tanggung jawab ketika insiden berasal dari vendor atau subprosesornya.
5. Kontrol Akses dan Integrasi Teknis
Vendor seharusnya hanya memperoleh akses minimum yang dibutuhkan. Terapkan:
- Akun individual;
- Multi-factor authentication;
- Privileged access management;
- Approval workflow;
- Time-bound access;
- Session recording;
- Review akses berkala.
Akun bersama perlu dihindari karena menyulitkan atribusi. Akses vendor yang tidak lagi diperlukan harus dicabut segera.
Untuk integrasi API, organisasi perlu menerapkan authentication yang kuat, rotasi secret, rate limiting, monitoring, pembatasan data, dan mekanisme pencabutan akses.
Kredensial vendor tidak boleh disimpan tanpa enkripsi dalam source code, dokumen bersama, atau aplikasi komunikasi.
6. Monitoring Berkelanjutan
Third-Party Risk Management 2026 tidak berhenti setelah kontrak aktif. Organisasi perlu memonitor:
- Perubahan kontrol;
- Insiden;
- Kinerja layanan;
- Status sertifikasi;
- Temuan audit;
- Perubahan subprosesor;
- Perubahan kepemilikan;
- Perubahan teknologi;
- Kondisi keuangan vendor.
Frekuensi monitoring harus berbasis risiko. Vendor kritis dapat ditinjau setiap kuartal atau semester, sedangkan vendor berisiko rendah dapat ditinjau tahunan.
Temuan perlu mempunyai risk owner, due date, status mitigasi, dan keputusan penerimaan risiko jika tidak diperbaiki.
Ketika risiko vendor meningkat, organisasi harus menentukan apakah layanan dibatasi, kontrol tambahan diterapkan, risiko diterima, atau kontrak dihentikan.
7. Kesiapan Insiden Bersama
Ketika insiden terjadi, keterlambatan sering muncul karena organisasi dan vendor tidak mengetahui siapa yang harus dihubungi, data apa yang tersedia, dan siapa yang berwenang mengambil keputusan.
Vendor kritis harus mempunyai:
- Kontak insiden 24/7;
- Jalur eskalasi;
- Prosedur pengamanan bukti;
- Format pelaporan;
- Kewajiban pembaruan berkala;
- Dukungan investigasi;
- Mekanisme komunikasi pelanggan.
Lakukan tabletop exercise bersama vendor untuk skenario ransomware, kebocoran data, kompromi akun, kegagalan cloud region, atau kerusakan integrasi.
Latihan tersebut dapat menemukan kelemahan yang tidak terlihat dalam kontrak atau dokumen prosedur.
8. Kelola Risiko Konsentrasi dan Subkontraktor
Organisasi perlu mengetahui apakah beberapa layanan kritis bergantung pada provider yang sama. Dua aplikasi yang terlihat berbeda dapat berjalan pada cloud, data centre, atau identity provider yang sama.
Jika provider tersebut gagal, beberapa layanan dapat terdampak secara bersamaan. Risiko ini disebut sebagai risiko konsentrasi.
Vendor juga harus transparan mengenai subkontraktor dan subprosesor. Perubahan pihak pendukung yang material perlu diberitahukan.
Untuk layanan berisiko tinggi, organisasi dapat meminta hak untuk menolak perubahan subprosesor atau mewajibkan vendor menerapkan kontrol yang setara kepada seluruh subkontraktor.
9. Exit Plan dan Offboarding
Vendor yang tidak dapat dihentikan bukanlah vendor yang sepenuhnya terkendali. Exit plan harus menjelaskan cara:
- Memindahkan data;
- Mengganti layanan;
- Menjaga operasi selama transisi;
- Memperoleh dokumentasi;
- Mencabut akses;
- Menghapus data;
- Memverifikasi penghapusan;
- Mengelola biaya penghentian.
Offboarding perlu menggunakan checklist formal. Pastikan akun dinonaktifkan, token dan sertifikat dicabut, perangkat dikembalikan, koneksi diputus, data dikembalikan, salinan dihapus, dan kewajiban kerahasiaan tetap berlaku.
Untuk vendor kritis, exit plan harus diuji melalui simulasi atau minimal tabletop exercise. Jangan menunggu vendor gagal sebelum organisasi mengetahui bahwa proses migrasi ternyata membutuhkan waktu berbulan-bulan.
Metrik Third-Party Risk Management
Program vendor risk management perlu mempunyai indikator yang dapat dilaporkan kepada manajemen. Contohnya:
- Persentase vendor yang telah diklasifikasikan;
- Jumlah vendor kritis;
- Persentase due diligence yang masih berlaku;
- Temuan risiko tinggi yang belum diselesaikan;
- Vendor tanpa klausul insiden;
- Vendor tanpa exit plan;
- Vendor dengan sertifikasi kedaluwarsa;
- Konsentrasi layanan pada provider tertentu;
- Waktu pencabutan akses setelah kontrak berakhir.
Metrik harus menunjukkan risiko dan kebutuhan keputusan. Jumlah kuesioner yang telah dikirim bukan ukuran bahwa vendor benar-benar aman.
Kesimpulan
Third-Party Risk Management 2026 membutuhkan sembilan kontrol yang saling terhubung: inventaris dan klasifikasi, due diligence, persyaratan pengadaan, kontrak, kontrol akses, monitoring, kesiapan insiden, pengelolaan konsentrasi, serta exit plan.
Kontrol tersebut harus diterapkan secara proporsional berdasarkan kritikalitas vendor.
Kesalahan paling mahal adalah menganggap sertifikasi atau kontrak sebagai pengganti pengawasan. Sertifikasi hanya memberikan bukti untuk ruang lingkup dan periode tertentu. Kontrak juga tidak otomatis mencegah kegagalan.
Organisasi tetap perlu memverifikasi kontrol, memantau perubahan, menguji respons, dan memastikan bahwa layanan dapat dipindahkan ketika risiko tidak lagi dapat diterima.
