Risiko Apa yang Muncul Saat Perusahaan Membangun Infrastruktur IT Tanpa Konsultan?
Membangun infrastruktur IT sendiri berarti perusahaan menanggung semua keputusan teknis, mulai dari server, jaringan, penyimpanan, backup, sampai keamanan, tanpa pembanding dari pihak yang sudah sering melihat kegagalan serupa. Sederhananya, risikonya jarang muncul saat sistem berjalan normal, tetapi terlihat jelas pada hari insiden. Tulisan ini membahas jenis risiko utama, soal backup, pelajaran dari PDNS 2, ancaman siber terkini, perangkat lunak usang, lokasi data, kapan membangun sendiri masih masuk akal, dan cara menimbang biayanya.
TLDR
Apa Saja Risiko Utama Membangun Infrastruktur IT Tanpa Konsultan?
Risiko terbesar ada pada hal yang tidak terlihat sehari-hari, yaitu backup, pemulihan, keamanan, dan dokumentasi.
Mengapa Backup Sering Terlewat Padahal Fasilitasnya Sudah Ada?
Backup sering dianggap beban anggaran dan sulit dijelaskan urgensinya, sehingga fasilitas tersedia tetapi tidak dipakai.
Apa yang Terjadi pada PDNS 2 dan Pelajarannya bagi Perusahaan?
Serangan ransomware pada Juni 2024 melumpuhkan layanan 282 instansi, dan pemulihan bergantung pada backup masing-masing tenant.
Seberapa Besar Ancaman Serangan Siber yang Dihadapi Infrastruktur Saat Ini?
Komdigi mencatat 2,2 juta percobaan serangan ke Indonesia dalam 24 jam pada 10 November 2026.
Bagaimana Perangkat Lunak Usang Diam-Diam Menumpuk Risiko?
Vaksincom menemukan 96,7 persen server pemerintah yang terdeteksi masih memakai PHP yang sudah tidak menerima pembaruan keamanan.
Di Mana Data Perusahaan Boleh Disimpan dan Apa Kata Aturannya?
Aturan membuka ruang penempatan data di luar negeri bagi swasta, dengan syarat pengawasan dan penegakan hukum tetap berjalan.
Kapan Membangun Sendiri Masih Masuk Akal dan Kapan Perlu Konsultan?
Membangun sendiri cocok untuk sistem sederhana dengan tim yang berpengalaman, sedangkan sistem kritis perlu pembanding dari luar.
Bagaimana Menimbang Biaya Konsultan Dibanding Biaya Insiden?
Bandingkan biaya konsultasi dengan kerugian henti layanan, bukan dengan nol rupiah.
Kesimpulan
Konsultan bukan keharusan, tetapi review independen atas backup, keamanan, dan pemulihan sebaiknya selalu ada.
Banyak perusahaan memulai infrastruktur IT dari kebutuhan kecil: satu server, satu aplikasi, satu tim kecil yang paham semuanya. Lima tahun kemudian server itu sudah menjadi belasan, orang yang paham sudah berpindah, dan tidak ada yang yakin data bisa dipulihkan kalau satu mesin mati. Tulisan ini menjawab pertanyaan yang sering muncul di tahap itu: apa saja yang bisa salah kalau semuanya dikerjakan sendiri, dan di titik mana bantuan dari luar lebih murah daripada belajar dari insiden.
Apa Saja Risiko Utama Membangun Infrastruktur IT Tanpa Konsultan?
Risiko utamanya adalah kesalahan yang tidak terlihat saat sistem normal: backup yang tidak pernah diuji pulih, konfigurasi keamanan yang longgar, perangkat lunak yang tidak diperbarui, dan pengetahuan yang hanya ada di kepala satu atau dua orang. Semuanya baru ketahuan ketika terjadi gangguan.
Tim internal biasanya kuat dalam hal yang mereka pakai setiap hari, seperti aplikasi, database, dan jaringan kantor. Masalah muncul di area yang jarang disentuh. Rencana pemulihan bencana, pemisahan jaringan, pengelolaan akun administrator, dan pemantauan log adalah pekerjaan yang tidak menghasilkan fitur baru, sehingga mudah tergeser oleh tenggat proyek lain.
Konsultan infrastruktur membawa dua hal yang sulit dimiliki tim internal. Pertama, pembanding: mereka sudah melihat banyak konfigurasi yang gagal di perusahaan lain dan tahu pola yang berulang. Kedua, jarak: mereka tidak terikat keputusan lama dan lebih leluasa menyebut bagian yang berisiko.
Risiko ini bersifat kumulatif. Satu backup yang tidak teruji mungkin belum berbahaya, tetapi jika digabung dengan akses administrator yang longgar dan server yang tidak diperbarui, satu gangguan kecil bisa berubah menjadi henti layanan yang jauh lebih besar. Itu sebabnya penilaian infrastruktur lebih bermanfaat dilakukan menyeluruh, bukan per komponen, dan diulang berkala, minimal setahun sekali serta setiap kali ada perubahan besar pada arsitektur atau susunan tim.
Berikut risiko yang paling sering muncul pada infrastruktur yang dibangun tanpa review dari luar.
Backup tanpa uji pemulihan. Salinan data ada, tetapi tidak pernah dicoba dipulihkan, sehingga baru ketahuan rusak atau tidak lengkap saat dibutuhkan.
Satu titik kegagalan. Satu server, satu storage, atau satu jalur internet menopang layanan penting tanpa cadangan.
Akses administrator yang longgar. Akun dengan hak tertinggi dipakai bersama, tanpa autentikasi berlapis dan tanpa catatan siapa melakukan apa.
Dokumentasi yang hilang. Diagram jaringan dan prosedur pemulihan tidak tertulis, sehingga bergantung pada ingatan orang tertentu.
Pembaruan yang tertunda. Sistem operasi dan perangkat lunak dibiarkan pada versi lama karena takut mengganggu layanan.
Kapasitas yang tidak dihitung. Pertumbuhan data dan lalu lintas baru disadari ketika layanan melambat.
Daftar itu tidak berarti tim internal tidak mampu. Artinya, enam hal di atas termasuk jenis pekerjaan yang paling mudah ditunda, dan penundaan itu baru terasa mahal ketika sudah terlambat. Panduan lengkap tentang tahapan, komponen biaya, dan cara memilih mitra ada di Panduan Infrastruktur IT untuk Perusahaan dan BUMN di Indonesia.
Mengapa Backup Sering Terlewat Padahal Fasilitasnya Sudah Ada?
Backup sering terlewat karena dianggap biaya tanpa hasil yang terlihat dan sulit dijelaskan urgensinya kepada pihak yang menyetujui anggaran. Fasilitasnya bisa saja tersedia, tetapi tidak diaktifkan atau tidak dipakai karena tidak ada yang memiliki tanggung jawab jelas atas pencadangan.
Contoh paling terang datang dari pemerintah. Pada Juni 2024, Menteri Komunikasi dan Informatika saat itu, Budi Arie Setiadi, mengatakan banyak instansi tidak melakukan pencadangan karena alasan anggaran. Menurut dia, alasannya adalah “keterbatasan anggaran, atau kesulitan menjelaskan urgensi backup tersebut kepada otoritas keuangan atau auditor”.
Ironisnya, fasilitasnya ada. Ekosistem PDNS 1 dan PDNS 2 memiliki kapasitas pencadangan 5.709 virtual machine, tetapi yang terpakai hanya 1.630 virtual machine atau 28,5 persen dari total kapasitas, menurut keterangan yang sama. Artinya, hambatannya bukan ketiadaan alat, melainkan keputusan, tanggung jawab, dan anggaran untuk memakainya.
Perusahaan swasta menghadapi dinamika yang mirip. Backup tidak punya pemilik bisnis yang jelas, biayanya muncul tiap bulan, dan manfaatnya baru terasa saat terjadi masalah. Dalam rapat anggaran, belanja yang menambah fitur hampir selalu menang atas belanja yang mencegah kerugian yang belum terjadi.
Ada tiga pertanyaan sederhana yang bisa diajukan tanpa bantuan siapa pun. Siapa yang bertanggung jawab atas backup, dan namanya tertulis di mana? Kapan terakhir kali data dipulihkan dari backup sebagai latihan? Berapa lama layanan boleh mati sebelum bisnis terganggu serius? Jika salah satunya tidak terjawab, infrastruktur itu sudah punya celah.
Konsultan independen biasanya memulai dari ketiga pertanyaan itu, karena jawabannya menentukan semua keputusan teknis berikutnya. Bagian ini juga yang paling murah diperiksa: cukup satu sesi review, tanpa membeli perangkat baru.
Cara termurah menghindari jebakan ini adalah memperlakukan backup sebagai bagian dari biaya layanan, bukan proyek tambahan. Ketika backup dihitung sejak awal sebagai komponen tetap, ia tidak perlu dibela ulang tiap tahun di rapat anggaran. Perusahaan juga bisa menetapkan target sederhana, yaitu seberapa banyak data yang boleh hilang dan seberapa lama pemulihan boleh berlangsung, lalu menguji apakah backup yang ada benar-benar memenuhi target itu.
Apa yang Terjadi pada PDNS 2 dan Pelajarannya bagi Perusahaan?
PDNS 2 di Surabaya diserang ransomware Brain Cipher sejak 20 Juni 2024 dan melumpuhkan layanan 282 instansi pemerintah. Pemulihannya bergantung pada backup masing-masing instansi, dan hanya 44 instansi yang disebut siap memulihkan layanan dengan cepat karena backup mereka cukup baik.
Data kronologinya cukup jelas. Pada 24 Juni 2024 pemerintah mengidentifikasi 211 instansi terdampak, lalu pada 25 Juni angkanya menjadi 282. Penyerang meminta tebusan US$ 8 juta, sekitar Rp 131,3 miliar, dan pemerintah menyatakan tidak akan membayarnya. Wakil Menteri Komunikasi dan Informatika Nezar Patria menegaskan, “Kami tidak akan melakukan yang opsi bayar tebusan itu.”
Direktur Network dan IT Solution PT Telkom Indonesia (Persero) Tbk Herlan Wijanarko menyampaikan hal yang paling relevan bagi perusahaan. Pemulihan layanan sepenuhnya bergantung pada backup tiap instansi, karena pengelola pusat data tidak memegang backup dari data yang tersimpan. “Sistem backup-nya disiapkan, tetapi belum dimanfaatkan,” ujarnya pada 26 Juni 2024.
Analisis forensik Badan Siber dan Sandi Negara menemukan adanya upaya menonaktifkan fitur keamanan Windows Defender di PDNS 2. Layanan Imigrasi disebut sebagai yang terdampak paling parah. PDNS 2 dinyatakan pulih 100 persen pada September 2024, sekitar lima bulan sesudah serangan.
Diagram kondisi backup instansi saat PDNS 2 diserang. Diolah Burung Hantu Infratek dari ANTARA, Investortrust, dan detikInet.
Pelajaran bagi perusahaan ada tiga. Backup harus dimiliki oleh pemilik data, bukan diserahkan sepenuhnya ke penyedia infrastruktur. Backup harus berada di jalur yang terpisah dari sistem utama, supaya serangan pada sistem utama tidak ikut mengunci cadangan. Dan pemulihan harus dilatih, karena sepanjang pemulihan 2024 pemerintah juga harus menyisir data yang dipulihkan agar tidak membawa ransomware kembali.
Pemerintah kemudian memperkuat pengaturan pusat data. Peraturan Menteri Komunikasi dan Digital Nomor 18 Tahun 2025, yang ditetapkan pada 23 Desember 2025, mengatur Balai Layanan Pusat Data Nasional. Fungsinya mencakup manajemen layanan untuk penempatan, penyimpanan, pengolahan, dan pemulihan data, serta pengelolaan keamanan pusat data nasional.
Satu catatan agar pelajaran ini tidak disalahartikan. Sumber yang kami buka tidak menyebut bahwa pusat data itu dibangun tanpa konsultan, dan skala PDNS jauh berbeda dari perusahaan pada umumnya. Yang relevan adalah polanya: fasilitas cadangan tersedia, tetapi pemakaiannya diserahkan kepada tiap pemilik data, dan banyak yang belum siap ketika hari itu datang. Pola ini bisa terjadi pada organisasi dengan ukuran berapa pun.
Seberapa Besar Ancaman Serangan Siber yang Dihadapi Infrastruktur Saat Ini?
Ancamannya konstan dan besar. Data dashboard FortiGuard Labs yang dikutip Komdigi menunjukkan 2,2 juta percobaan serangan siber menyasar Indonesia dalam 24 jam hingga Selasa, 10 November 2026, pukul 07.30 WIB. Sebagian besar percobaan semacam itu otomatis dan tidak memilih target.
Pada 8 November 2026, Badan Siber dan Sandi Negara menerbitkan Security Advisory soal ancaman terhadap situs dan layanan pemerintah. Sehari kemudian, Direktorat Jenderal Teknologi Pemerintah Digital Komdigi menerbitkan tiga surat imbauan kepada pengguna layanan PDN-1 dan Government Cloud, pejabat nama domain, dan seluruh penyelenggara sistem elektronik lingkup publik.
BSSN sendiri menyatakan keaslian ancaman dan kemampuan pelakunya belum terverifikasi. Namun Direktur Strategi dan Kebijakan Teknologi Pemerintah Digital Komdigi Aries Kusdaryono menilai langkah antisipasi tetap perlu. “Kita tidak boleh mengabaikan potensi risiko ancaman serangan tersebut,” katanya pada 10 November 2026.
Imbauan itu relevan bagi perusahaan karena daftarnya praktis. Komdigi meminta pengelola sistem memastikan tim tanggap insiden siap, memperkuat autentikasi akun administrator, memperbarui perangkat lunak, meningkatkan perlindungan terhadap serangan DDoS, dan memastikan pencadangan data serta mekanisme pemulihan layanan berjalan dengan baik.
Wakil Menteri Nezar Patria juga menyoroti serangan yang memakai agentic AI, yakni agen yang mengambil keputusan secara mandiri melalui otomatisasi. Menurut dia, “ini suatu hal yang baru dan butuh risk management sendiri”. Bagi perusahaan, artinya laju serangan bisa lebih cepat daripada laju respons tim yang bekerja manual.
Karena sebagian besar percobaan serangan bersifat otomatis, pertahanan yang efektif lebih bergantung pada disiplin dasar daripada perangkat canggih. Akun administrator dengan autentikasi berlapis, pembaruan rutin, pembatasan akses jaringan, dan pemantauan log yang benar-benar dibaca menutup sebagian besar jalan masuk yang paling sering dicoba. Konsultan membantu memastikan disiplin itu berjalan sebagai proses, bukan sekadar daftar niat di dokumen kebijakan.
Poinnya sederhana: ancaman tidak menunggu perusahaan siap. Infrastruktur yang dibangun sendiri tetap harus memenuhi daftar dasar di atas, dan konsultan berguna untuk memastikan daftar itu benar-benar terpenuhi, bukan sekadar dianggap terpenuhi.
Untuk sisi vendor dan kepatuhan keamanan, pembahasan lebih rinci ada di Apa yang Perlu Dipenuhi Vendor IT soal Keamanan Siber Saat RUU KKS Dibahas DPR?
Bagaimana Perangkat Lunak Usang Diam-Diam Menumpuk Risiko?
Perangkat lunak usang menumpuk risiko karena tidak lagi menerima pembaruan keamanan resmi, sementara celahnya terus ditemukan dan dipublikasikan. Server yang masih berjalan normal belum tentu aman, dan justru karena berjalan normal, tidak ada yang merasa perlu menyentuhnya.
Temuan Vaksincom yang dikutip Komdigi memberi gambaran skalanya. Sebanyak 96,7 persen server pemerintah yang terdeteksi masih menggunakan PHP versi End of Life, yaitu versi yang tidak lagi mendapat pembaruan keamanan resmi. Vaksincom memetakan paparan celah kritis PHP2Shell yang memungkinkan pengambilalihan server melalui eksekusi kode jarak jauh tanpa login.
Angka itu menggambarkan server pemerintah, bukan perusahaan swasta, sehingga tidak bisa langsung diterapkan ke semua organisasi. Tetapi polanya sama. Aplikasi dibuat bertahun-tahun lalu, pembuatnya sudah pindah, dan memperbarui versi bahasa pemrogramannya berisiko merusak fitur. Maka keputusan yang paling mudah adalah membiarkannya.
Ada beberapa kebiasaan yang membantu menahan penumpukan itu. Pertama, inventaris: catat semua server, aplikasi, dan versinya dalam satu daftar yang diperbarui berkala. Kedua, jadwal: tetapkan kapan versi tertentu akan dipensiunkan sebelum masa dukungannya berakhir. Ketiga, lingkungan uji: perbarui di lingkungan terpisah dulu agar risiko merusak layanan produksi berkurang.
Contoh sederhana membantu. Bayangkan aplikasi internal yang dibuat lima tahun lalu dengan versi bahasa pemrograman yang saat itu terbaru. Selama tidak ada yang memperbaruinya, jaraknya dari versi yang didukung makin lebar setiap tahun, dan biaya memperbaikinya ikut membesar. Menunda satu pembaruan kecil hari ini sering berarti harus melakukan migrasi besar nanti. Karena itu, memperlakukan pembaruan sebagai pekerjaan rutin berbiaya kecil hampir selalu lebih murah daripada menunggu sampai semuanya harus dilakukan serentak dalam keadaan darurat.
Di titik ini konsultan sering paling membantu, karena inventaris dan peta risiko perlu dikerjakan secara sistematis, bukan di sela pekerjaan lain. Hasilnya berupa daftar prioritas: mana yang harus diperbaiki bulan ini, mana yang bisa menunggu, dan mana yang sebaiknya dimodernisasi sekalian.
Jika aplikasinya sudah terlalu tua untuk diperbarui sedikit demi sedikit, pertimbangkan jalur modernisasi bertahap. Tahapan dan risikonya dibahas di Panduan Modernisasi Aplikasi untuk Perusahaan dan BUMN di Indonesia.
Di Mana Data Perusahaan Boleh Disimpan dan Apa Kata Aturannya?
Untuk perusahaan swasta, aturan yang ada tidak mewajibkan semua data disimpan di dalam negeri. Peraturan Pemerintah Nomor 71 Tahun 2019 memberi ruang menempatkan sistem dan data di luar Indonesia, selama pengawasan dan akses untuk penegakan hukum tetap efektif. Penyelenggara lingkup publik punya syarat yang lebih kuat.
Penjelasan itu disampaikan Ketua Umum Asosiasi Data Center Indonesia, Hendra Suryakusuma, kepada Kontan pada 4 Agustus 2026. Menurut dia, regulasi Indonesia saat ini bukan kewajiban lokalisasi menyeluruh untuk seluruh data sektor privat. Undang-Undang Perlindungan Data Pribadi juga mengatur transfer data pribadi ke luar negeri lewat persyaratan tingkat pelindungan yang setara atau lebih tinggi.
Asosiasi itu mendorong pendekatan berbasis risiko dan klasifikasi data. Data pemerintahan, infrastruktur kritis, data strategis nasional, serta data pribadi sensitif perlu tingkat pelindungan dan persyaratan lokasi yang lebih kuat. Untuk data yang tidak strategis, transfer lintas batas tetap dimungkinkan selama standar keamanan dan pelindungan data terpenuhi.
Perdebatan soal ini masih berjalan. Pada 27 April 2026, pendiri Sobat Cyber Indonesia, Al Akbar Rahmadillah, meminta kebijakan fleksibilitas lokasi data di PP 71/2019 dievaluasi ulang dari sudut kedaulatan data dan ketahanan nasional. Dari sumber yang kami buka, belum ada dokumen resmi yang menyatakan peraturan itu direvisi atau dicabut.
Bagi perusahaan yang membangun infrastruktur sendiri, pertanyaan lokasi data layak dijawab secara tertulis sejak awal. Klasifikasikan data menurut sensitivitasnya, tentukan mana yang wajib berada di dalam negeri karena aturan sektor atau kontrak, dan dokumentasikan alasannya. Keputusan yang tidak tertulis cenderung diputuskan ulang setiap kali ada orang baru.
Konsekuensi praktisnya, kontrak dengan penyedia cloud atau pusat data sebaiknya menyebut lokasi penyimpanan, lokasi backup, dan hak audit secara eksplisit. Banyak perusahaan baru menyadari lokasi backup ketika diminta klien atau auditor. Menanyakannya di awal jauh lebih murah daripada memindahkan data setelah sistem berjalan, terutama jika data itu mencakup data pribadi pelanggan atau karyawan.
Soal tanggung jawab atas data pribadi ketika proyek dikerjakan pihak ketiga, pembahasannya ada di Siapa yang Bertanggung Jawab atas Data Pribadi Saat Proyek IT Dikerjakan Vendor?
Kapan Membangun Sendiri Masih Masuk Akal dan Kapan Perlu Konsultan?
Membangun sendiri masuk akal untuk sistem sederhana yang tidak kritis, dengan tim yang berpengalaman dan waktu untuk merawatnya. Konsultan sebaiknya dilibatkan ketika sistem menopang layanan inti, menyimpan data sensitif, atau harus memenuhi aturan dan audit yang ketat.
Tidak ada rumus tunggal, tetapi beberapa pertanyaan membantu memutuskan. Seberapa mahal satu jam layanan mati bagi bisnis? Apakah ada orang di tim yang pernah memulihkan sistem sejenis dari kegagalan nyata? Apakah ada pihak luar yang akan menilai, seperti auditor, regulator, atau klien besar? Semakin banyak jawaban “ya”, semakin kuat alasan memakai pembanding dari luar.
Ukuran perusahaan bukan penentu utama. Perusahaan kecil dengan satu sistem inti yang menopang seluruh pendapatan bisa lebih rentan daripada perusahaan besar yang punya banyak sistem cadangan. Yang menentukan adalah ketergantungan bisnis pada sistem itu dan seberapa cepat tim bisa memulihkannya. Jika tim ragu menjawab berapa lama pemulihan bisa dilakukan, itu pertanda pemulihan belum pernah diuji, dan pertanda itu cukup untuk memulai percakapan dengan pihak luar.
Perlu ditekankan bahwa konsultan tidak harus mengambil alih pekerjaan. Bentuk yang paling hemat sering berupa review: konsultan memeriksa desain, backup, keamanan, dan dokumentasi, lalu memberi daftar temuan berperingkat, sementara tim internal tetap membangun dan merawat.
Berikut situasi yang biasanya menjadi pemicu paling jelas untuk melibatkan konsultan.
Sebelum membangun. Desain arsitektur dan perhitungan kapasitas diperiksa pihak kedua, saat perubahan masih murah.
Sebelum audit atau tender. Klien besar, BUMN, dan regulator sering meminta bukti kontrol keamanan dan rencana pemulihan.
Setelah pergantian tim. Dokumentasi yang hilang perlu direkonstruksi sebelum menjadi masalah.
Setelah insiden atau nyaris insiden. Analisis akar masalah dari pihak independen lebih mudah diterima semua pihak.
Saat memilih vendor. Penilaian teknis penawaran butuh pengalaman yang tidak selalu dimiliki tim internal.
Memilih mitra juga punya risiko sendiri, terutama soal kedekatan dengan vendor dan konflik kepentingan. Perbandingan vendor lokal dan luar negeri dibahas di Lebih Baik Software House Lokal atau Outsourcing Luar Negeri untuk Sistem Perusahaan?
Bagaimana Menimbang Biaya Konsultan Dibanding Biaya Insiden?
Bandingkan biaya konsultasi dengan kerugian akibat layanan berhenti, bukan dengan nol rupiah. Biaya konsultasi pasti dan terbatas, sedangkan biaya insiden tidak pasti tetapi bisa jauh lebih besar, mencakup pemulihan, hilangnya pendapatan, denda, dan kepercayaan pelanggan.
Kasus PDNS 2 menunjukkan bahwa kerugian tidak berhenti pada tebusan yang diminta. Tebusan US$ 8 juta tidak dibayar, tetapi layanan 282 instansi terganggu, proses pemulihan memakan waktu berbulan-bulan, dan Direktur Jenderal Aplikasi Informatika saat itu mengundurkan diri pada 4 Juli 2024. Dampak ke reputasi dan kepercayaan publik tidak punya angka, tetapi nyata.
Untuk perusahaan, perhitungan yang berguna terdiri dari beberapa komponen. Perkirakan pendapatan atau produktivitas yang hilang per jam layanan mati, kalikan dengan waktu pemulihan yang realistis, lalu tambahkan biaya tenaga ahli darurat dan potensi denda kontrak. Angka itu dibandingkan dengan biaya review tahunan.
Hitungan ini juga menjelaskan mengapa backup layak dibela di rapat anggaran. Budi Arie menyebut kesulitan menjelaskan urgensi backup kepada auditor sebagai salah satu penyebab instansi tidak mencadangkan data. Perusahaan bisa menghindarinya dengan menuliskan urgensi itu dalam bahasa bisnis: berapa jam layanan boleh mati, dan berapa biayanya jika melewati batas itu.
Perusahaan yang berkontrak dengan BUMN atau klien besar juga perlu memperhitungkan sisi bukti. Dalam tender, pertanyaan tentang rencana pemulihan bencana dan kontrol keamanan bisa diminta secara tertulis. Laporan review dari pihak independen menjadi dokumen yang dapat ditunjukkan, sehingga manfaatnya tidak hanya mencegah insiden, tetapi juga membantu membangun kepercayaan calon klien. Biaya review kemudian bisa dihitung sebagai bagian dari biaya kepatuhan dan penjualan, bukan semata biaya teknis. Dengan cara pandang itu, keputusan tidak lagi berupa memilih antara hemat dan boros, melainkan memilih risiko mana yang siap ditanggung perusahaan.
Langkah awal yang realistis ada tiga. Tentukan pemilik backup dan pemulihan secara tertulis. Jadwalkan satu latihan pemulihan penuh dalam tiga bulan ke depan. Lalu minta review independen atas desain dan keamanan, minimal untuk sistem yang paling kritis. Ketiganya tidak menuntut investasi besar, tetapi menutup celah yang paling sering berujung pada krisis.
Pertanyaan yang Sering Diajukan
Apa risiko membangun infrastruktur IT sendiri tanpa konsultan?
Risiko utamanya ada pada hal yang tidak terlihat sehari-hari: backup yang tidak pernah diuji, akses administrator yang longgar, perangkat lunak yang tidak diperbarui, titik kegagalan tunggal, dan dokumentasi yang hanya ada di ingatan orang tertentu. Semuanya baru terasa saat terjadi insiden.
Apakah perusahaan wajib memakai konsultan untuk membangun infrastruktur IT?
Dari sumber yang kami buka, tidak ada aturan umum yang mewajibkan perusahaan swasta memakai konsultan. Namun sistem kritis, data sensitif, atau kewajiban audit membuat review independen sangat dianjurkan, karena membuktikan kontrol keamanan dan rencana pemulihan kepada klien, auditor, atau regulator.
Berapa banyak instansi yang punya backup saat PDNS 2 diserang?
Pada 26 Juni 2024, Wakil Menteri Komunikasi dan Informatika Nezar Patria menyebut sekitar 44 instansi bisa memulihkan layanan karena backup mereka cukup baik, sedangkan sekitar 238 instansi masih dalam pemantauan. Total instansi terdampak yang teridentifikasi pada 25 Juni 2024 adalah 282.
Apakah data perusahaan swasta harus disimpan di Indonesia?
Menurut penjelasan Asosiasi Data Center Indonesia kepada Kontan pada 4 Agustus 2026, PP 71 Tahun 2019 memberi ruang penempatan data swasta di luar negeri selama pengawasan dan penegakan hukum tetap efektif. Penyelenggara lingkup publik dan data sensitif punya syarat lebih kuat.
Apa langkah pertama yang paling murah untuk mengurangi risiko infrastruktur?
Tetapkan pemilik backup secara tertulis, lalu lakukan satu latihan pemulihan penuh dari backup ke sistem uji. Latihan itu tidak memerlukan perangkat baru dan langsung menunjukkan apakah backup bisa dipakai, berapa lama pemulihan berlangsung, dan bagian mana yang belum terdokumentasi.
Kesimpulan
Membangun infrastruktur IT sendiri bukan kesalahan. Banyak perusahaan melakukannya dengan baik. Yang berisiko adalah membangunnya tanpa pembanding, karena bagian yang paling mudah terlewat, yaitu backup, pemulihan, pembaruan, dan dokumentasi, justru bagian yang menentukan nasib perusahaan pada hari terburuk. Kasus PDNS 2 memperlihatkan bahwa fasilitas yang tersedia tidak otomatis terpakai, dan hanya instansi yang punya backup sendiri yang bisa pulih cepat.
Langkah berikutnya tidak perlu besar. Tetapkan pemilik backup, latih pemulihan, inventarisasi versi perangkat lunak, dan minta review independen untuk sistem yang paling kritis. Jika Anda ingin membandingkan opsi dan komponen biaya secara lebih lengkap, mulailah dari Panduan Infrastruktur IT untuk Perusahaan dan BUMN di Indonesia, lalu tentukan bagian mana yang cukup dikerjakan sendiri dan bagian mana yang perlu mata kedua.
(Burung Hantu Infratek / Berbagai Sumber)
⚠️ Artikel ini seluruhnya diriset, ditulis, dan dikembangkan oleh AI internal Burung Hantu Infratek.
🦉 Burung Hantu Infratek adalah software house dan system integrator yang sudah berpengalaman lebih dari 5 tahun dalam pengembangan dan implementasi generative AI pada berbagai perusahaan dan institusi.
Sumber dan Referensi
[1] Komdigi Minta Instansi Pemerintah Waspada Ancaman Serangan Hacker - Katadata
[2] Kemenkominfo Bakal Wajibkan Instansi Pemerintah Buat Backup Data - Investortrust
[3] Telkom: Data Pemerintah yang Diserang Ransomware Tak Bisa Dipulihkan - Investortrust
[4] 44 instansi sudah migrasi data pulihkan layanan imbas PDNS 2 - ANTARA
[5] Jejak Horor Serangan Ransomware di Indonesia dari PDNS sampai BSI - detikInet
[6] IDPRO: Regulasi Residensi Data Jangan Hambat Industri Data Center Nasional - Kontan
[7] Sobat Cyber Ingin Kedaulatan Data RI, Soroti PP 71/2019 - Republika