Kuesioner Keamanan Siber Pihak Ketiga: Bukti, Skor, Owner
Kuesioner mengumpulkan bukti, bukan jaminan keamanan
NIST SP 800-161 Rev. 1, diperbarui November 2024, memberi panduan manajemen risiko keamanan siber rantai pasok. Dokumen ini menempatkan risiko pemasok sebagai kerja visibilitas, assessment, dan mitigasi. CISA menjelaskan berbagi informasi sebagai bagian koordinasi insiden siber. Kedua sumber tidak menjadikan kuesioner pemasok sebagai bukti pemasok aman, patuh, bersertifikat, atau layak untuk setiap layanan.
Mulai dari konteks layanan: jenis data, wilayah hosting, integrasi, akses istimewa, subkontraktor, kekritisan bisnis, dan ketergantungan exit. Procurement buyer memiliki keputusan komersial; security memiliki review teknis; privacy/legal mereview kewajiban kontrak dan data; owner layanan menerima kecocokan operasional. Responden tidak boleh menilai pengecualiannya sendiri.
Pertanyaan, bukti, dan skor
Nilai setiap jawaban setelah meninjau bukti bernama: 2 = didukung dan terkini, 1 = sebagian didukung atau akan kedaluwarsa, 0 = tidak ada, bertentangan, atau di luar scope. Bukti lebih dari dua belas bulan, tanpa owner bernama atau batas layanan, bernilai maksimal 1 sampai diperbarui. Bobot mengikuti model risiko buyer; skor membantu triage, bukan menggantikan persetujuan.
| Domain dan pertanyaan | Permintaan bukti | Owner review | Aturan lulus/gagal |
|---|---|---|---|
| Inventaris layanan: Layanan dan data apa dalam scope? | diagram arsitektur/aliran data, daftar subprosesor terkini | owner layanan | lulus bila batas dan kelas data cocok dengan catatan procurement |
| Akses: Bagaimana akses istimewa disetujui dan dicabut? | sampel review akses, konfigurasi MFA, rekam terminasi | owner IAM | gagal bila populasi istimewa atau bukti pencabutan hilang |
| Kerentanan: Bagaimana temuan material ditangani? | kebijakan kini, sampel tiket tersanitasi, rekam retest | owner security | gagal bila owner, tenggat, atau validasi tidak ada |
| Koordinasi insiden: Bagaimana fakta dipertukarkan? | matriks kontak, kutipan playbook, pelajaran latihan terakhir | owner insiden | gagal bila jalur kontak atau eskalasi tanpa owner |
| Ketahanan dan exit: Bagaimana data/akses dikembalikan atau dihapus? | runbook exit, bukti penghapusan/penonaktifan | vendor manager | gagal bila exit tidak dapat diuji atau ditugaskan |
Contoh terisi: pemasok meng-host API jadwal berisiko rendah dan tidak memiliki akses istimewa produksi. Diagram aliran data cocok dengan kontrak; review akses enam bulan lalu memuat bukti pencabutan; satu tiket kerentanan punya bukti retest; matriks kontak insiden memiliki kontak operasional 24 jam tetapi owner kontrak perlu memvalidasi notifikasi. Skor: 2, 2, 2, 1, 1. Hasil: persetujuan bersyarat, dengan tenggat vendor manager untuk bukti exit teruji dan konfirmasi legal. Ini bukan “pemasok disetujui selamanya”.
Pengecualian dan remediasi
Pengecualian memuat celah kontrol, dampak layanan, rating risiko, kontrol kompensasi, otoritas penyetuju, tanggal mulai, kedaluwarsa, dan pemicu penilaian ulang. Tanpa kedaluwarsa, pengecualian gagal. Remediasi memuat owner pemasok akuntabel, owner buyer, aksi, bukti yang diharapkan, tenggat, dan metode verifikasi. Jawaban spreadsheet “terenkripsi” tanpa konfigurasi, scope, atau bukti pengelolaan kunci belum selesai, bukan lulus.
Lindungi bukti. Minta laporan dan sampel tersamarkan dahulu; jangan mengumpulkan kredensial, data pelanggan mentah, bukti eksploitasi, atau laporan pentest penuh tanpa kebutuhan serta custody yang ditentukan. Catat versi dokumen, tanggal diterima, reviewer, dan keputusan retensi.
Paket keputusan
Sebelum rapat persetujuan, owner buyer menyusun satu paket: deskripsi layanan, kuesioner terisi, indeks bukti, scorecard, jawaban belum selesai, pengecualian, tanggal remediasi, dan rekomendasi. Notulen menyatakan keputusan, syarat, kedaluwarsa, dan penandatangan akuntabel. Jika layanan berubah sebelum onboarding, buka kembali jawaban relevan; jangan meneruskan skor tanpa perubahan.
Uji bukti
Reviewer mengambil sampel klaim, bukan menerima pernyataan ringkas. Untuk enkripsi, tanyakan lokasi penerapan, data serta backup yang dicakup, pengelola kunci, dan tanggal konfigurasi direview. Untuk akses, cocokkan populasi user istimewa dengan bukti review. Untuk kesiapan insiden, hubungi satu kontak saat latihan disetujui. Uji gagal menurunkan skor dan membuka item remediasi.
Catatan tindak lanjut
Setiap kondisi wajib mencantumkan bukti yang belum tersedia, owner pemasok, owner buyer, tanggal target, dan cara verifikasi. Jangan tutup kondisi hanya karena pemasok menjawab lewat email. Verifikasi dapat berupa dokumen terkini, demonstrasi terbatas, rekam retest, atau konfirmasi kontrak dari fungsi berwenang. Bila target lewat, eskalasi keputusan kepada owner risiko, bukan kepada responder kuesioner.
Penutupan persetujuan bersyarat
Untuk API jadwal, vendor manager mencatat kondisi VND-22: runbook exit harus menunjukkan jalur penghapusan data tenant, penyetuju, tanggal target, dan metode validasi. Pada tindak lanjut, pemasok memberi bukti penghapusan tersamarkan untuk tenant sintetis; buyer memverifikasi identifier, batas layanan, tanggal, dan tanda tangan berwenang. Bila hanya teks kebijakan diterima, skor tetap 1 dan kondisi persetujuan terbuka. Kondisi kedaluwarsa memicu keputusan owner untuk memperpanjang dengan risiko terdokumentasi atau menghentikan onboarding; responder kuesioner tidak dapat menutupnya sendiri.
Siklus review
Perbarui jawaban saat scope layanan, aliran data, hosting, akses istimewa, subprosesor, insiden material, atau ketentuan kontrak berubah. Minimal, vendor manager mencatat tanggal review berikut, usia bukti, dan aksi terbuka. Skor tanpa tanggal belum siap untuk keputusan.
Batas keputusan
Legal, privacy, procurement, dan owner layanan harus mereview kewajiban masing-masing sebelum kontrak. Kuesioner ini hanya menghasilkan rekam due diligence yang dapat ditelusuri. Kuesioner ini tidak menjanjikan kepatuhan regulasi, hasil keamanan, sertifikasi, ketersediaan layanan, atau pengalihan risiko buyer.
Perubahan setelah penilaian
Keputusan pemasok harus ditinjau kembali ketika bukti kedaluwarsa atau layanan berubah secara material. Pengelola pemasok membandingkan batas layanan baru dengan jawaban, bukti, dan pengecualian sebelumnya, lalu membuka kembali hanya bagian yang terdampak. Catatan keputusan harus menunjukkan apakah risiko baru diterima, dimitigasi, atau menyebabkan penghentian proses pengadaan.
Sumber
Validasi penutupan pemasok
Untuk penyedia identitas terkelola, catat cakupan layanan, subprosesor, versi bukti, serta kondisi VND-22 yang masih terbuka. Peninjau membandingkan jawaban pemasok dengan konfigurasi atau artefak tersamarkan, lalu memastikan kontrol kompensasi dan tenggat remediasi masih berlaku. Perubahan pada data, akses istimewa, atau subprosesor membuka kembali penilaian; pengisi kuesioner tidak dapat menutup risiko atas namanya sendiri.