Pada 23 September 2026, Menteri Koordinator Bidang Hukum, HAM, Imigrasi, dan Pemasyarakatan Yusril Ihza Mahendra menegaskan bahwa transformasi digital pemerintahan harus ditopang sistem dengan keamanan dan keandalan tinggi. Pada hari yang sama, Kemenko Kumham Imipas menandatangani nota kesepahaman dengan Badan Siber dan Sandi Negara (BSSN) untuk memperkuat keamanan sistem elektronik, mitigasi insiden, dan pelindungan aset digital pemerintah selama 2026–2031—sebagaimana diliput ANTARA.
Pesannya relevan jauh di luar satu kementerian. Bagi pimpinan operasional di pemerintah daerah, BUMD, faskes, lembaga keuangan lokal, maupun perusahaan yang melayani sektor publik, pertanyaan praktisnya sama: bagaimana memasukkan keamanan ke dalam siklus hidup sistem—bukan sebagai audit di ujung proyek. Kepala BSSN Nugroho Sulistyo Budi, dalam konferensi yang sama, menekankan keamanan harus menjadi bagian dari perencanaan, pembangunan, hingga pengembangan sistem. Itu selaras dengan prinsip security by design yang sudah lama digaungkan BSSN untuk SPBE.
Keamanan jangan ditempatkan di pemeriksaan terakhir (security at the end), tetapi dirancang sejak awal (security by design).
Artikel ini merangkum lima langkah operasional yang bisa Anda terapkan sebelum go-live, dengan merujuk liputan publik dan pernyataan resmi BSSN, lalu menempatkannya dalam kerangka Diagnose, Deliver, dan Operate. Ini bukan nasihat hukum, dan bukan klaim bahwa organisasi Anda sudah wajib mengikuti MoU tersebut; ini adalah cara membaca sinyal kebijakan agar keputusan teknologi lebih tahan uji.
Mengapa security by design mendesak sekarang
Insiden ransomware pada Pusat Data Nasional Sementara (PDNS) pada Juni 2024 menjadi pengingat mahal: gangguan pada infrastruktur bersama dapat menjalar ke layanan imigrasi, beasiswa, hingga aplikasi persuratan. Menurut liputan GovInsider yang mengutip Deputi BSSN Sulistyo, PDNS mendukung lebih dari 228 kementerian, lembaga, dan pemerintah daerah. Ketika satu titik gagal, dampaknya sistemik.
BSSN juga mencatat sektor administrasi pemerintahan termasuk tiga sektor dengan anomali trafik tertinggi dalam tiga tahun terakhir; sekitar 60–80 persen di antaranya terkait malware. Celah yang berulang tidak selalu serangan canggih: perangkat lunak bajakan atau lisensi habis, antivirus tidak dipakai, serta kegagalan patching. Itu berarti banyak risiko bisa dikurangi dengan disiplin siklus hidup—bukan hanya alat keamanan baru.
Di sisi kebijakan, Peraturan Presiden Nomor 132 Tahun 2022 tentang Arsitektur SPBE sudah menempatkan keamanan sebagai salah satu domain. Rancangan Perpres tentang Pemerintahan Digital sedang dibahas sebagai refleksi atas implementasi SPBE. Sementara itu, konsolidasi Tim Tanggap Insiden Siber (CSIRT) berlanjut: Sulistyo menyebut sekitar 97 persen kementerian, lembaga, dan pemda sudah punya CSIRT pada 2025, naik dari sekitar 42 persen tahun sebelumnya—dengan penyelesaian sisa pada 2026. Kapasitas respons meningkat; yang sering tertinggal adalah desain keamanan sebelum sistem diadakan.
Lima langkah sebelum go-live
1. Kunci kriteria keamanan di Diagnose, sebelum anggaran terkunci
Security by design dimulai saat ruang lingkup masih bisa diubah murah. Pada tahap Diagnose, tuliskan secara eksplisit: klasifikasi data (termasuk data pribadi dan data strategis), asumsi ancaman, persyaratan sertifikasi atau pengujian keamanan produk, kebutuhan pencatatan akses, serta batasan integrasi ke sistem lain. Sulistyo menekankan kriteria keamanan perlu masuk sejak pengadaan—bukan setelah vendor terpilih dan kontrak sulit diubah.
Untuk organisasi yang bekerja dengan mitra eksternal, Diagnose juga mencegah pola fitur dulu, keamanan belakangan. Jika Anda masih meraba apakah masalahnya proses, arsitektur, atau sekadar tooling, kapan Diagnose berbayar masuk akal adalah titik mulai yang lebih murah daripada retrofit setelah go-live.
2. Jadikan keamanan acceptance criteria di setiap milestone Deliver
Pada tahap Deliver, keamanan harus punya kriteria penerimaan tertulis per milestone: autentikasi dan otorisasi, manajemen rahasia, logging yang bisa diaudit, enkripsi data diam dan data bergerak sesuai klasifikasi, serta uji kerentanan sebelum rilis. Tanpa itu, selesai hanya berarti UI jalan—bukan sistem siap menghadapi ancaman.
Integrasi API sering menjadi titik lemah. Saat sistem baru menyambung ke registri sipil, ERP, atau layanan pihak ketiga, perlakukan batas kepercayaan (trust boundary) sebagai desain, bukan catatan kaki. Lihat juga praktik integrasi sistem & API agar kontrak antarmuka dan kontrol akses ikut diuji, bukan hanya happy path.
3. Rencanakan patching dan siklus hidup sebagai bagian Operate
BSSN mengingatkan: sistem yang bertahun-tahun beroperasi tanpa pembaruan teknologi dan keamanan membuka kerentanan. CVE hanya berguna jika patch benar-benar diterapkan. Itu alasan mengapa model maintenance reaktif vs Operate penting untuk sistem kritis: Operate mensyaratkan pemilik layanan, jendela patch, monitoring, dan perubahan terkendali—bukan menunggu rusak lalu memperbaiki.
Pada SOW Deliver, minta draft Operate sejak awal: siapa on-call, SLA respons, kebijakan lisensi, inventaris aset, dan prosedur dekomisioning. Keamanan tidak berhenti saat peresmian; justru risiko meningkat setelah sistem menjadi bisnis seperti biasa.
4. Siapkan CSIRT dan runbook sebelum insiden pertama
Tidak ada sistem yang sepenuhnya kebal. BSSN mendorong CSIRT di kementerian, lembaga, dan pemda—bukan hanya saat serangan, tetapi untuk prosedur, latihan, dan deteksi dini (defacing, kebocoran data, ransomware). Jika organisasi Anda belum punya struktur setara, minimal miliki: jalur eskalasi, kontak hukum dan komunikasi, cadangan yang teruji restore, dan runbook pemberitahuan jika data pribadi terlibat (selaras dengan arah PP 33/2026 yang kami bahas di hitung mundur PP 33/2026).
Sulistyo menekankan Infrastruktur Informasi Vital dan layanan yang menyentuh keselamatan manusia membutuhkan pengelolaan kerentanan, pengujian, dan pemeliharaan yang lebih ketat. Rekam medis yang dimanipulasi, atau sistem navigasi yang usang, punya konsekuensi berbeda dari portal informasi statis. Gunakan klasifikasi dampak untuk mengalokasikan anggaran keamanan—bukan merata tipis ke semua aplikasi.
Checklist singkat untuk pimpinan operasional
- Apakah kriteria keamanan sudah ada di dokumen pengadaan atau Diagnose sebelum RFP ditutup?
- Apakah setiap milestone Deliver punya acceptance criteria keamanan yang bisa diuji?
- Apakah patching, lisensi, dan inventaris aset punya pemilik di Operate?
- Apakah CSIRT atau setara punya runbook dan latihan, bukan hanya nama di SK?
- Apakah sistem berdampak tinggi mendapat pengujian dan monitoring lebih ketat?
Bagaimana MarkasDev menempatkan ini di Diagnose–Deliver–Operate
MarkasDev adalah Technology Partner, bukan auditor keamanan tersertifikasi atau penasihat hukum. Yang kami bantu adalah memperjelas risiko dan opsi di Diagnose, membangun dengan kriteria penerimaan tertulis di Deliver—termasuk software custom dan server & lingkungan—lalu menjaga sistem dengan SLA, monitoring, dan perubahan terkendali di Operate. Untuk pembaca di pemerintah dan BUMD, konteks sektor kami ringkas di Pemerintah & BUMD.
Jika Anda sedang merancang SPBE lokal, modernisasi layanan, atau integrasi yang menyentuh data warga, mulailah dari daftar aset dan kriteria keamanan—bukan dari katalog fitur. Untuk mendiskusikan ruang lingkup tanpa komitmen besar di depan, kunjungi halaman kontak.
Sumber