Tetapkan apa saja yang termasuk dalam “situs web”
Mulai dengan inventaris layanan. Untuk setiap situs, portal, toko, atau kampanye, catat pemilik bisnis, pemilik teknis, akun hosting, kontrol domain dan DNS, repositori, penyimpanan konten dan media, integrasi, dan kredensial penting. Tandai apa yang bisa dibangun ulang dari version control dan apa yang menyimpan catatan unik.
Sertakan konfigurasi secara sengaja: pengalihan (redirect), pengaturan CDN atau firewall, job terjadwal, template, dan berkas infrastructure-as-code. Jangan menyalin rahasia langsung ke manifesto umum; arahkan ke sistem rahasia yang disetujui dan proses akses darurat. Dokumentasi WordPress menunjukkan celah umum: situs tipikal memerlukan berkas dan basis data terpisah.
Definisikan versi terkecil yang aman yang dapat menyediakan informasi atau transaksi esensial.
Berikan ekspor basis data, berkas, media, dan konfigurasi yang kompatibel satu cap waktu atau label versi.
Tentukan frekuensi dan retensi berdasarkan toleransi bisnis
Pilih frekuensi berdasarkan laju dan nilai perubahan. Tuliskan RPO dalam bahasa sederhana, lalu periksa bahwa setiap penyimpanan unik ditangkap cukup sering. Salinan berkas malam‑hari tidak memenuhi RPO empat jam untuk basis data yang berubah cepat.
Tetapkan RTO secara terpisah. Sertakan persetujuan, infrastruktur bersih, pemulihan, validasi, perubahan lalu lintas, dan komunikasi internal. Ukur melalui latihan daripada menerima klaim vendor. Simpan poin lama cukup lama agar dapat dicapai sebelum kesalahan atau penemuan terlambat, lalu tinjau retensi dengan spesialis privasi, arsip, atau legal bila data mengharuskannya.
Bandingkan interval antar titik pemulihan lengkap dengan RPO setiap layanan.
Verifikasi orang yang berwenang dapat menemukan titik pemulihan berizin yang lebih tua.
Pisahkan dan lindungi salinan pemulihan
Gunakan beberapa salinan di lokasi atau layanan berbeda sehingga satu akun, kejadian lokal, atau kesalahan tidak menghapus semua opsi. CISA merekomendasikan cadangan otomatis reguler, salinan off‑site, enkripsi, dan salinan offline. NCSC menyarankan menghindari perangkat cadangan yang selalu terhubung dan merekomendasikan lebih dari satu solusi atau lokasi cadangan.
Lindungi administrasi cadangan dengan prinsip least privilege, autentikasi multi‑faktor bila didukung, akun admin terpisah, dan peninjauan akses. Gunakan proteksi penghapusan, riwayat versi, atau penyimpanan immutable hanya setelah memahami biaya dan perilaku pemulihannya. Enkripsikan data yang disimpan dan uji penjagaan kunci. Enkripsi tanpa kunci yang dapat dijangkau tidak dapat digunakan; akses yang dibagi luas melemahkan setiap salinan.
Salinan harus memiliki mode kegagalan yang bermakna berbeda dari produksi.
Daftarkan siapa yang dapat membaca, mengubah, menghapus, dan memulihkan cadangan; hapus akses usang.
Tulis runbook pemulihan dan tetapkan otoritas
Runbook adalah prosedur pemulihan yang telah diuji. Simpan salinannya dapat dijangkau tanpa situs yang terpengaruh, penyedia identitas produksi, atau sistem chat normal. Sertakan kontak dan alternatif, otoritas, prioritas sistem, lokasi cadangan, prasyarat, urutan pemulihan, pemeriksaan validasi, dan kondisi penghentian.
Tunjuk pemilik pemulihan yang bertanggung jawab dan pengganti untuk setiap layanan kritis. Definisikan siapa yang memberi otorisasi pemulihan ke produksi, perubahan DNS, dan validasi data bisnis. Jika melibatkan data kartu pembayaran, data sensitif pribadi, atau catatan yang diatur, dapatkan tinjauan keamanan, privasi, legal, dan bila relevan PCI sebelum memutuskan apa yang dipertahankan, diberitahukan, atau dipulihkan.
Catat titik pemulihan yang dipilih, orang yang menyetujui, sistem yang disentuh, hasil validasi, dan pengecualian.
Dokumentasikan akses darurat yang terkontrol; jangan pernah mengandalkan perangkat atau ingatan satu karyawan.
Pulihkan dengan aman setelah kecurigaan kompromi
Jangan otomatis menimpakan produksi dengan salinan terbaru ketika akses tidak sah, malware, atau penghapusan mencurigakan mungkin terjadi. Ikuti proses insiden, nilai akun dan cadangan yang mungkin terpengaruh, pilih titik berdasarkan bukti, dan bangun atau isolasi lingkungan pemulihan sebelum menghubungkannya kembali.
CISA mengarahkan pemulihan menurut prioritas layanan kritis dan memperingatkan agar tidak menyebarkan kembali infeksi ke sistem bersih. NCSC merekomendasikan menghubungkan cadangan hanya ke perangkat yang sudah dipastikan bersih dan memindainya sebelum pemulihan. Langkah‑langkah ini mengurangi risiko, bukan menjamin kebersihan. Tingkatkan ke bantuan respons insiden berkualifikasi jika investigasi, pengawetan bukti, atau kewajiban pemberitahuan mungkin berlaku.
Pulihkan layanan berkepentingan tertinggi pada infrastruktur bersih, validasi, lalu lanjutkan sesuai urutan ketergantungan.
Periksa alur pengguna, data, job, integrasi, administrasi, logging, dan cakupan cadangan baru.
Gunakan latihan (drill) sebagai bukti dan masukan perbaikan
Jalankan pemulihan parsial, rekonstruksi penuh terisolasi, latihan kehilangan ketergantungan, atau simulasi meja menurut tingkat risiko. Mulai dengan tes yang aman dan bermakna lalu tingkatkan realisme seiring waktu. CISA merekomendasikan tes pemulihan penuh dan parsial; NCSC merekomendasikan latihan untuk memperjelas peran, tanggung jawab pihak ketiga, dan prioritas.
Ukur usia titik pemulihan terhadap RPO dan waktu pemulihan yang berlalu terhadap RTO. Catat pengenal set, peserta, hasil validasi, langkah yang gagal, dan pemilik untuk tiap perbaikan. Uji ulang setelah menutup celah dan setelah perubahan material pada platform, identitas, basis data, atau penyedia. SIU dapat mengorganisasikan kerja remediasi pencegahan ini; ini bukan sistem cadangan atau layanan pemantauan langsung.
Simpan catatan ringkas tentang apa yang dipulihkan, di mana, apa yang lolos, apa yang gagal, dan siapa yang menerimanya.
Ulangi pengujian fokus setelah perubahan arsitektur atau pemasok yang material.