ISO 27001/27002
Apa yang Bisa Dipelajari Developer dari ISO 27002
Juli 2026 · 4 menit baca
Ketika seorang developer yang belum pernah bekerja di dalam program compliance membuka katalog kontrol ISO 27002 untuk pertama kalinya, reaksinya biasanya sama: ini bukan untuk saya, ini dokumen yang akan diterjemahkan orang di departemen lain menjadi aturan yang pada akhirnya harus saya ikuti. Saya memahami reaksi itu, dan untuk sebagian besar katalognya, reaksi itu tidak sepenuhnya salah. Tetapi beberapa temanya menggambarkan kebiasaan yang sudah saya hargai sebagai engineer jauh sebelum saya tahu nama standar yang meresmikannya, dan begitu saya menyadari tumpang tindih itu, saya berhenti membaca katalognya sebagai birokrasi dan mulai membacanya sebagai daftar praktik yang layak diadopsi atas dasar nilainya sendiri.
Tumpang tindih itu bukan kebetulan. Standar yang dibangun untuk mengurangi risiko dalam cara organisasi menangani informasi pada akhirnya mengodekan banyak hal yang sudah dilakukan engineer berpengalaman karena kebiasaan — karena mode kegagalan yang sama (tidak ada yang memiliki ini, kita tidak bisa tahu apa yang terjadi, siapa saja bisa menyentuh apa saja) muncul terlepas dari ada atau tidaknya program compliance yang mengawasi. Membaca standar dengan cara ini tidak membutuhkan menjadi spesialis compliance, dan tidak membutuhkan mengutip teks kontrolnya; yang dibutuhkan hanyalah menyadari baris mana yang menggambarkan sesuatu yang akan Anda bangun juga meski tidak ada yang harus mensertifikasinya.
Tulisan ini membahas empat tumpang tindih itu — tema yang terbaca sebagai bahasa tata kelola di atas kertas, tetapi begitu direnungkan, berubah menjadi keputusan yang sudah dibuat developer setiap hari, entah sengaja atau tidak.
Ia bersikeras sesuatu harus dimiliki, bukan sekadar dibangun
Pola yang berulang di seluruh katalog adalah asumsi bahwa setiap aset, proses, dan kontrol punya pemilik yang bertanggung jawab — orang atau tim tertentu, bukan departemen, bukan "siapa pun yang dulu menulisnya". Tim engineering yang sudah mempraktikkan kepemilikan service yang jelas, rotasi on-call, dan code-owner yang ditentukan untuk modul kritis sebenarnya sudah menjalankan requirement ini tanpa pernah membuka standarnya. Pelajaran yang layak diambil, bahkan di luar program compliance, adalah betapa lebih lancarnya incident response dan pemeliharaan jangka panjang begitu setiap bagian penting sebuah sistem punya nama yang melekat padanya — bukan sebagai formalitas, melainkan perbedaan antara perbaikan cepat dan pencarian siapa saja yang masih ingat cara kerja hal itu.
Ia meminta Anda menentukan apa itu security-relevant event sebelum Anda membutuhkannya
Developer sudah terbiasa mencatat log — untuk debugging, untuk metrik, karena penasaran. Tema terkait logging dalam standar ini mendorong lebih jauh: tentukan sejak awal apa yang dianggap security-relevant event (perubahan izin, autentikasi yang gagal, ekspor data) sehingga ketika sesuatu terjadi salah, rekaman yang Anda butuhkan sudah tercatat dengan sengaja, bukan diselamatkan secara kebetulan dari apa pun yang kebetulan tercatat hari itu. Ini adalah disiplin yang benar-benar berguna, terlepas dari audit mana pun — alternatifnya, memutuskan setelah insiden apa yang seharusnya Anda catat, adalah cara yang jauh lebih buruk untuk mempelajari pelajaran yang sama.
Ia memperlakukan akses sebagai sesuatu yang Anda rancang, bukan sekadar diberikan
Developer secara naluriah tahu bahwa credential database seharusnya tidak dibagikan ke setiap service, tetapi standar ini memperluas insting itu menjadi pertanyaan desain penuh: siapa yang membutuhkan akses ini, seberapa lama, dan bagaimana ia dicabut ketika sudah tidak dibutuhkan lagi? Memperlakukan kontrol akses sebagai keputusan desain yang dibuat pada saat sebuah fitur dibangun — alih-alih pemberian akses luas demi kenyamanan yang tidak pernah ditinjau ulang — adalah salah satu kebiasaan paling murah untuk diadopsi sejak awal dan salah satu yang paling mahal untuk ditambal belakangan setelah puluhan service bergantung pada model akses yang tidak pernah sengaja dirancang siapa pun.
Ia mengharapkan sebuah perubahan meninggalkan jejak di belakangnya
Sebagian besar developer sudah bekerja di dalam alur pull request dengan semacam review. Yang ditambahkan standar ini adalah ekspektasi bahwa jejaknya bertahan terhadap pemeriksaan berbulan-bulan kemudian — bahwa persetujuan reviewer tercatat dan bisa diatribusikan, bukan sekadar tersirat dari sebuah branch yang di-merge. Tim yang sudah menganggap serius code review sebenarnya lebih dekat dengan requirement ini daripada yang mereka sadari; celahnya biasanya bukan review itu sendiri, melainkan apakah rekamannya masih masuk akal bagi seseorang yang membacanya jauh setelah pull request-nya ditutup.
Tidak satu pun dari ini membutuhkan organisasi yang sedang mengejar sertifikasi, dan tidak satu pun memintanya developer menghafal nomor kontrol. Yang diminta lebih kecil dan lebih berguna: baca tema-tema standar ini sebagai katalog praktik yang layak dimiliki terlepas dari siapa yang sedang memeriksa, karena mode kegagalan yang dijaganya — aset yang yatim, insiden yang tidak bisa dijelaskan, akses yang tidak pernah dirancang siapa pun, perubahan yang tidak bisa ditelusuri siapa pun — pertama-tama adalah masalah engineering, dan baru menjadi masalah birokrasi jika Anda menunggu orang lain menamainya begitu.