Dalam penerapan ISO 27001, perusahaan tidak hanya perlu memiliki kebijakan keamanan informasi, tetapi juga harus menentukan kontrol keamanan yang sesuai dengan risiko yang dihadapi. Salah satu dokumen penting yang digunakan dalam proses ini adalah SOA atau Statement of Applicability.
SOA menjadi bagian penting dalam pengelolaan keamanan informasi karena menunjukkan kontrol apa saja yang diperlukan oleh organisasi, alasan pemilihannya, serta status penerapannya. Dokumen ini juga membantu perusahaan menjelaskan alasan apabila kontrol tertentu dalam Annex A ISO 27001 dinyatakan tidak berlaku.
Lalu, apa itu SOA dalam ISO 27001, apa fungsinya, dan bagaimana cara membuatnya? Berikut penjelasan lengkapnya.
Apa Itu SOA dalam ISO 27001?
SOA adalah singkatan dari Statement of Applicability, yaitu dokumen yang mencatat kontrol keamanan informasi yang diperlukan organisasi, alasan pemilihannya, status penerapannya, serta alasan pengecualian kontrol Annex A yang dinilai tidak berlaku.
Dalam standar ISO/IEC 27001:2022, SOA berkaitan dengan persyaratan pengelolaan risiko keamanan informasi pada klausul 6.1.3, khususnya bagian d.
Dokumen ini disusun berdasarkan hasil penilaian risiko dan keputusan perlakuan risiko yang dilakukan organisasi. Artinya, kontrol keamanan tidak dipilih hanya karena tercantum dalam standar, tetapi harus mempertimbangkan kebutuhan bisnis, risiko, kewajiban hukum, dan kondisi operasional perusahaan.
Sebagai contoh, perusahaan yang mengelola data pelanggan secara digital mungkin membutuhkan kontrol untuk membatasi akses pengguna, melakukan pencadangan data, mengelola insiden keamanan, dan melindungi informasi dari akses yang tidak sah.
Kontrol tersebut kemudian dicatat dalam SOA beserta alasan pemilihannya dan status implementasinya.
Dengan demikian, SOA ISO 27001 merupakan dokumen yang menjelaskan kontrol keamanan informasi yang dipilih organisasi, alasan pemilihannya, dan bagaimana penerapannya dikelola.
Apa Fungsi SOA dalam ISO 27001?
SOA bukan sekadar dokumen administratif. Dokumen ini membantu organisasi memastikan bahwa keputusan mengenai kontrol keamanan informasi dapat dijelaskan dan ditelusuri.
Berikut beberapa fungsi utama SOA.
1. Menentukan kontrol keamanan informasi
SOA membantu organisasi mendokumentasikan kontrol yang diperlukan berdasarkan hasil penilaian dan perlakuan risiko.
Kontrol tersebut dapat berasal dari Annex A ISO 27001 maupun sumber lain yang relevan, termasuk kontrol tambahan yang dirancang sendiri oleh organisasi.
2. Menjelaskan alasan pemilihan kontrol
Setiap kontrol yang dipilih perlu memiliki alasan yang jelas. Misalnya, kontrol pengelolaan hak akses diperlukan karena perusahaan menangani informasi rahasia yang hanya boleh diakses oleh personel tertentu.
Alasan ini membantu memastikan bahwa keputusan keamanan informasi didasarkan pada kebutuhan nyata.
3. Mencatat status implementasi
SOA menunjukkan apakah kontrol yang diperlukan sudah diterapkan atau belum.
Informasi ini memudahkan tim keamanan informasi, manajemen, dan auditor memahami perkembangan penerapan kontrol di perusahaan.
4. Menjelaskan pengecualian kontrol Annex A
Tidak semua kontrol referensi Annex A harus diterapkan secara otomatis pada setiap organisasi. Namun, organisasi tetap perlu mengevaluasi kontrol tersebut dan memberikan alasan yang dapat dipertanggungjawabkan apabila suatu kontrol dinyatakan tidak berlaku.
Pengecualian tidak boleh hanya didasarkan pada alasan bahwa kontrol tersebut sulit diterapkan atau membutuhkan biaya.
5. Mendukung proses audit ISO 27001
Auditor dapat menggunakan SOA untuk memahami hubungan antara penilaian risiko, keputusan perlakuan risiko, dan penerapan kontrol keamanan informasi.
Informasi dalam SOA juga perlu didukung oleh bukti yang sesuai, seperti kebijakan, prosedur, konfigurasi sistem, atau catatan pelaksanaan kontrol.
Apa Hubungan SOA dengan Annex A ISO 27001?
Annex A ISO/IEC 27001:2022 merupakan referensi kontrol keamanan informasi yang digunakan dalam proses perlakuan risiko.
Pada versi 2022, Annex A memuat 93 kontrol yang dikelompokkan ke dalam empat kategori utama.
1. Organizational Controls
Kelompok ini mencakup kontrol organisasi, seperti kebijakan keamanan informasi, pembagian tanggung jawab, pengelolaan pemasok, dan penanganan insiden.
2. People Controls
Kelompok ini berhubungan dengan aspek manusia, seperti pemeriksaan personel, kesadaran keamanan informasi, dan tanggung jawab karyawan.
3. Physical Controls
Kelompok ini berkaitan dengan perlindungan fisik, seperti pengamanan area kerja, akses ke fasilitas, serta perlindungan perangkat dan aset fisik.
4. Technological Controls
Kelompok ini mencakup kontrol teknologi, seperti pengelolaan hak akses, pencadangan data, pencatatan aktivitas, penggunaan kriptografi, dan keamanan sistem.
SOA membantu organisasi mendokumentasikan kontrol yang diperlukan berdasarkan hasil penilaian risiko serta membandingkannya dengan kontrol referensi Annex A agar tidak ada kontrol penting yang terlewat.
Perlu dipahami bahwa Annex A bukan daftar kontrol yang harus diterapkan seluruhnya tanpa mempertimbangkan konteks organisasi. Organisasi menentukan kontrol yang diperlukan berdasarkan proses perlakuan risiko dan harus memberikan justifikasi yang sesuai terhadap kontrol Annex A yang dikecualikan.
Apa Saja Isi Dokumen SOA ISO 27001?
ISO/IEC 27001:2022 klausul 6.1.3 d menetapkan empat hal utama yang harus tercakup dalam SOA, yaitu:
- Kontrol yang diperlukan organisasi.
- Justifikasi pemilihan kontrol tersebut.
- Status implementasi kontrol yang diperlukan.
- Justifikasi pengecualian kontrol dari Annex A.
Dalam praktiknya, organisasi dapat menambahkan beberapa kolom agar dokumen lebih mudah dikelola dan ditinjau.
Contoh struktur SOA yang dapat digunakan adalah sebagai berikut.
| ID Kontrol | Nama Kontrol | Status Berlaku | Justifikasi | Status Implementasi |
|---|---|---|---|---|
| A.5.1 | Kebijakan keamanan informasi | Berlaku | Diperlukan untuk menetapkan arahan dan tanggung jawab keamanan informasi | Sudah diterapkan |
| A.5.15 | Pengendalian akses | Berlaku | Diperlukan untuk membatasi akses ke sistem dan informasi | Dalam proses |
| A.8.13 | Pencadangan informasi | Berlaku | Diperlukan untuk mendukung pemulihan data ketika terjadi kehilangan atau kerusakan | Sudah diterapkan |
| A.7.4 | Pemantauan keamanan fisik | Perlu evaluasi | Penetapan status harus mempertimbangkan fasilitas, risiko, dan pengamanan yang digunakan | Belum ditentukan |
Tabel tersebut hanya contoh struktur dokumentasi, bukan SOA siap audit. Penetapan status dan justifikasi setiap kontrol harus disesuaikan dengan kondisi organisasi yang sebenarnya.
Dokumen SOA tidak diwajibkan menggunakan format tabel tertentu. Organisasi dapat menggunakan spreadsheet, dokumen, atau perangkat lunak pengelolaan keamanan informasi, selama seluruh persyaratan yang relevan terpenuhi.
Bagaimana Cara Membuat SOA ISO 27001?
Penyusunan SOA sebaiknya dilakukan setelah organisasi memahami konteks bisnis, ruang lingkup ISMS, dan risiko keamanan informasi yang dihadapi.
Berikut langkah-langkah yang dapat digunakan sebagai panduan.
1. Tentukan ruang lingkup ISMS
Tentukan bagian organisasi, proses bisnis, lokasi, sistem informasi, dan aset yang termasuk dalam ruang lingkup Sistem Manajemen Keamanan Informasi atau ISMS.
Ruang lingkup ini akan memengaruhi risiko yang dinilai dan kontrol yang diperlukan.
2. Lakukan penilaian risiko keamanan informasi
Identifikasi aset informasi, ancaman, kerentanan, serta kemungkinan dampak apabila terjadi insiden keamanan informasi.
Contohnya, perusahaan dapat mengidentifikasi risiko kebocoran data pelanggan akibat akses yang tidak sesuai atau risiko kehilangan data karena pencadangan tidak memadai.
3. Tentukan perlakuan risiko
Setelah risiko dianalisis, organisasi menentukan cara menanganinya sesuai kriteria risiko yang telah ditetapkan.
Keputusan ini menjadi dasar dalam menentukan kontrol yang diperlukan. Kontrol dapat diambil dari Annex A atau sumber lain yang relevan.
4. Bandingkan kontrol yang diperlukan dengan Annex A
Periksa apakah kontrol yang ditentukan dalam proses perlakuan risiko sudah tercakup dalam Annex A.
Tujuannya adalah memastikan tidak ada kontrol yang diperlukan terlewat. Jika risiko tertentu membutuhkan kontrol tambahan di luar Annex A, organisasi dapat memasukkannya sebagai kontrol tambahan.
5. Dokumentasikan SOA
Catat kontrol yang diperlukan, alasan pemilihannya, status implementasi, dan alasan pengecualian kontrol Annex A yang dinyatakan tidak berlaku.
Pastikan alasan yang ditulis spesifik dan sesuai dengan kondisi organisasi, bukan sekadar menggunakan pernyataan umum.
6. Pastikan implementasi didukung bukti
Kontrol yang berstatus sudah diterapkan harus memiliki bukti yang sesuai.
Contohnya dapat berupa kebijakan yang disetujui, daftar hak akses, catatan pencadangan, hasil pengujian pemulihan, atau bukti pelaksanaan pelatihan keamanan informasi.
7. Tinjau dan perbarui SOA
SOA perlu ditinjau ketika terdapat perubahan penting, seperti perubahan sistem, proses bisnis, ruang lingkup ISMS, kewajiban hukum, atau profil risiko.
Dengan pembaruan berkala, dokumen SOA tetap mencerminkan kondisi keamanan informasi yang sebenarnya.
Contoh Justifikasi SOA ISO 27001
Salah satu bagian yang sering membutuhkan perhatian adalah penulisan justifikasi kontrol. Alasan yang terlalu umum dapat menyulitkan organisasi saat menjelaskan keputusan tersebut dalam audit.
Berikut contoh sederhana.
Contoh 1: Kontrol pengendalian akses
Kontrol: A.5.15 — Access control.
Status: Berlaku.
Justifikasi: Organisasi mengelola sistem informasi yang berisi data internal dan data pelanggan. Pengendalian akses diperlukan untuk memastikan bahwa pengguna hanya dapat mengakses informasi sesuai tugas dan kewenangannya.
Status implementasi: Sudah diterapkan, jika didukung bukti yang memadai.
Contoh 2: Kontrol pencadangan informasi
Kontrol: A.8.13 — Information backup.
Status: Berlaku.
Justifikasi: Organisasi perlu menjaga ketersediaan dan kemampuan pemulihan data ketika terjadi kehilangan data, kerusakan sistem, atau gangguan operasional.
Status implementasi: Dalam proses, jika mekanisme pencadangan belum sepenuhnya memenuhi rencana yang ditetapkan.
Contoh 3: Kontrol yang dinyatakan tidak berlaku
Kontrol: Kontrol tertentu dari Annex A yang telah dievaluasi berdasarkan konteks organisasi.
Status: Tidak berlaku, hanya jika hasil evaluasi mendukung keputusan tersebut.
Justifikasi: Organisasi perlu menjelaskan secara spesifik mengapa kontrol tersebut tidak relevan terhadap ruang lingkup ISMS dan risiko yang dihadapi. Alasan harus mempertimbangkan proses bisnis, aset, teknologi, dan kewajiban yang berlaku.
Contoh ketiga sengaja tidak menetapkan ID kontrol tertentu karena status tidak berlaku tidak dapat diputuskan hanya berdasarkan nama kontrol. Keputusan tersebut harus didukung analisis kondisi organisasi yang sebenarnya.
Apa Kesalahan yang Sering Terjadi Saat Membuat SOA?
Ada beberapa kesalahan yang perlu dihindari agar dokumen SOA dapat digunakan secara efektif.
1. Menganggap seluruh kontrol Annex A wajib diterapkan tanpa evaluasi. Organisasi harus menentukan kontrol yang diperlukan berdasarkan proses perlakuan risiko dan mengevaluasi seluruh kontrol referensi Annex A.
2. Tidak memberikan alasan pemilihan kontrol. Setiap kontrol yang diperlukan harus memiliki justifikasi yang menjelaskan relevansinya bagi organisasi.
3. Mengecualikan kontrol tanpa alasan yang kuat. Status tidak berlaku harus didukung evaluasi yang dapat dijelaskan, bukan hanya karena kontrol dianggap merepotkan.
4. Menandai kontrol sudah diterapkan tanpa bukti. Status implementasi harus sesuai dengan keadaan nyata dan dapat diverifikasi.
5. Tidak memperbarui dokumen. Perubahan sistem, proses bisnis, atau risiko dapat membuat SOA lama tidak lagi sesuai dengan kondisi perusahaan.
Menghindari kesalahan tersebut membantu organisasi menjaga konsistensi antara dokumen, pelaksanaan kontrol, dan kebutuhan keamanan informasi.
Mengapa SOA Penting dalam Audit ISO 27001?
Dalam proses audit ISO 27001, SOA membantu auditor memahami bagaimana organisasi menentukan kontrol keamanan informasi dan menghubungkannya dengan hasil penilaian risiko.
Auditor dapat menelusuri apakah kontrol yang dinyatakan berlaku telah diterapkan sesuai rencana dan apakah keputusan pengecualian kontrol Annex A memiliki alasan yang dapat diterima.
Misalnya, apabila SOA menyatakan bahwa pencadangan data telah diterapkan, organisasi perlu menunjukkan bukti yang relevan. Bukti tersebut dapat berupa konfigurasi pencadangan, catatan keberhasilan proses, atau hasil pengujian pemulihan data.
Dengan demikian, SOA harus konsisten dengan kondisi operasional. Dokumen yang lengkap tetapi tidak sesuai dengan pelaksanaan sebenarnya tidak cukup untuk menunjukkan bahwa kontrol keamanan informasi telah berjalan efektif.
Kesimpulan
SOA atau Statement of Applicability merupakan dokumen penting dalam penerapan ISO 27001 karena menjelaskan kontrol keamanan informasi yang diperlukan organisasi, alasan pemilihannya, status implementasi, dan justifikasi pengecualian kontrol Annex A.
Penyusunannya harus didasarkan pada penilaian risiko dan keputusan perlakuan risiko, bukan sekadar menyalin daftar kontrol dari standar.
Dengan SOA yang jelas, konsisten, dan selalu diperbarui, organisasi dapat mengelola kontrol keamanan informasi secara lebih terstruktur sekaligus mempermudah penelusuran bukti dalam proses audit ISO 27001.
FAQ tentang SOA ISO 27001
1. Apa kepanjangan SOA dalam ISO 27001?
SOA adalah Statement of Applicability, yaitu dokumen yang menjelaskan kontrol keamanan informasi yang diperlukan, alasan pemilihannya, status implementasi, dan justifikasi pengecualian kontrol Annex A.
2. Apakah SOA wajib dalam ISO 27001?
Ya. ISO/IEC 27001:2022 klausul 6.1.3 d mensyaratkan organisasi menghasilkan Statement of Applicability sebagai bagian dari proses perlakuan risiko keamanan informasi.
3. Berapa jumlah kontrol dalam Annex A ISO 27001:2022?
Annex A ISO/IEC 27001:2022 berisi 93 kontrol yang dikelompokkan menjadi kontrol organisasi, manusia, fisik, dan teknologi.
4. Apakah semua kontrol Annex A harus diterapkan?
Tidak secara otomatis. Organisasi menentukan kontrol yang diperlukan berdasarkan proses perlakuan risiko dan harus mengevaluasi kontrol referensi Annex A agar tidak ada kontrol yang diperlukan terlewat. Pengecualian kontrol Annex A harus disertai justifikasi.
5. Apa perbedaan SOA dan risk assessment?
Risk assessment merupakan proses untuk mengidentifikasi, menganalisis, dan mengevaluasi risiko keamanan informasi. SOA mendokumentasikan kontrol yang diperlukan, alasan pemilihannya, status implementasi, dan justifikasi pengecualian kontrol Annex A.
6. Siapa yang bertanggung jawab membuat SOA?
Penyusunan SOA biasanya melibatkan tim keamanan informasi, pengelola ISMS, pemilik risiko, pemilik proses bisnis, dan pihak terkait lainnya. Tanggung jawab serta persetujuannya ditetapkan sesuai tata kelola organisasi.
7. Apakah tersedia template SOA ISO 27001?
Organisasi dapat menggunakan spreadsheet atau perangkat lunak untuk menyusun SOA. Tidak ada satu format tabel yang diwajibkan secara universal, tetapi isi dokumen harus memenuhi persyaratan klausul 6.1.3 d dan sesuai dengan kondisi organisasi.
Ingin mengurus sertifikasi ISO resmi tanpa ribet dan penuh kepastian?
Konsultasikan kebutuhan ISO perusahaan Anda sekarang dan dapatkan pendampingan profesional hingga sertifikat resmi terbit!
—
KONSULTASIKAN KEBUTUHAN ANDA,
HUBUNGI KAMI UNTUK INFORMASI & PEMESANAN
Website : PT Taf Multi Global
Telp kantor : +6282112139439
Google Maps : ANNEX BUILDING (Bina Sentra, MENARA BIDAKARA 2, Lantai 4) Kota Jakarta Selatan, Daerah Khusus Ibukota Jakarta 12870