Terlihat
Seluruh aset SPBE dan risikonya tercatat dalam satu register, dapat ditelusuri per OPD.
Panduan Tata Kelola · Pemerintah Digital Sulawesi Barat
Tata Kelola Risiko SPBE yang Terorganisir, Terhubung, dan Terukur
MARISKA menyatukan register aset SPBE, layanan publik, dan manajemen risiko dalam satu sistem. Setiap risiko punya pemilik, punya aset yang dirujuk, punya layanan yang terdampak — dan setiap keputusan tercatat.
5
Kategori Aset SPBE
Data, Aplikasi, Pusat Data, Jaringan Intra, Penghubung Layanan
15
Kategori Risiko SPBE
Sesuai PermenPANRB No. 5 Tahun 2020
2
Register Risiko Terpadu
Risiko SPBE (ISO 31000) & Risiko Keamanan (ISO 27005)
1
Sumber Data Aplikasi
Katalog aplikasi tersinkron dari RELIGI
Satu layar, seluruh risiko
Dasbor yang langsung menunjukkan apa yang perlu ditindaklanjuti
Bukan sekadar daftar — Dasbor Risiko SPBE merangkum peta panas risiko (kemungkinan × dampak), status terkendali per kategori, dan daftar "Perlu Tindakan" yang diurutkan menurut prioritas, sehingga pimpinan dan pengelola tahu persis apa yang harus diputuskan lebih dulu.
Mengapa risiko SPBE perlu dikelola
Mengapa risiko SPBE perlu dikelola secara terstruktur?
Layanan pemerintahan kini bergantung pada aplikasi, data, server, dan jaringan. Ketika satu server berhenti, beberapa aplikasi bisa ikut lumpuh; ketika satu aplikasi lumpuh, layanan kepada masyarakat terhenti. Manajemen risiko SPBE memastikan pemerintah daerah mengetahui lebih dulu apa yang dapat mengganggu sasaran SPBE, memutuskan cara menanganinya, dan membuktikan bahwa penanganan itu benar-benar dijalankan.
Terhubung
Risiko tidak berdiri sendiri: ia ditautkan ke aset, layanan publik, insiden, dan risiko lain yang berkaitan.
Akuntabel
Setiap risiko punya pemilik, setiap rencana aksi punya penanggung jawab dan tenggat, setiap perubahan masuk jejak audit.
Landasan kebijakan & standar
Dibangun di atas kebijakan nasional dan standar internasional
- Regulasi Perpres No. 95 Tahun 2018 tentang SPBE — Kerangka SPBE dan unsur aset SPBE (data & informasi, aplikasi, infrastruktur: pusat data, jaringan intra pemerintah, sistem penghubung layanan).
- Regulasi PermenPANRB No. 5 Tahun 2020 Pedoman Manajemen Risiko SPBE — Dasar 15 kategori risiko SPBE, jenis risiko (negatif/positif), dan area dampak yang dipakai di modul Risiko SPBE.
- Standar ISO 31000 Manajemen Risiko — Siklus Risiko SPBE: penetapan konteks → identifikasi → analisis → evaluasi → perlakuan → pemantauan → reviu.
- Standar ISO/IEC 27005 Manajemen Risiko Keamanan Informasi — Siklus Risiko Keamanan: aset → ancaman → kerentanan → analisis → evaluasi → perlakuan → pemantauan → reviu → perbaikan berkelanjutan.
Pengelolaan data pribadi pada aset diperhitungkan melalui klasifikasi data (lihat bagian Atribut Aset), sejalan dengan kewajiban pelindungan data pribadi.
Register aset SPBE
Lima kategori aset SPBE — fondasi identifikasi risiko
Risiko keamanan selalu dimulai dari pertanyaan "aset apa yang perlu dilindungi?". MARISKA mencatat aset SPBE dalam lima kategori. Kategori aset juga menentukan katalog ancaman dan kerentanan yang relevan saat menilai risiko.
4.1 — Data dan Informasi
Kumpulan data dan informasi yang dikelola pemerintah daerah untuk penyelenggaraan pemerintahan dan layanan.
Contoh: data kependudukan, data kepegawaian, data sektoral, basis data, dokumen/arsip elektronik.
Dapat dicatat sebagai kelompok satu entri dengan rincian per jenis dan jumlah (satuan: dataset). Contoh rincian: Dataset kepegawaian, Dataset kependudukan, Arsip dokumen elektronik.
Mengapa penting: Data adalah aset yang paling sering menjadi sasaran (kebocoran, perubahan tanpa izin, kehilangan). Klasifikasi data menentukan seberapa besar dampak kerahasiaan dihitung.
Risiko yang lazim: data tidak akurat/tidak mutakhir, kebocoran data pribadi, data tidak tersedia saat dibutuhkan, tidak dapat dibagipakai.
4.2 — Aplikasi SPBE
Aplikasi yang digunakan untuk layanan publik dan administrasi pemerintahan, berbasis web maupun mobile.
Contoh: aplikasi layanan publik, aplikasi kepegawaian, aplikasi perencanaan & keuangan, portal informasi.
Wajib satu entri per aplikasi setiap aplikasi punya profil risiko dan ketergantungan sendiri. Aplikasi Pemprov diambil dari katalog RELIGI sehingga tidak perlu diinput ulang dan profilnya selalu tersinkron.
Mengapa penting: Aplikasi adalah wajah layanan digital kepada masyarakat; gangguan aplikasi langsung dirasakan pengguna.
Risiko yang lazim: aplikasi tidak berfungsi/tidak tersedia, celah keamanan, duplikasi aplikasi, tidak terintegrasi, tidak sesuai kebutuhan pengguna.
4.3 — Pusat Data
Fasilitas dan perangkat untuk menempatkan, menyimpan, mengolah, serta memulihkan data dan sistem elektronik.
Contoh: ruang/data center, server, storage, sistem backup, Disaster Recovery Center (DRC).
Dapat dicatat sebagai kelompok satuan: unit. Contoh rincian: Server rack 2U, Storage NAS, UPS ruang server.
Mengapa penting: Banyak aplikasi menumpang pada server dan storage yang sama — satu gangguan di pusat data dapat berdampak berantai ke banyak layanan.
Risiko yang lazim: kegagalan perangkat keras, backup tidak tersedia/tidak teruji, gangguan catu daya & pendingin, ransomware.
4.4 — Jaringan Intra Pemerintah
Jaringan tertutup yang menghubungkan simpul-simpul jaringan antar-OPD dan unit kerja pemerintah daerah.
Contoh: LAN/WAN, jaringan antar-OPD, VPN, perangkat jaringan (switch, router, access point, firewall).
Dapat dicatat sebagai kelompok satuan: unit. Contoh rincian: Access Point Tipe 1 × 4, Access Point Tipe 2 × 7, Switch 24 port. Perangkat sejenis tidak perlu dicatat satu per satu.
Mengapa penting: Jaringan adalah jalur seluruh layanan digital; tanpa jaringan, aplikasi dan data tidak dapat diakses.
Risiko yang lazim: gangguan konektivitas, akses tidak sah, konfigurasi perangkat yang lemah, ketergantungan pada satu jalur.
4.5 — Sistem Penghubung Layanan
Perangkat integrasi yang memungkinkan aplikasi dan data saling bertukar dan berbagi pakai, baik antar-OPD maupun dengan instansi pusat.
Contoh: API, API Gateway, middleware, layanan integrasi antar-aplikasi.
Wajib satu entri per integrasi/API setiap penghubung punya profil risiko dan ketergantungan sendiri.
Mengapa penting: Penghubung adalah titik temu banyak sistem; gangguan atau kebocoran di sini memengaruhi semua aplikasi yang terhubung.
Risiko yang lazim: integrasi gagal/terputus, kebocoran data lewat API, autentikasi API lemah, perubahan sistem mitra tanpa pemberitahuan.
Selain lima aset SPBE, MARISKA juga mencatat aset pendukung agar analisis
risiko lengkap:
Sumber Daya Manusia
— pengelola, operator, dan tenaga ahli SPBE (satuan: orang). · Fasilitas
— ruang, catu daya, pendingin, dan sarana fisik (mis. AC presisi, genset, APAR).
Rincian pencatatan
Setiap aset dicatat lengkap, bukan sekadar nama
- OPD pemilik OPD yang memiliki dan bertanggung jawab. Risiko keamanan atas aset otomatis tercatat pada OPD ini.
- Penanggung jawab Pegawai/pejabat yang mengelola aset sehari-hari — kontak utama saat insiden.
- Klasifikasi data Publik · Internal · Terbatas · Rahasia · Sangat Rahasia. Bawaan sistem: Internal (aman secara default). Semakin tinggi klasifikasi, semakin besar bobot dampak kerahasiaan.
- Kritikalitas (0–100) Seberapa penting aset bagi layanan. 20–44 rendah–sedang · 45–69 tinggi · ≥ 70 kritis (prioritas pengamanan, pencadangan, pemulihan).
- Status operasional Aktif · Maintenance · Nonaktif · Dekomisioning. Aset tidak dihapus — dinonaktifkan, agar riwayat risikonya tetap utuh.
- Relasi ketergantungan Aset ini membutuhkan aset apa (teknis, operasional, atau data). Dasar analisis dampak berantai.
- Layanan yang didukung Layanan publik yang bergantung pada aset ini.
Integrasi aplikasi
Aplikasi tidak diinput dua kali — tersinkron dari RELIGI
RELIGI (Repositori Layanan Digital Pemprov Sulawesi Barat) adalah sumber kebenaran profil aplikasi SPBE. MARISKA menarik katalog aplikasi dari RELIGI secara berkala, lalu operator mendaftarkan aplikasi dari katalog menjadi aset di MARISKA.
-
1
Tarik katalog
MARISKA menyalin daftar aplikasi dari RELIGI: sinkron menyeluruh berkala (dengan rekonsiliasi) dan pembaruan inkremental setiap jam.
-
2
Petakan OPD
OPD pemilik di RELIGI dicocokkan otomatis dengan OPD di MARISKA (kode/nama); sisanya dipetakan administrator.
-
3
Daftarkan sebagai aset
Aplikasi dari katalog didaftarkan menjadi aset kategori Aplikasi SPBE lengkap dengan snapshot profilnya.
-
4
Tetap tersinkron
Perubahan nama, deskripsi, status, atau OPD di RELIGI ikut diperbarui di MARISKA.
Jaminan tata kelola
- Satu sumber kebenaran. Profil aplikasi (nama, deskripsi, status, OPD) hanya berubah lewat RELIGI — tidak bisa diubah manual di MARISKA, sehingga tidak ada dua versi data.
- Register risiko tidak pernah rusak. Aplikasi yang dihapus atau keluar cakupan di RELIGI dinonaktifkan, bukan dihapus — risiko, rencana aksi, dan reviu yang merujuknya tetap utuh.
- Kritikalitas awal otomatis. Saran kritikalitas diambil dari kategori urgensi keamanan RELIGI (Kritis 90 · Tinggi 70 · Sedang 45 · Rendah 20). Jika sudah ditetapkan manual, sinkronisasi tidak menimpanya.
- Klasifikasi data hanya naik, tidak pernah turun. Aplikasi yang memproses data pribadi otomatis berklasifikasi minimal Terbatas; keputusan klasifikasi lebih tinggi oleh admin tidak diturunkan.
- Insiden ikut terhubung. Insiden aplikasi yang dicatat di Log Insiden RELIGI tampil otomatis di modul Insiden MARISKA.
- Tercatat. Setiap run sinkronisasi menyimpan jejak (mode, jumlah data baru/diperbarui/dinonaktifkan, status berhasil/gagal).
Satu rantai yang terhubung
Manajemen risiko yang terintegrasi dengan pengelolaan layanan dan aplikasi
Inilah pembeda utama MARISKA. Risiko tidak dicatat sebagai daftar terpisah, tetapi sebagai bagian dari rantai: aset → layanan publik → risiko → penanganan → pemantauan.
1 — Aset menopang aset lain — Peta Dependensi
- Setiap aset dapat ditautkan ke aset prasyaratnya (mis. Aplikasi Kepegawaian bergantung pada Server Basis Data dan Jaringan Intra). Jenis relasi: teknis, operasional, atau data.
- MARISKA menghitung dampak berantai: jika aset X terganggu, aset dan layanan apa saja yang ikut terdampak, sampai berapa tingkat?
- Peta Dependensi menandai otomatis: titik kegagalan tunggal (aset penopang satu-satunya), aset perlu ditinjau (penopang yang kritikalitasnya lebih rendah dari yang ditopangnya), dan peran aset (inti, perantara, hilir, atau terisolasi).
- Batas akses OPD tetap dijaga: aset milik OPD lain yang terhubung tampil tanpa nama.
2 — Aset melayani layanan publik
- Setiap layanan publik OPD dicatat dengan perkiraan jumlah pengguna, kritikalitas, serta target RTO (batas waktu pemulihan) dan RPO (batas kehilangan data).
- Aset ditautkan ke layanan yang didukungnya — sehingga gangguan pada aset dapat langsung diterjemahkan menjadi "layanan apa yang berhenti dan berapa warga terdampak".
3 — Analisis Dampak Bisnis (BIA)
- Untuk layanan penting, OPD melakukan asesmen BIA bersama pemilik proses bisnis: dampak operasional, finansial, reputasi, dan kepatuhan (skala 1–5), serta MTPD (batas maksimum layanan boleh terganggu).
- Hasilnya: rekomendasi RTO/RPO dan strategi pemulihan, yang setelah disetujui diterapkan kembali ke data layanan.
4 — Risiko keamanan menilai aset dan layanannya
- Dampak keamanan informasi — kerahasiaan, integritas, ketersediaan (diambil nilai tertinggi) × pengali klasifikasi data aset.
- Kemungkinan — dengan mempertimbangkan kontrol yang sudah ada dan riwayat insiden.
- Bobot bisnis — kritikalitas layanan, dampak ke masyarakat, dampak regulasi, dan dampak reputasi.
- Skor inheren (0–100) lalu skor residual setelah kontrol keamanan diterapkan.
5 — Insiden memberi umpan balik
- Insiden dikaitkan ke aset dan (opsional) layanan yang terganggu.
- Frekuensi insiden per aset menjadi dasar penilaian kemungkinan pada risiko keamanan aset tersebut — risiko dinilai berdasarkan kejadian nyata, bukan asumsi.
- Bila ancaman muncul kembali, risiko yang sudah ditutup dapat dibuka kembali.
Dua sudut pandang, satu tata kelola
Risiko SPBE dan Risiko Keamanan SPBE
15 kategori risiko SPBE (PermenPANRB 5/2020)
Perencanaan & Tata Kelola:
Rencana Induk SPBE
Arsitektur SPBE
Peta Rencana SPBE
Proses Bisnis
Rencana dan Anggaran
Inovasi
Kepatuhan & Pelaksanaan:
Kepatuhan terhadap Peraturan
Pengadaan Barang dan Jasa
Proyek Pembangunan/Pengembangan Sistem
Sumber Daya SPBE:
Data dan Informasi
Infrastruktur SPBE
Aplikasi SPBE
Keamanan SPBE
Sumber Daya Manusia SPBE
Eksternal:
Bencana Alam
Kategori Data dan Informasi, Aplikasi SPBE, dan
Infrastruktur SPBE (Pusat Data, Jaringan Intra Pemerintah, Sistem Penghubung
Layanan) pada Risiko SPBE berpadanan langsung dengan lima kategori aset SPBE — sehingga risiko
tata kelola dan risiko teknis atas aset yang sama dapat dibaca berdampingan.
Cascade — jembatan antar-register
-
Bottom-up
Risiko keamanan yang serius pada sebuah aset dapat diusulkan naik menjadi risiko SPBE bagi OPD (mis. kerentanan pada aplikasi layanan yang mengancam sasaran layanan). Hasilnya berupa draf yang wajib dikonfirmasi pemilik risiko SPBE sebelum masuk register resmi.
-
Top-down
Risiko SPBE kategori proyek pembangunan, aplikasi, infrastruktur, atau pengadaan dapat ditandai butuh asesmen keamanan — tim Diskominfo lalu menyusun risiko keamanan terkait sebelum sistem beroperasi.
Setiap tautan cascade tidak pernah ditimpa: perubahan status dicatat sebagai entri baru sehingga riwayat keterkaitan dapat ditelusuri penuh.
Satu siklus yang jelas
Dari identifikasi hingga penutupan
Risiko SPBE (ISO 31000)
-
1 Penetapan konteks
-
2 Identifikasi
-
3 Analisis
-
4 Evaluasi
-
5 Perlakuan
-
6 Pemantauan
-
7 Reviu
Risiko Keamanan (ISO/IEC 27005)
-
1 Identifikasi aset
-
2 Identifikasi ancaman
-
3 Identifikasi kerentanan
-
4 Analisis risiko
-
5 Evaluasi
-
6 Perlakuan
-
7 Pemantauan
-
8 Reviu
-
9 Perbaikan berkelanjutan
Matriks level risiko (bawaan — ambang dapat disesuaikan per pemerintah daerah)
Syarat penutupan risiko
- Rencana aksi tuntas.
- Level risiko sudah di bawah Tinggi (untuk risiko keamanan: kontrol efektif dan skor residual di bawah Tinggi).
- Diputuskan melalui reviu dengan alasan penutupan yang tercatat permanen.
- Risiko yang ditutup tetap tersimpan sebagai bukti dan dapat dibuka kembali.
Siapa berperan
Peran yang jelas di setiap tingkatan
Kepala Daerah
Menetapkan arah dan selera risiko; memantau risiko strategis lewat Dasbor Eksekutif.
Sekretaris Daerah
Mengoordinasikan penanganan risiko lintas OPD; memberi persetujuan risiko Tinggi/Ekstrem sesuai kewenangan.
Operator Diskominfo
Mengelola register aset lintas OPD, integrasi RELIGI, katalog ancaman/kerentanan/kontrol, dan asesmen risiko keamanan.
Pemilik Risiko OPD
Pejabat yang bertanggung jawab atas risiko layanan/proses OPD-nya: menetapkan perlakuan dan memutuskan hasil reviu.
Operator OPD
Mencatat aset, risiko, insiden, dan tindak lanjut rencana aksi untuk OPD-nya sendiri.
Verifikator
Memverifikasi kelengkapan dan kewajaran isian risiko serta tindak lanjut.
Inspektorat
Mengawasi dan mereviu pelaksanaan manajemen risiko sebagai bagian pengawasan internal.
Hak akses setiap peran ditegakkan di server — menu yang tidak berhak tidak tampil, dan setiap permintaan data tetap diperiksa. Operator OPD hanya melihat data OPD-nya sendiri.
Bukti tata kelola yang baik
Bagaimana MARISKA membuktikan risiko dikelola dengan baik
Jejak audit lengkap
Setiap perubahan (nilai sebelum & sesudah), persetujuan, dan keputusan reviu tercatat.
Akuntabilitas bernama
Setiap risiko punya pemilik, setiap rencana aksi punya PIC dan target tanggal; yang lewat target otomatis berstatus Terlambat.
Persetujuan berjenjang
Risiko Tinggi/Ekstrem tidak dapat ditangani tanpa persetujuan pimpinan.
Reviu terjadwal
Risiko yang dipantau memiliki jadwal reviu berikutnya; keputusan reviu menentukan arah siklus.
Tidak ada yang hilang
Aset dan risiko tidak dihapus fisik; aset nonaktif dan risiko tertutup tetap menjadi bukti.
Laporan berkala
Ringkasan kondisi risiko, capaian rencana aksi, dan insiden per periode untuk pimpinan dan pemeriksa.
Mulai dari mana?
Lima langkah untuk OPD
-
1
Periksa aset OPD Anda
di Aset & Layanan — pastikan aplikasi dari RELIGI sudah terdaftar; lengkapi data, pusat data, jaringan, dan penghubung yang dikelola OPD.
Lihat bagian ini -
2
Tautkan ketergantungan dan layanan
aset apa menopang aset apa, dan layanan publik mana yang dilayani. Cek Peta Dependensi untuk titik kegagalan tunggal.
Lihat bagian ini -
3
Identifikasi risiko
Risiko SPBE untuk sasaran/layanan OPD; Risiko Keamanan untuk aset (bersama Diskominfo).
Lihat bagian ini -
4
Susun dan jalankan rencana aksi
tetapkan PIC dan target, laporkan tindak lanjut berkala.
Lihat bagian ini -
5
Reviu dan laporkan
putuskan lanjut pantau, perlakuan ulang, atau tutup; laporan berkala tersusun otomatis.
Lihat bagian ini
Pertanyaan umum
Yang paling sering ditanyakan
Apa beda Risiko SPBE dan Risiko Keamanan?
Risiko SPBE melihat apa yang dapat menghambat sasaran SPBE OPD (perencanaan, anggaran, proyek, layanan, SDM, dll.). Risiko Keamanan melihat ancaman terhadap kerahasiaan, integritas, dan ketersediaan aset tertentu. Keduanya dapat saling ditautkan melalui cascade.
Mengapa aplikasi saya tidak bisa diubah namanya di MARISKA?
Aplikasi yang berasal dari RELIGI dikelola di RELIGI sebagai sumber kebenaran. Ubah profilnya di RELIGI; perubahan akan tersinkron ke MARISKA.
Mengapa aset tidak bisa dihapus?
Aset yang sudah dirujuk risiko harus tetap ada agar riwayat penilaian dan bukti penanganannya utuh. Aset yang tidak digunakan cukup diubah statusnya menjadi Nonaktif atau Dekomisioning.
Apakah setiap access point harus dicatat satu per satu?
Tidak. Data dan Informasi, Pusat Data, Jaringan Intra Pemerintah (serta SDM dan Fasilitas) dapat dicatat sebagai aset kelompok dengan rincian tipe dan jumlah unit. Aplikasi dan Sistem Penghubung Layanan tetap dicatat satu per satu.
Apa arti "titik kegagalan tunggal" di Peta Dependensi?
Aset yang menjadi satu-satunya penopang bagi aset lain. Jika aset ini terganggu, aset yang bergantung padanya tidak punya alternatif — prioritaskan cadangan, redundansi, atau rencana pemulihannya.
Kapan risiko boleh ditutup?
Ketika rencana aksi tuntas, level risiko sudah di bawah Tinggi, dan reviu memutuskan penutupan dengan alasan yang tercatat. Risiko tertutup dapat dibuka kembali bila sumber risikonya muncul lagi.
Risiko yang dikenali adalah risiko yang dapat dikendalikan
Lengkapi register aset OPD Anda dan pastikan setiap layanan penting memiliki risiko yang teridentifikasi, pemilik yang jelas, dan rencana aksi yang berjalan.