ISO 27001/27002
Dari Kontrol ISO 27002 ke Kebutuhan Rekayasa
Juli 2026 · 4 menit baca
Katalog kontrol ISO 27002 sengaja ditulis pada tingkat hasil. Ia memberi tahu organisasi bahwa akses harus dikelola, perubahan harus dikendalikan, dan security-relevant event harus dicatat — lalu berhenti di situ, karena standar tidak mungkin mengetahui arsitektur Anda, tim Anda, atau pipeline deployment Anda. Penahanan diri itu adalah kekuatan sang standar sekaligus masalah menahun bagi tim engineering, yang dibiarkan memegang bahasa yang menggambarkan tujuan tanpa rutenya.
Pola kegagalan yang paling sering saya lihat adalah memperlakukan celah itu sebagai latihan dokumentasi: teks kontrol diparafrasakan ke dalam kebijakan, kebijakan disetujui, dan delivery berjalan seperti biasa sampai audit memaksa perbaikan tergesa-gesa. Compliance menjadi proses paralel yang ditempelkan pada engineering — memenuhi bunyi setiap kontrol tanpa mengubah apa pun tentang cara software sebenarnya dibangun.
Setelah bergerak di antara tanggung jawab tata kelola keamanan dan software engineering langsung — termasuk berkontribusi pada platform yang tujuannya memang membantu organisasi menilai kontrol-kontrol seperti ini — saya terbiasa memperlakukan setiap kontrol sebagai input bagi proses requirement. Berikut jalur penerjemahan yang saya pakai, dari bahasa kontrol menjadi pekerjaan yang bisa diestimasi, dibangun, dan diverifikasi tim engineering.
Baca kontrol sebagai pertanyaan, bukan instruksi
Kontrol yang menyatakan akses ke informasi harus dibatasi sesuai kebijakan tidak sedang memberi tahu Anda apa yang harus dibangun; ia sedang mengajukan pertanyaan yang belum Anda jawab. Siapa pemilik sistem ini dan data ini? Peran apa saja yang ada, dan apa yang benar-benar dibutuhkan masing-masing? Bagaimana akses diberikan, dan — bagian yang sering dilupakan tim — bagaimana serta kapan akses dicabut? Gerakan yang sama berlaku di seluruh katalog: kontrol logging menanyakan seperti apa security-relevant event di sistem Anda; kontrol change management menanyakan perubahan mana yang membutuhkan jejak persetujuan terdokumentasi sebelum masuk production. Tuliskan pertanyaan-pertanyaannya. Itulah bahan mentah requirement, dan menjawabnya sejak awal jauh lebih murah daripada menjawabnya di tengah audit.
Beri setiap jawaban seorang pemilik
Bahasa kontrol gemar kalimat pasif: akses akan ditinjau, insiden akan dilaporkan. Software tidak berjalan dengan kalimat pasif. Setiap requirement hasil terjemahan membutuhkan pemilik yang disebut namanya — orang atau tim, bukan departemen — yang bertanggung jawab memastikan mekanismenya ada dan terus bekerja. Dalam praktik, inilah langkah penerjemahan dengan daya ungkit tertinggi: sebagian besar kegagalan kontrol yang saya lihat bukan karena mekanismenya tidak ada, melainkan karena yatim — dibangun sekali dan tidak dimiliki siapa pun setelah engineer yang menulisnya pindah.
Ubah maksud menjadi acceptance criteria
Begitu sebuah kontrol menjadi pertanyaan yang ada pemiliknya, jawabannya berubah menjadi pernyataan yang bisa diuji — acceptance criteria yang sama seperti yang Anda tulis untuk fitur mana pun:
- Ketika peran seorang pengguna berubah, akses yang terikat pada peran lama dicabut dalam jangka waktu yang terdefinisi, dan pencabutan itu tercatat.
- Setiap deployment ke production dapat ditelusuri ke perubahan yang sudah di-review dan disetujui, dengan penyetuju yang bisa diidentifikasi.
- Security-relevant event — autentikasi, perubahan izin, ekspor data — dicatat dengan aktor, timestamp, dan hasilnya, dan log itu sendiri dilindungi dari modifikasi.
- Jalur akses darurat tersedia, dan pemakaiannya memicu review, bukan sekadar angkat bahu.
Lebur kontrol ke dalam kebiasaan delivery
Penerjemahan baru selesai ketika ia melebur ke dalam cara tim sudah bekerja. Aturan akses menjadi bagian code review — reviewer menanyakan siapa yang boleh memanggil endpoint ini sebagaimana ia menanyakan test coverage. Change control berhenti menjadi formulir terpisah dan menjadi alur pull request Anda dengan persetujuan yang benar-benar tercatat. Keputusan logging dibuat dalam diskusi desain, bukan ditemukan saat incident response. Ketika sebuah kontrol hidup di dalam kebiasaan delivery, bukti terkumpul sebagai efek samping pekerjaan normal — persis yang diharapkan auditor, dan yang tidak pernah dihasilkan proses tempelan.
Semua ini tidak serta-merta membuat tim menjadi compliant, dan memang bukan itu tujuannya. Tujuannya adalah ketika percakapan audit terjadi, engineering bisa menjawab dengan artefak alih-alih jaminan lisan — requirement, catatan review, log — karena kontrol diperlakukan sebagai input pekerjaan, bukan dokumen sesudahnya. Dari pengalaman saya, tim seperti itu juga menghasilkan software yang lebih baik, dengan atau tanpa audit: kepemilikan, traceability, dan desain akses yang disengaja tidak pernah menjadi gagasan compliance semata. Sejak awal semuanya adalah gagasan engineering yang kebetulan dituliskan sebuah standar.