Kepatuhan Keamanan Siber
Kepatuhan Bukan Berarti Efektivitas Kontrol
Juli 2026 · 4 menit baca
Checklist compliance yang selesai memberi tahu Anda bahwa sebuah tugas sudah dikerjakan. Ia jarang memberi tahu apakah hal yang seharusnya dicegah tugas itu benar-benar tercegah. Access review bisa dicatat selesai, kebijakan bisa ditandatangani, sebuah file bukti bisa dilampirkan ke sebuah kontrol di audit tracker — dan tidak satu pun dari itu menjamin kontrolnya benar-benar mengubah perilaku siapa pun pada hari Selasa biasa, enam minggu setelah review itu terjadi. Mencampuradukkan keduanya, memperlakukan checklist yang selesai sebagai bukti kontrol yang efektif, adalah salah satu kesalahan paling mahal yang bisa dibuat organisasi, karena ia tidak terlihat sampai momen ketika ia paling penting.
Saya pernah menghabiskan waktu berkontribusi pada platform self-assessment yang dibangun persis untuk pekerjaan compliance semacam ini, menyaksikan organisasi menandai requirement selesai dari dalam tool yang memungkinkan mereka melakukannya. Yang menjadi jelas selama bekerja di platform itu adalah bahwa "selesai" adalah status yang ditetapkan seseorang, bukan properti yang diperoleh kontrol dengan sendirinya. Requirement yang ditandai selesai dengan dokumen kebijakan terlampir menunjukkan organisasi sudah mengerjakan administrasinya. Itu jauh lebih sedikit menunjukkan apakah kontrolnya, pada hari ketika benar-benar dibutuhkan, benar-benar bertahan.
Tulisan ini membahas kesenjangan itu — antara kontrol yang terdokumentasi dan kontrol yang efektif — dan apa yang dibutuhkan, sebagai pemimpin engineering bukan sebagai auditor, untuk menjaga keduanya agar tidak diam-diam menjauh satu sama lain.
Apa yang sebenarnya dibuktikan oleh "terdokumentasi"
Kontrol yang terdokumentasi membuktikan niat, dan paling baik, satu momen implementasi. Ia membuktikan organisasi memutuskan akses harus dibatasi, mencatat siapa yang menyetujuinya, dan bisa menunjukkan bukti ketika seorang asesor bertanya. Yang tidak dibuktikannya adalah daya tahan: apakah langkah persetujuan masih diikuti ketika penyetujunya sedang cuti, apakah pembatasannya bertahan melewati migrasi sistem, apakah tidak ada yang diam-diam memberi pengecualian karena tenggat waktu terasa lebih mendesak daripada kebijakan. Item checklist dan kontrol saling berkaitan, tetapi item checklist adalah potret sesaat sedangkan kontrol dimaksudkan untuk berkelanjutan.
Skala maturity ada karena "selesai" bukan satu keadaan tunggal
Pekerjaan self-assessment yang saya ikut kerjakan memakai skala maturity, bukan status biner selesai-atau-belum, dan alasannya menjadi jelas semakin lama saya bekerja di sana: maturity sebuah kontrol — Nonexistent, Initial, Limited, Defined, Managed, Optimized, atau Not Applicable ketika requirement-nya memang tidak relevan — menggambarkan sesuatu yang lebih dekat ke konsistensi dan perbaikan berkelanjutan daripada sekadar kelengkapan. Sebuah kontrol bisa berada di level Defined, artinya sudah tertulis dan dipahami, sementara masih jauh dari Managed, artinya benar-benar dipantau dan diukur. Memperlakukan "kami punya kebijakan" setara dengan "kami tahu ini berhasil" melompati empat level dari skala enam level, dan justru di lompatan itulah efektivitas kontrol diam-diam gagal.
Kesenjangan melebar di celah antar-audit
Sebuah audit, menurut desainnya, adalah latihan pada satu titik waktu. Ia mengambil sampel sebuah kontrol pada hari tertentu dan mengekstrapolasikan bahwa sampel itu mewakili satu tahun penuh. Masalahnya, hampir semua mode kegagalan kontrol yang sesungguhnya berkembang di antara audit, bukan selama audit: staf kunci yang memiliki proses itu keluar, sebuah sistem dimigrasikan dan mekanisme dasar kontrolnya tidak ikut bermigrasi dengan mulus, sebuah pengecualian diberikan di bawah tekanan tenggat waktu dan tidak pernah ditinjau ulang, sebuah tool dikonfigurasi ulang untuk alasan yang tidak terkait dan sebuah dependensi diam-diam rusak.
Tidak satu pun dari kejadian itu muncul di audit tracker kecuali seseorang mencarinya secara khusus di luar siklus audit. Itulah argumen sesungguhnya untuk memperlakukan audit yang lolos sebagai batas bawah, bukan batas atas: ia memberi tahu Anda kontrolnya berfungsi pada hari seseorang memeriksanya, bukan bahwa ia terus berfungsi sejak itu.
Seperti apa review yang jujur dari kursi kepemimpinan engineering
Menutup kesenjangan itu lebih merupakan keputusan kepemimpinan daripada keputusan teknis, karena artinya memilih untuk mencari bukti kegagalan pada jadwal yang tidak dipaksakan siapa pun kepada Anda.
- Uji kontrol pada jadwal yang lepas dari kalender audit, bukan hanya saat asesor bertanya — fire drill yang tidak pernah dilihat auditor tetap layak dijalankan.
- Ajukan pertanyaan yang lebih sulit kepada control owner daripada "apakah ini masih terdokumentasi": kapan terakhir kali kontrol ini benar-benar menghentikan sesuatu, atau Anda bahkan tidak tahu?
- Perlakukan sinyal operasional — lonjakan manual override, kenaikan pengecualian akses, celah logging yang tidak dilaporkan siapa pun — sebagai bukti maturity sebuah kontrol sedang mundur, bahkan di antara review formal.
- Buat aman, bahkan dihargai, bagi control owner untuk melaporkan bahwa kontrolnya berhenti berfungsi, alih-alih diam-diam melampirkan ulang bukti lama yang sama saat waktu perpanjangan tiba.
Semua ini bukan argumen menentang framework compliance atau tool self-assessment — saya sudah cukup lama membangun salah satunya untuk percaya pada apa yang bisa mereka wujudkan. Ini adalah argumen tentang apa yang tidak bisa mereka lakukan sendiri: sebuah framework bisa memberi tahu Anda apa yang harus diperiksa dan sebuah platform bisa membuat pemeriksaan lebih mudah, tetapi hanya organisasi yang memperlakukan audit yang lolos sebagai batas bawah ekspektasinya, bukan batas atasnya, yang benar-benar mengetahui apakah kontrolnya bekerja pada hari-hari ketika tidak ada yang sedang mengawasi.