Penilaian dan penanganan risiko untuk ISO 27001

Mulai dari keputusan yang ingin dibuat

Penilaian risiko membantu menentukan apa yang perlu ditangani, oleh siapa, dan dengan bukti apa. Dalam sistem manajemen keamanan informasi (SMKI), hubungkan penilaian dengan layanan yang benar-benar masuk lingkup. Daftar panjang kelemahan tanpa keputusan belum cukup untuk membagi pekerjaan.

ISO 27005 membahas pengelolaan risiko untuk mendukung SMKI. Langkah dan contoh di halaman ini adalah bantuan kerja Kompli, bukan metode penilaian wajib atau pemeriksaan seluruh klausul ISO 27001. Cocokkan pekerjaan tim dengan naskah standar yang digunakan.

Sepakati lingkup dan kriteria sebelum memberi nilai

Catat layanan, proses, data, pihak yang bergantung pada layanan, serta periode penilaian. Sertakan pengembangan, dukungan dan vendor bila memengaruhi layanan tersebut. Pilih orang yang memahami pekerjaan dan orang yang berwenang mengambil keputusan.

Sepakati arti kemungkinan dan dampak. Kategori rendah, sedang, dan tinggi dapat digunakan jika tim memahami perbedaannya. Jangan mengalikan angka yang tidak punya dasar lalu menyebut hasilnya ukuran risiko yang pasti.

Contoh kriteria fiktif untuk aplikasi penggajian:

• Dampak tinggi: dapat membuka data gaji pihak lain atau menghentikan proses penggajian pada waktu kritis.
• Kemungkinan tinggi: jalur akses tersedia dan belum ada pengamanan yang terbukti mencegah kejadian pada kondisi yang dibahas.
• Penanganan: keputusan untuk risiko tinggi dibawa kepada pemilik layanan; tim menetapkan tindakan sementara, perbaikan, dan batas waktunya.

Kriteria itu milik contoh, bukan ambang ISO atau aturan untuk semua perusahaan. Catat juga ketidakpastian, misalnya log yang belum lengkap atau sistem yang belum diperiksa.

Tulis skenario, bukan hanya nama ancaman

Gunakan satu skenario per catatan. Jelaskan penyebab, kejadian yang mungkin timbul, dan akibatnya. “Akun berisiko” belum menunjukkan pekerjaan; “akses pegawai keluar masih aktif karena perubahan status HR tidak diteruskan ke aplikasi” lebih mudah diperiksa.

Bandingkan dengan daftar risiko keamanan. Catat pengamanan yang sudah berjalan beserta bukti; rencana memasang MFA bulan depan belum menjadi kontrol saat ini.

Contoh: pilih tindakan dan periksa hasilnya

Skenario fiktif: aplikasi penggajian memakai akun pegawai yang terpisah dari sistem HR. Catatan perubahan pegawai diteruskan secara manual.

Bagian	Keputusan contoh
Risiko R-01	Pegawai keluar masih dapat membaca data gaji karena akunnya belum ditutup.
Bukti awal	Daftar perubahan HR tidak memiliki catatan pencabutan pada aplikasi; log perlu diperiksa.
Tindakan segera	Tutup akses yang sudah tidak berwenang dan periksa sesi aktif melalui petugas yang ditunjuk.
Perbaikan proses	HR mengirim pemberitahuan; IT mencabut akses; pemilik aplikasi memeriksa hasil dan pengecualian.
Bukti keberhasilan	Tiket pencabutan dan uji akun buatan yang ditolak setelah statusnya dinonaktifkan.
Risiko tersisa	Kesalahan pemberitahuan manual masih mungkin terjadi; pemilik layanan menetapkan pemeriksaan tambahan dan meninjau rencana otomatisasi.

Tindakan dapat mengurangi risiko, menghindari kegiatan yang menimbulkannya, membagi sebagian dampak melalui pengaturan yang sesuai, atau menerima risiko dengan alasan. Kontrak dengan vendor tidak otomatis menghapus risiko pada layanan maupun tanggung jawab perusahaan.

Bedakan rencana selesai dengan risiko ditinjau

Tiket yang ditutup hanya membuktikan status pekerjaan pada sistem tiket. Periksa apakah tindakan menghasilkan perubahan yang diharapkan. Catat tanggal, hasil, keterbatasan dan pihak yang memeriksa.

Risiko tersisa harus dijelaskan kepada pemilik keputusan. Jika diterima, tuliskan alasan, wewenang penerima, batas penerimaan dan pemicu peninjauan. Bila bukti belum ada, statusnya tetap belum diperiksa; jangan menurunkan kategori hanya karena pekerjaan sudah dijadwalkan.

Perbarui saat kondisi berubah

Tinjau ulang setelah fitur, pemasok, alur data, lingkup atau ancaman berubah, serta setelah insiden dan temuan pemeriksaan. Simpan versi kriteria agar penilaian lama dan baru dapat dibandingkan dengan masuk akal.

Hubungkan keputusan pengamanan dengan Statement of Applicability. Bukti penerapannya kemudian digunakan pada audit internal dan pembahasan pimpinan.

Contoh tambahan: perubahan lingkup mengubah keputusan

Skenario fiktif: aplikasi penggajian yang semula hanya memiliki panel web menambah API ekspor untuk pelanggan. Keputusan risiko lama hanya mencakup panel dan satu kelompok akun; hasil itu belum menjawab akses melalui API.

Pemilik layanan menambahkan jalur ekspor dan akun integrasi ke lingkup, meninjau kemungkinan akses lintas pelanggan, lalu meminta bukti penolakan serta akses yang sah. Jika hasil API belum tersedia, keputusan peluncuran tetap mencatat ketidakpastian itu. Kriteria risiko dan wewenang penerimaan mengikuti pengaturan organisasi, bukan skor universal dari contoh.

Gunakan penilaian kontrol NIST untuk merancang pemeriksaan terpilih. Hasilnya menjadi masukan penilaian risiko; satu uji yang berhasil tidak menghapus skenario pemulihan, kesalahan operator atau bagian lain yang belum diperiksa.