--- title: "Panduan Respons Insiden Siber untuk Bisnis" description: "Menyusun rencana respons insiden siber: tahapan ala NIST, pembagian peran, daftar kontak termasuk BSSN, latihan tabletop, dan kewajiban pelaporan." url: "https://nivelva.com/insight/panduan-respons-insiden-siber" category: "Keamanan/Cyber Security" tags: ["respons insiden","incident response","nist","bssn","tabletop exercise"] author: "Theresia Candiawan" published: "2026-11-07T09:23:00+07:00" updated: "2026-11-07T09:23:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Panduan Respons Insiden Siber untuk Bisnis > **Jawaban singkat:** Rencana respons insiden menjawab siapa melakukan apa saat serangan terjadi. Ikuti alur persiapan, deteksi dan analisis, penahanan, pembersihan, pemulihan, dan pelajaran. Siapkan peran, daftar kontak termasuk Pusat Kontak Siber BSSN, latihan tabletop, dan alur notifikasi 3x24 jam sesuai UU PDP. Rencana respons insiden yang baik ditulis pada hari yang tenang, bukan pada malam ketika server terkunci ransomware. Isinya sederhana: siapa yang memimpin, langkah apa yang diambil lebih dulu, siapa yang harus dihubungi, dan bagaimana bisnis kembali berjalan. Dokumen satu sampai tiga halaman yang benar-benar dibaca tim jauh lebih berguna daripada manual tebal yang tersimpan di folder. Kalau timmu kecil dan belum punya rencana formal, bagian-bagian di bawah bisa langsung diadaptasi. Kerangkanya mengikuti pedoman NIST yang banyak dipakai, disesuaikan dengan konteks Indonesia seperti pelaporan ke BSSN dan kewajiban UU PDP. Informasi kontak dan regulasi ditulis per 4 November 2026. ## Apa yang dimaksud insiden siber? Tidak setiap kejadian aneh adalah insiden. NIST membedakan **event** (kejadian yang teramati, misalnya percobaan login), **adverse event** (kejadian yang berdampak negatif), dan **incident** (kejadian yang benar-benar atau hampir pasti membahayakan kerahasiaan, integritas, atau ketersediaan informasi, atau melanggar kebijakan keamanan). Contoh insiden yang relevan untuk bisnis antara lain: ransomware yang mengenkripsi file, akun admin atau email yang diambil alih lewat phishing, website disusupi halaman judi, kebocoran database pelanggan, serangan DDoS yang membuat layanan tidak bisa diakses, dan penyalahgunaan akun vendor atau layanan cloud. Membuat kriteria yang jelas membantu tim memutuskan kapan rencana insiden diaktifkan, dan mencegah dua kesalahan: panik untuk hal kecil, atau menganggap remeh hal yang serius. ## Kerangka NIST: dari siklus lama ke CSF 2.0 Pedoman NIST SP 800-61 sudah lama menjadi rujukan respons insiden. Revisi 2 (2012) memperkenalkan siklus empat tahap: persiapan; deteksi dan analisis; penahanan, pembersihan, dan pemulihan; serta aktivitas pascainsiden. Pada April 2025, NIST menerbitkan **SP 800-61 Revisi 3** yang menggantikan revisi 2 dan menyelaraskan respons insiden dengan enam fungsi NIST Cybersecurity Framework (CSF) 2.0: Govern, Identify, Protect, Detect, Respond, dan Recover. Menurut NIST, Govern, Identify, dan Protect membantu mencegah sebagian insiden, mempersiapkan penanganan, dan memperbaiki praktik dari pelajaran insiden. Detect, Respond, dan Recover membantu menemukan, mengelola, memprioritaskan, menahan, membersihkan, dan memulihkan insiden, termasuk pelaporan dan komunikasi. NIST juga menyarankan organisasi memakai model siklus yang paling cocok untuknya. Untuk tim kecil, tahapan klasik tetap paling mudah dipraktikkan. Tabel ini menyandingkannya dengan fungsi CSF 2.0. | Tahap praktis | Fungsi CSF 2.0 terkait | Pertanyaan kunci | |:--|:--|:--| | Persiapan | Govern, Identify, Protect | Siapa melakukan apa? Aset apa yang paling penting? | | Deteksi dan analisis | Detect | Apa yang terjadi, sejak kapan, seberapa luas? | | Penahanan | Respond | Bagaimana menghentikan penyebaran tanpa menghapus bukti? | | Pembersihan | Respond | Celah apa yang dipakai dan sudahkah ditutup? | | Pemulihan | Recover | Bagaimana kembali beroperasi dengan aman? | | Pelajaran | Govern, Identify, Protect | Apa yang perlu diubah agar tidak terulang? | ## Tahap 1: Persiapan Banyak hal yang menentukan keberhasilan respons disiapkan sebelum insiden terjadi. Yang perlu disiapkan: - **Daftar aset penting**: website, server, database pelanggan, email, akun cloud, domain, dan sistem keuangan, beserta pemiliknya. - **Backup yang teruji**, disimpan terpisah dari sistem utama dan punya beberapa versi ke belakang. Pengaturannya dibahas di [backup website otomatis](https://nivelva.com/insight/backup-website-otomatis). - **Log yang cukup**: log akses web, login, dan sistem disimpan cukup lama dan, bila mungkin, di tempat terpisah agar tidak dihapus pelaku. - **Akses darurat**: akun admin cadangan dengan 2FA yang disimpan aman, serta akses ke registrar domain dan panel penyedia. - **Peran dan kontak**, dibahas di bagian berikutnya. ### Peran dalam tim respons Bahkan tim tiga orang perlu pembagian yang jelas. | Peran | Tanggung jawab | Siapa di tim kecil | |:--|:--|:--| | Pemimpin insiden | Mengambil keputusan, menjaga prioritas, mencatat linimasa | Pemilik usaha atau manajer IT | | Teknis | Investigasi, penahanan, pembersihan, pemulihan | Admin internal atau vendor IT | | Komunikasi | Pesan ke pelanggan, mitra, dan publik | Pemilik atau kepala pemasaran | | Hukum dan kepatuhan | Menilai kewajiban pelaporan dan notifikasi | Konsultan hukum atau penanggung jawab PDP | | Pencatat | Mencatat setiap keputusan dan tindakan beserta waktunya | Siapa pun yang tidak sedang memegang teknis | Tulis nama, nomor cadangan, dan siapa penggantinya bila orang utama tidak bisa dihubungi. ## Tahap 2: Deteksi dan analisis Insiden biasanya terlihat dari tanda yang samar: pelanggan mengeluh dialihkan ke situs lain, email ditolak, server tiba-tiba berat, atau ada akun admin baru. Gejala umum website yang diretas dirangkum di [tanda website diretas](https://nivelva.com/insight/tanda-website-diretas), dan cara membaca jejaknya ada di [membaca log server untuk deteksi serangan](https://nivelva.com/insight/log-server-deteksi-serangan). Saat analisis, jawab pertanyaan dasar: sistem apa yang terdampak, sejak kapan, data apa yang mungkin terlibat, dan apakah serangan masih berlangsung. Catat semuanya dengan waktu yang jelas. Catatan ini nanti dibutuhkan untuk pelaporan, klaim asuransi bila ada, dan pelajaran pascainsiden. > **Amankan bukti sebelum membersihkan:** > > Menghapus file atau install ulang terlalu cepat bisa menghilangkan jejak yang menunjukkan cara pelaku masuk. Sebelum mengubah apa pun, buat salinan log, file, dan database, atau snapshot server bila tersedia. ## Tahap 3 sampai 5: Penahanan, pembersihan, pemulihan ### Penahanan Tujuannya menghentikan kerusakan agar tidak meluas. Contohnya: memutus server yang terinfeksi dari jaringan, menonaktifkan akun yang diambil alih, mengganti kredensial yang mungkin bocor, mengaktifkan mode perawatan website, atau memblokir IP dan pola lalu lintas tertentu di WAF. Penahanan jangka pendek boleh kasar asalkan bukti sudah diamankan. ### Pembersihan Setelah tertahan, cari dan tutup akar masalahnya: celah software, password yang bocor, backdoor, atau akun asing. Tanpa langkah ini, pelaku bisa masuk lagi dengan cara yang sama. Untuk kasus website yang dipenuhi halaman judi, langkah pembersihannya dibahas di [website disusupi konten judi online](https://nivelva.com/insight/website-disusupi-judi-online). ### Pemulihan Kembalikan layanan dari sumber yang bersih, misalnya backup sebelum insiden atau instalasi ulang dari sumber resmi, lalu pantau lebih ketat beberapa minggu setelahnya. Pulihkan bertahap mulai dari sistem paling kritis, dan pastikan pembaruan keamanan sudah terpasang sebelum sistem dibuka lagi ke publik. ## Daftar kontak darurat dan pelaporan ke BSSN Simpan daftar ini di tempat yang tetap bisa diakses bila sistem utama mati, misalnya dokumen cetak atau catatan di ponsel. - **Internal**: pemimpin insiden, tim teknis, manajemen, konsultan hukum. - **Penyedia**: hosting atau cloud, registrar domain, penyedia email, vendor aplikasi, penyedia layanan keamanan bila ada. - **Eksternal**: bank atau penyedia pembayaran bila transaksi terdampak, asuransi siber bila ada, dan aparat penegak hukum bila ada unsur pidana. Di Indonesia, BSSN (Badan Siber dan Sandi Negara) menyediakan **Pusat Kontak Siber** untuk aduan insiden. Per 4 November 2026, halaman resminya mencantumkan kanal berikut: - Email: bantuan70@bssn.go.id - WhatsApp dan telepon: 0811-1065-2018 - Layanan khusus: 183 - Portal aduan: aduansiber.bssn.go.id - Telegram: t.me/Id_SIRTII Halaman tersebut meminta identitas pelapor dan formulir Pusat Kontak Siber, serta data teknis seperti aset dan sistem elektronik terdampak, topologi jaringan, atau informasi kerentanan. Menurut standar layanannya, verifikasi persyaratan dilakukan paling lambat 24 jam sejak dokumen diterima, dan respons analisis awal paling lambat 72 jam sejak permohonan dinyatakan valid. Cek halaman resmi BSSN sebelum memasukkan kontak ke rencanamu, karena kanal bisa berubah. ## Kewajiban pelaporan dan notifikasi Bila insiden melibatkan data pribadi, UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi (Pasal 46) mewajibkan pengendali memberi pemberitahuan tertulis **paling lambat 3 x 24 jam** kepada subjek data dan lembaga, berisi data yang terungkap, kapan dan bagaimana terjadi, serta upaya penanganan dan pemulihan. Dalam hal tertentu, masyarakat juga harus diberi tahu. Rinciannya ada di [panduan kepatuhan UU PDP](https://nivelva.com/insight/panduan-kepatuhan-uu-pdp). Sektor tertentu, seperti keuangan, kesehatan, dan telekomunikasi, bisa punya kewajiban pelaporan tambahan dari regulator masing-masing. Petakan kewajiban ini saat persiapan, bukan saat insiden. Siapkan juga templat pemberitahuan untuk pelanggan dengan bahasa yang jujur dan jelas: apa yang terjadi, data apa yang terdampak, apa yang sudah dilakukan, dan apa yang perlu dilakukan pelanggan. ## Bagaimana menguji rencana lewat latihan tabletop? Latihan tabletop adalah simulasi diskusi. Tim duduk bersama, fasilitator membacakan skenario, lalu tim menjelaskan apa yang akan dilakukan di setiap tahap. Tidak ada sistem yang disentuh. 1. Pilih skenario realistis, misalnya "email direktur diambil alih dan dipakai meminta transfer dana" atau "website menampilkan halaman judi di Google". 2. Undang semua peran, termasuk manajemen dan komunikasi, bukan hanya tim teknis. 3. Bacakan skenario bertahap dan tambahkan kejutan, misalnya pemimpin insiden tidak bisa dihubungi. 4. Catat di mana tim ragu: kontak yang hilang, akses yang tidak dimiliki, keputusan yang tidak jelas pemiliknya. 5. Perbarui rencana berdasarkan temuan, lalu jadwalkan latihan berikutnya. Untuk tim kecil, latihan berkala, misalnya dua kali setahun, sudah membantu. Contoh temuan yang mungkin muncul: tidak ada yang tahu siapa pemegang akses registrar domain. ## Pelajaran pascainsiden Setelah keadaan normal, adakan pertemuan tanpa mencari kambing hitam. Bahas linimasa, apa yang berjalan baik, apa yang lambat, dan apa yang perlu diubah: kebijakan, konfigurasi, pelatihan, atau alat. Hasilnya dimasukkan kembali ke tahap persiapan. Inilah yang membuat respons berikutnya lebih cepat. Gambaran lapisan pencegahannya ada di [panduan lengkap keamanan website untuk bisnis](https://nivelva.com/insight/panduan-keamanan-website-bisnis). ## Pertanyaan yang sering diajukan ### Apakah bisnis kecil perlu rencana respons insiden? Perlu, dalam bentuk sederhana. Satu sampai tiga halaman berisi peran, kontak, langkah awal, dan lokasi backup sudah sangat membantu saat panik. Yang penting semua orang tahu dokumennya ada dan di mana. ### Haruskah server langsung dimatikan saat diretas? Tidak selalu. Mematikan server bisa menghilangkan bukti di memori dan mengganggu layanan. Biasanya lebih baik memutus akses jaringan atau membatasi akses publik, mengamankan bukti, lalu memutuskan langkah berikutnya. ### Apakah wajib melapor ke BSSN? Kewajiban pelaporan bergantung pada sektor dan jenis penyelenggara. Di luar kewajiban, Pusat Kontak Siber BSSN bisa dimanfaatkan untuk aduan dan bantuan. Untuk insiden yang melibatkan data pribadi, kewajiban notifikasi 3x24 jam menurut UU PDP tetap berlaku. ### Bagaimana jika pelaku meminta tebusan? Libatkan manajemen, konsultan hukum, dan aparat penegak hukum sebelum mengambil keputusan. Membayar tebusan tidak menjamin data kembali atau tidak disebarkan. Backup yang terpisah dan teruji adalah pertahanan yang jauh lebih bisa diandalkan. ### Seberapa sering rencana perlu diperbarui? Setiap ada perubahan tim, vendor, atau sistem penting, dan setelah setiap latihan atau insiden. Tinjauan berkala, misalnya setiap enam bulan, membantu menjaga kontak tetap akurat. ## Sumber - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/panduan-respons-insiden-siber Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com