Klausa 6 menuntut informasi terdokumentasi lebih banyak daripada klausa mana pun. Sebagian besar temuan audit berakar di sini — bukan karena organisasi tidak menilai risiko, tetapi karena prosesnya tidak konsisten, tidak tertelusur ke konteks, atau SoA-nya tidak sinkron dengan hasil penanganan risiko.
6.1.1 Umum
Sering dikira duplikat 6.1.2. Bedanya: 6.1.1 tentang risiko dan peluang bagi SMKI sebagai sistem, sedangkan 6.1.2 tentang risiko keamanan informasi terhadap kerahasiaan, integritas, dan ketersediaan.
Apa yang diminta standar
- NORMATIFMempertimbangkan isu dari 4.1 dan persyaratan dari 4.2 saat merencanakan SMKI.
- NORMATIFMenentukan risiko dan peluang yang perlu ditangani untuk: memastikan SMKI mencapai manfaat yang diharapkan; mencegah atau mengurangi efek yang tidak diinginkan; dan mencapai peningkatan berkelanjutan.
- NORMATIFMerencanakan tindakan untuk menangani risiko dan peluang tersebut.
- NORMATIFMerencanakan cara mengintegrasikan dan menerapkan tindakan itu ke dalam proses SMKI, serta cara mengevaluasi efektivitasnya.
- PRAKTIK BAIKMenautkan tiap risiko dan peluang ke isu 4.1 atau persyaratan 4.2 yang menjadi sumbernya, agar jejaknya terlihat saat audit.
Keluaran & bukti
| Bentuk bukti | Contoh nyata | Wajib terdokumentasi |
|---|---|---|
| Register risiko & peluang SMKI | Daftar risiko tingkat sistem manajemen + tindakan + rencana evaluasi efektivitas | Tidak eksplisit — tetapi wajib bisa ditunjukkan |
| Jejak ke konteks | Rujukan tiap entri ke isu 4.1 atau persyaratan 4.2 | Praktik baik |
| Rencana evaluasi efektivitas | Cara menilai apakah tindakan berhasil | Wajib ditentukan |
Yang ditanyakan auditor
Auditor memakai 6.1.1 untuk menguji apakah Klausa 4 dikerjakan sungguhan. Pertanyaannya hampir selalu tentang asal-usul.
“Dari mana risiko ini berasal?”
Mengapa ditanya: Jawaban yang baik menunjuk isu atau persyaratan tertentu di Klausa 4. Risiko yang muncul entah dari mana menandakan konteks tidak dipakai.
“Apa bedanya daftar ini dengan register risiko keamanan informasi Anda?”
Mengapa ditanya: Menguji pemahaman bahwa 6.1.1 dan 6.1.2 berbeda tingkat.
“Bagaimana Anda tahu tindakan ini efektif?”
Mengapa ditanya: Butir (e)(2) yang eksplisit disebut standar dan paling sering dilewati.
Kesalahan yang sering terjadi
Menyalin isi register risiko keamanan informasi
6.1.1 lalu jadi duplikat 6.1.2, dan risiko tingkat sistem manajemen tidak pernah dinilai.
Peluang diabaikan
Standar menyebut risiko DAN peluang; kebanyakan organisasi hanya mengisi risikonya.
Tidak ada rencana evaluasi
Tindakan direncanakan, tetapi tidak pernah ditentukan bagaimana keberhasilannya diukur.
6.1.2 Asesmen risiko keamanan informasi
Yang diminta bukan hasil asesmennya saja, melainkan prosesnya — dan proses itu harus menghasilkan hasil yang konsisten bila diulang.
Apa yang diminta standar
persyaratan normatif
+ 1 catatan
Menyiapkan dasar
- Kriteria risikoNORMATIF
Menetapkan dan memelihara kriteria risiko keamanan informasi, mencakup kriteria akseptasi risiko dan kriteria untuk melakukan asesmen.
- Konsistensi hasilNORMATIF
Memastikan asesmen yang berulang memberikan hasil yang konsisten, valid, dan dapat dibandingkan.
Menjalankan asesmen
- Identifikasi risiko CIANORMATIF
Mengidentifikasi risiko yang terkait dengan hilangnya kerahasiaan, integritas, dan ketersediaan informasi dalam ruang lingkup SMKI.
- Pemilik risikoNORMATIF
Mengidentifikasi pemilik risiko.
- Analisis risikoNORMATIF
Menganalisis risiko: menilai konsekuensi potensial, menilai kemungkinan realistis terjadinya, dan menentukan level risiko.
- Evaluasi & prioritasNORMATIF
Mengevaluasi risiko: membandingkan hasil analisis dengan kriteria yang ditetapkan, lalu memprioritaskan risiko untuk penanganan.
Membuktikan
- Informasi terdokumentasiNORMATIF
Menyimpan informasi terdokumentasi tentang proses asesmen risiko keamanan informasi.
- Keselarasan ISO 31000CATATAN
Proses asesmen dan penanganan risiko dalam standar ini selaras dengan prinsip dan pedoman ISO 31000.
Tujuh butir pertama wajib dipenuhi. Urutannya bukan sekadar penomoran — kriteria harus ada sebelum risiko dinilai, dan risiko harus dianalisis sebelum bisa dievaluasi terhadap kriteria itu.
Keluaran & bukti
| Bentuk bukti | Contoh nyata | Wajib terdokumentasi |
|---|---|---|
| Metodologi asesmen risiko | Dokumen berisi skala dampak, skala kemungkinan, cara menghitung level risiko, dan ambang penerimaan | Ya — normatif |
| Register risiko keamanan informasi | Risiko CIA + pemilik + konsekuensi + kemungkinan + level + prioritas | Wajib sebagai hasil penerapan proses |
| Kriteria akseptasi risiko | Ambang yang menentukan risiko diterima atau harus ditangani | Ya — bagian dari metodologi |
| Penetapan pemilik risiko | Nama atau jabatan per risiko, bukan nama unit | Wajib ada |
Yang ditanyakan auditor
Uji paling tajam di 6.1.2 adalah konsistensi: apakah dua orang yang menilai risiko yang sama akan sampai pada level yang sama.
“Tunjukkan metodologi asesmen risiko Anda. Bagaimana level risiko dihitung?”
Mengapa ditanya: Menguji apakah kriteria benar-benar terdefinisi, bukan penilaian intuitif.
“Bagaimana Anda memastikan asesmen yang diulang tahun depan menghasilkan angka yang sebanding?”
Mengapa ditanya: Butir (b) yang eksplisit dan sering terlewat.
“Siapa pemilik risiko ini, dan apakah dia tahu?”
Mengapa ditanya: Pemilik risiko harus orang atau jabatan yang berwenang menerima risiko, bukan sekadar nama unit.
“Berapa ambang penerimaan risiko Anda, dan siapa yang menetapkannya?”
Mengapa ditanya: Ambang yang tidak pernah ditetapkan membuat seluruh evaluasi risiko tidak bermakna.
Kesalahan yang sering terjadi
Level risiko tanpa metodologi
Angka muncul tanpa definisi skala; auditor tidak bisa memverifikasi dan penilaian dianggap sewenang-wenang.
Pemilik risiko diisi nama unit
“Divisi TI” tidak bisa menerima risiko; yang diminta adalah orang atau jabatan yang berwenang.
Risiko bukan risiko CIA
Register berisi risiko bisnis umum, bukan risiko terhadap kerahasiaan, integritas, dan ketersediaan informasi.
Asesmen sekali seumur hidup
Dibuat menjelang sertifikasi lalu tidak pernah diulang, sehingga butir konsistensi tidak pernah teruji.
6.1.3 Penanganan risiko keamanan informasi
Di sinilah Statement of Applicability lahir — dan urutannya penting. SoA adalah keluaran dari penanganan risiko, bukan dokumen yang disusun lebih dulu lalu dicocokkan belakangan.
Apa yang diminta standar
persyaratan normatif
+ 1 catatan
Memilih penanganan
- Opsi penangananNORMATIF
Memilih opsi penanganan risiko yang tepat dengan mempertimbangkan hasil asesmen risiko.
- Menentukan kontrolNORMATIF
Menentukan semua kontrol yang diperlukan untuk menerapkan opsi penanganan yang dipilih.
Menguji terhadap Lampiran A
- Bandingkan Lampiran ANORMATIF
Membandingkan kontrol yang ditentukan dengan kontrol pada Lampiran A, dan memverifikasi bahwa tidak ada kontrol yang diperlukan terlewat.
- Pernyataan Aplikabilitas (SoA)NORMATIF
Menghasilkan Pernyataan Aplikabilitas yang memuat: kontrol yang diperlukan, justifikasi inklusinya, status penerapannya, serta justifikasi pengecualian kontrol Lampiran A.
- Sumber kontrolCATATAN
Organisasi dapat mendesain kontrol sendiri atau mengambil dari sumber mana pun; Lampiran A bukan daftar yang menyeluruh dan kontrol lain boleh ditambahkan.
Merencanakan & menyetujui
- Rencana penanganan risikoNORMATIF
Memformulasikan rencana penanganan risiko.
- Persetujuan pemilik risikoNORMATIF
Memperoleh persetujuan pemilik risiko atas rencana penanganan dan penerimaan risiko residual.
- Informasi terdokumentasiNORMATIF
Menyimpan informasi terdokumentasi tentang proses penanganan risiko.
Urutan inilah yang paling sering terbalik di lapangan. SoA lahir setelah kontrol ditentukan dari hasil asesmen risiko — bukan disusun lebih dulu lalu dicocokkan belakangan.
Keluaran & bukti
| Bentuk bukti | Contoh nyata | Wajib terdokumentasi |
|---|---|---|
| Rencana Penanganan Risiko (RTP) | Risiko + opsi penanganan + kontrol + penanggung jawab + tenggat + risiko residual | Ya — normatif |
| Statement of Applicability (SoA) | Seluruh kontrol Lampiran A + status berlaku/tidak + justifikasi inklusi + justifikasi eksklusi + status penerapan | Ya — normatif |
| Persetujuan pemilik risiko | Tanda tangan atau persetujuan tercatat atas RTP dan penerimaan risiko residual | Ya — normatif |
| Proses penanganan risiko | Dokumen yang menjelaskan tahapan penanganan | Ya — normatif |
Yang ditanyakan auditor
SoA adalah dokumen yang paling sering diperiksa baris per baris. Auditor mencocokkannya dengan RTP dan dengan kenyataan di lapangan.
“Tunjukkan SoA Anda. Mengapa kontrol ini dinyatakan berlaku?”
Mengapa ditanya: Justifikasi inklusi harus merujuk risiko tertentu, bukan alasan umum seperti 'praktik baik'.
“Mengapa kontrol ini dikecualikan?”
Mengapa ditanya: Justifikasi eksklusi wajib ada untuk setiap kontrol Lampiran A yang tidak dipakai — ini butir yang eksplisit.
“SoA menyatakan kontrol ini sudah diterapkan. Tunjukkan buktinya.”
Mengapa ditanya: Status penerapan yang tidak sesuai kenyataan adalah temuan serius.
“Siapa yang menyetujui penerimaan risiko residual ini?”
Mengapa ditanya: Persetujuan pemilik risiko bersifat wajib, bukan formalitas.
Kesalahan yang sering terjadi
SoA disusun lebih dulu
Kontrol dipilih dari daftar Lampiran A tanpa melalui asesmen risiko, sehingga justifikasi inklusinya kosong atau mengada-ada.
Justifikasi eksklusi tidak ada
Kontrol ditandai tidak berlaku tanpa alasan — pelanggaran langsung butir (d).
SoA tidak sinkron dengan RTP
Kontrol muncul di SoA tetapi tidak ada di rencana penanganan, atau sebaliknya.
Risiko residual tidak dihitung
Penanganan direncanakan, tetapi sisa risikonya tidak dinilai dan tidak disetujui siapa pun.
Mencampur pengecualian kontrol dengan pengecualian ruang lingkup
Menyatakan kontrol Lampiran A tidak berlaku adalah 6.1.3; membatasi cakupan organisasi adalah 4.3.
6.2 Sasaran keamanan informasi dan perencanaan untuk mencapainya
Sasaran yang baik lahir dari hasil asesmen risiko. Sasaran yang disusun tanpa melihat risiko biasanya berbunyi bagus tetapi tidak berhubungan dengan apa pun.
Apa yang diminta standar
- NORMATIFMenetapkan sasaran keamanan informasi pada fungsi dan level yang relevan.
- NORMATIFSasaran harus konsisten dengan kebijakan keamanan informasi.
- NORMATIFSasaran harus dapat diukur, jika dapat dipraktikkan.
- NORMATIFSasaran harus mempertimbangkan persyaratan keamanan informasi yang berlaku serta hasil asesmen dan penanganan risiko.
- NORMATIFSasaran harus dipantau, dikomunikasikan, dan dimutakhirkan dengan tepat.
- NORMATIFSasaran harus tersedia sebagai informasi terdokumentasi.
- NORMATIFDalam merencanakan pencapaiannya, organisasi menentukan: apa yang akan dilakukan, sumber daya yang diperlukan, siapa yang bertanggung jawab, kapan diselesaikan, dan bagaimana hasilnya dievaluasi.
Keluaran & bukti
| Bentuk bukti | Contoh nyata | Wajib terdokumentasi |
|---|---|---|
| Dokumen Sasaran Keamanan Informasi | Daftar sasaran + indikator + target + fungsi/level | Ya — normatif |
| Rencana pencapaian | Kolom tindakan, sumber daya, penanggung jawab, tenggat, dan cara evaluasi untuk tiap sasaran | Ya — kelimanya wajib ditentukan |
| Bukti pemantauan | Catatan pengukuran berkala terhadap sasaran | Terhubung ke 9.1 |
| Bukti komunikasi | Sosialisasi sasaran ke fungsi terkait | Bentuk bebas |
Yang ditanyakan auditor
Auditor menguji kelima unsur rencana pencapaian satu per satu. Sasaran tanpa penanggung jawab dan tenggat dianggap belum direncanakan.
“Tunjukkan sasaran keamanan informasi Anda. Bagaimana mengukurnya?”
Mengapa ditanya: Sasaran seperti 'meningkatkan keamanan' tidak dapat diukur dan akan dipertanyakan.
“Sasaran ini berasal dari risiko yang mana?”
Mengapa ditanya: Butir (c) mensyaratkan sasaran mempertimbangkan hasil asesmen dan penanganan risiko.
“Siapa bertanggung jawab atas sasaran ini, kapan tenggatnya, dan bagaimana hasilnya dievaluasi?”
Mengapa ditanya: Tiga dari lima unsur perencanaan yang paling sering kosong.
Kesalahan yang sering terjadi
Sasaran tidak terukur
'Meningkatkan kesadaran karyawan' tanpa indikator dan target.
Tidak terhubung ke risiko
Sasaran disusun terpisah, padahal standar meminta hasil asesmen risiko dipertimbangkan.
Rencana pencapaian kosong
Sasaran ada, tetapi tidak ada tindakan, sumber daya, penanggung jawab, tenggat, maupun cara evaluasi.
Tidak pernah dipantau
Ditetapkan di awal tahun lalu tidak pernah diukur sampai audit tiba.
6.3 Perencanaan perubahan
Klausa terpendek di seluruh standar — satu kalimat. Tetapi ia sering jadi temuan karena tidak ada yang menyiapkan buktinya.
Apa yang diminta standar
- NORMATIFKetika organisasi menentukan adanya kebutuhan perubahan pada SMKI, perubahan tersebut harus dilakukan dengan cara yang terencana.
- PRAKTIK BAIKMencatat perubahan SMKI beserta alasan, dampak, persetujuan, dan tanggal berlakunya.
- PRAKTIK BAIKMeninjau apakah perubahan berdampak pada ruang lingkup, asesmen risiko, atau SoA.
Keluaran & bukti
| Bentuk bukti | Contoh nyata | Wajib terdokumentasi |
|---|---|---|
| Catatan perubahan SMKI | Daftar perubahan + alasan + dampak + penyetuju + tanggal | Tidak eksplisit — tetapi wajib bisa ditunjukkan |
| Bukti perencanaan | Dokumen yang menunjukkan perubahan dipertimbangkan sebelum dijalankan, bukan sesudahnya | Wajib bisa ditunjukkan |
Yang ditanyakan auditor
6.3 baru muncul di versi 2022. Banyak organisasi belum menyiapkan buktinya karena mengira klausa sependek ini tidak diperiksa.
“Perubahan apa saja yang terjadi pada SMKI Anda tahun ini?”
Mengapa ditanya: Menguji apakah perubahan dicatat sama sekali.
“Bagaimana perubahan itu direncanakan sebelum dijalankan?”
Mengapa ditanya: Kata kuncinya 'terencana' — perubahan mendadak tanpa pertimbangan dampak adalah temuan.
“Apakah perubahan itu memengaruhi ruang lingkup atau SoA Anda?”
Mengapa ditanya: Menguji apakah dampak perubahan ditelusuri ke dokumen lain.
Kesalahan yang sering terjadi
Tidak ada catatan perubahan sama sekali
Klausa dianggap terlalu pendek untuk diperiksa.
Perubahan dilakukan lalu didokumentasikan
Kebalikan dari 'terencana'.
Dampak tidak ditelusuri
Ruang lingkup berubah tetapi SoA dan asesmen risiko tidak ikut ditinjau.
Checklist kesiapan
Daftar periksa cepat sebelum audit — bersifat panduan, tidak tersimpan.
- Risiko dan peluang tingkat SMKI (6.1.1) terpisah dari register risiko keamanan informasi, dan dapat ditelusuri ke isu 4.1 atau persyaratan 4.2.
- Metodologi asesmen risiko terdokumentasi: skala dampak, skala kemungkinan, cara menghitung level, dan ambang penerimaan.
- Setiap risiko punya pemilik berupa orang atau jabatan, bukan nama unit.
- Asesmen risiko dapat diulang dan menghasilkan angka yang sebanding.
- Rencana Penanganan Risiko lengkap dengan kontrol, penanggung jawab, tenggat, dan risiko residual.
- Statement of Applicability memuat justifikasi inklusi, status penerapan, dan justifikasi eksklusi untuk seluruh kontrol Lampiran A.
- SoA sinkron dengan RTP — tidak ada kontrol yang muncul di satu dokumen tetapi hilang di dokumen lain.
- Pemilik risiko menyetujui RTP dan menerima risiko residual secara tercatat.
- Sasaran keamanan informasi terukur dan mempertimbangkan hasil asesmen risiko.
- Tiap sasaran punya tindakan, sumber daya, penanggung jawab, tenggat, dan cara evaluasi.
- Perubahan SMKI dicatat dan dilakukan secara terencana.