# BCP dan DRP: persiapan pemulihan layanan digital Sumber diperiksa. Metode: https://kompli.id/metodologi/. Tentukan pekerjaan yang harus tetap berjalan saat sistem terganggu, lalu siapkan cara memulihkannya. Cadangan data perlu diuji bersama aplikasi, akses, dan pihak yang menjalankan layanan. URL kanonis: https://kompli.id/panduan/kelangsungan-usaha/bcp-drp-layanan-digital/ Sumber diakses: 2026-09-29 Diperbarui: 2026-09-29 Penulis: Kompli Sumber diperiksa: 2026-09-29 ## Apa bedanya BCP dan DRP? **BCP mengatur kelangsungan pekerjaan bisnis; DRP berfokus pada pemulihan sistem yang mendukungnya.** *Business continuity plan* (BCP) dapat mencakup layanan sementara, pembagian tugas, pemasok, dan komunikasi. *Disaster recovery plan* (DRP) membahas bagaimana sistem dipulihkan ketika gangguan besar terjadi. NIST SP 800-34 Rev. 1 membedakan keduanya. Dalam dokumen itu, DRP khusus membahas pemulihan yang memerlukan lokasi alternatif; rencana pemulihan sistem yang lebih luas disebut *information system contingency plan* (ISCP). Sepakati lingkupnya sebelum memakai nama dokumen yang sama dengan vendor. Panduan NIST ditulis untuk sistem pemerintah federal Amerika Serikat. Di sini, konsepnya dipakai sebagai rujukan teknis, bukan kewajiban hukum Indonesia. Langkah dan contoh berikut adalah saran persiapan Kompli; ketentuan sektor dan kontrak tetap perlu diperiksa tersendiri. ## Mulai dari dampak gangguan Pilih satu layanan, misalnya penerimaan pesanan. Ajak pemilik proses dan tim teknis membahas dampak jika layanan berhenti, siapa yang terdampak, serta pekerjaan yang harus diprioritaskan. Ini bagian dari analisis dampak bisnis atau *business impact analysis* (BIA), dibahas dalam NIST bagian 3.2. Catat ketergantungannya: database, identitas pengguna, jaringan, tenaga pelaksana, dan pihak lain. Sistem yang terlihat kurang penting bisa menjadi prasyarat untuk memulihkan layanan utama. Periksa pula apakah pekerjaan sementara benar-benar bisa dijalankan tanpa menambah kesalahan atau membuka data kepada pihak yang tidak berwenang. Sebagai bahan rapat, jawab tiga pertanyaan: berapa lama proses bisa terhenti, layanan minimum apa yang masih dibutuhkan, dan siapa yang boleh mengaktifkan cara kerja sementara. Dasarkan jawaban pada dampak, bukan sekadar paket cadangan yang sudah dibeli. ## RTO dan RPO menjawab pertanyaan berbeda **RTO (*recovery time objective*)** adalah sasaran batas waktu sistem boleh tidak tersedia sebelum dampaknya tidak dapat diterima. Tentukan kapan pengukuran dimulai dan kondisi apa yang dianggap sudah pulih. **RPO (*recovery point objective*)** adalah sasaran titik waktu data yang harus bisa dipulihkan. Dalam perencanaan, ini membantu menyatakan seberapa jauh data terbaru boleh hilang. RPO bukan waktu yang diperlukan untuk menjalankan pemulihan. NIST bagian 3.2.1 juga membedakan RTO dari total waktu gangguan proses yang dapat ditoleransi. Proses bisnis mungkin masih perlu mengecek atau mengolah ulang transaksi setelah sistem menyala. **Data sampai kapan, sistem pulih kapan?** Contoh fiktif: gangguan pukul 10.00, dengan RPO 15 menit dan RTO dua jam. 1. **09.45 — Titik data minimum:** Data yang dipulihkan setidaknya harus mencapai waktu ini. 2. **10.00 — Gangguan dimulai:** Awal pengukuran yang disepakati dalam contoh ini. 3. **12.00 — Batas target pulih:** Sistem ditargetkan tersedia kembali paling lambat pada waktu ini. - **RPO · 15 menit:** 09.45 → 10.00: seberapa jauh data terbaru boleh hilang. - **RTO · 2 jam:** 10.00 → 12.00: berapa lama sistem boleh tidak tersedia. Urutan waktu tidak digambar menurut skala. Angka ini target contoh, bukan hasil uji, batas wajib, atau rekomendasi untuk semua bisnis. Rujukan: [NIST SP 800-34 Rev. 1, bagian 3.2.1](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf). Jika hasil uji baru dapat memulihkan data sampai pukul 09.00, sasaran RPO belum tercapai meskipun aplikasi sudah bisa dibuka sebelum pukul 12.00. Tinjau hasil waktu pemulihan dan kelengkapan data secara terpisah. ## Siapkan langkah yang bisa dijalankan Buat urutan kerja dari keputusan aktivasi sampai layanan boleh digunakan lagi. Contoh isi rencana: - Pemilik keputusan, petugas pelaksana, pengganti, dan kontak bantuan. - Prasyarat pemulihan: akses, konfigurasi, cadangan, jaringan, dan layanan pendukung. - Urutan tindakan, pemeriksaan data dan fungsi, serta persetujuan membuka layanan. - Cara memberi kabar kepada pengguna dan mencatat pekerjaan yang perlu diselesaikan setelah pemulihan. Simpan petunjuk di tempat yang bisa dijangkau ketika sistem utama terganggu, dengan akses yang tetap dibatasi. Jangan menaruh kata sandi atau kunci akses langsung dalam checklist yang dibagikan. Jika gangguan berkaitan dengan insiden keamanan, koordinasikan pemulihan dengan pemeriksaan penyebab dan penjagaan bukti. Baca [panduan penanganan insiden data pribadi](/panduan/keamanan/penanganan-insiden-data-pribadi/) untuk pembagian tugas dan penilaian pemberitahuan. Menyalakan aplikasi kembali belum menyelesaikan seluruh pekerjaan insiden. ## Apa beda sinkronisasi, backup, dan pemulihan? **Sinkronisasi menyamakan perubahan; backup menyediakan salinan untuk dipulihkan; pemulihan mengembalikan data dan layanan agar bisa digunakan.** Kemampuan setiap alat berbeda. Periksa versi lama yang tersedia, masa simpannya, dan siapa yang dapat menghapusnya. Contoh fiktif: folder kerja tersinkron ke laptop dan penyimpanan online. Seseorang menghapus berkas, lalu penghapusan ikut tersinkron. Dua lokasi itu sekarang sama-sama kehilangan berkas. Jika layanan menyimpan versi atau berkas terhapus, mungkin masih ada jalan pemulihan, tetapi batas waktunya perlu diperiksa. Keberadaan dua salinan saja belum membuktikan kesiapan backup. Catat data yang dicadangkan, jadwal, lokasi, perlindungan akses, serta cara mengambil salinan saat layanan utama bermasalah. NIST bagian 3.4.1–3.4.2 membahas pemilihan cara backup dan pemulihan berdasarkan kebutuhan sistem. Skenario sinkronisasi di atas adalah contoh Kompli untuk memeriksa kemampuan alat yang dipakai. ## Uji pemulihan, bukan hanya keberadaan cadangan NIST bagian 3.5 membedakan diskusi skenario (*tabletop exercise*) dari pengujian teknis. Diskusi membantu memeriksa keputusan dan koordinasi. Kemampuan memulihkan data perlu dibuktikan melalui uji yang sesuai. Sebagai latihan awal, pilih lingkungan uji yang terpisah dan data buatan. Tentukan lingkup, izin pelaksanaan, kriteria berhasil, serta cara menghentikan latihan jika berdampak ke layanan nyata. Uji akses aplikasi, kelengkapan data, koneksi yang dibutuhkan, dan pekerjaan pengguna setelah pemulihan. Catat waktu mulai dan selesai, titik data yang berhasil dikembalikan, kegagalan, serta orang yang menilai hasil. Jangan menyebut uji berhasil hanya karena proses penyalinan berkas selesai. Jika memakai vendor, minta bukti untuk lingkup layanan Anda; klaim cadangan tersedia saja belum menunjukkan hasil pemulihan. ## Latihan: apakah target pemulihan tercapai? Gunakan contoh gangguan pukul 10.00 pada diagram: RTO dua jam dan RPO 15 menit. Angka ini bahan latihan, bukan target wajib untuk semua bisnis.
Layanan kembali pukul 11.30, tetapi data hanya sampai 09.00. Target mana yang gagal?

RPO gagal: ada jarak satu jam sebelum gangguan, melebihi sasaran 15 menit. RTO terpenuhi jika layanan pada 11.30 sudah memenuhi kriteria pulih yang disepakati. Periksa waktu pulih dan titik data secara terpisah.

Data sampai 09.50 tersedia, tetapi layanan baru bisa dipakai pukul 13.00. Bagaimana hasilnya?

RPO terpenuhi karena jarak data hanya sepuluh menit. RTO gagal karena pemulihan memerlukan tiga jam, melebihi target dua jam. Cari hambatan pada proses, akses, atau layanan pendukung, lalu uji ulang setelah perbaikan.

Dashboard menampilkan “backup berhasil”. Bukti apa yang masih dibutuhkan?

Hasil uji pemulihan: salinan dapat diambil, data lengkap sesuai titik pemulihan, dan fungsi penting berjalan. Catat waktu, kegagalan, serta pemeriksa hasilnya. Laporan penyalinan saja belum membuktikan layanan dapat digunakan kembali.

## Perbarui rencana setelah perubahan Tinjau rencana ketika tim, arsitektur, pemasok, atau kebutuhan layanan berubah. NIST bagian 3.6 menekankan pemeliharaan rencana agar tetap sesuai kondisi sistem. Catat temuan, penanggung jawab, batas penyelesaian internal, dan hasil uji ulang. Gunakan [checklist pemulihan layanan](/template/checklist-pemulihan-layanan/) untuk rapat persiapan. Jika perlu sistem manajemen kelangsungan usaha yang lebih luas, lanjutkan ke [pengantar ISO 22301](/panduan/kelangsungan-usaha/iso-22301-untuk-bisnis/). Untuk cadangan yang berisiko ikut terdampak serangan, lihat [kesiapan ransomware dan contoh pemeriksaan restore](/panduan/keamanan/kesiapan-ransomware-dan-pemulihan/). ## Catat hasil nyata di samping target Gunakan [catatan uji pemulihan](/template/catatan-uji-pemulihan/) untuk membandingkan target dengan waktu yang benar-benar dibutuhkan. Contoh fiktif: target dua jam, hasil tiga jam karena menunggu akses cadangan. Catat keterlambatan itu, pemilik akses, dan rencana uji ulang. Angka tersebut hanya contoh, bukan target wajib bagi semua usaha. ## Sumber rujukan - [NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf) — Bagian 2.2.1, 2.2.6–2.2.7, 3.2, 3.4.1–3.4.2, 3.5–3.6 dan 4: jenis rencana, BIA, RTO/RPO, pengujian dan pemeliharaan - [NIST SP 800-34 Rev. 1 — catatan publikasi dan pembaruan](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final) — Identitas revisi dan pembaruan publikasi 11 November 2010; konteks sistem federal AS ## Jalur belajar: Website dan aplikasi [Lihat urutan belajar](https://kompli.id/belajar/#website-dan-aplikasi) ## Perlu membahas kebutuhan tim Anda? Ceritakan standar atau bukti yang diminta pelanggan dan kesiapan tim Anda saat ini. [Konsultasikan kebutuhan Anda](https://kompli.id/konsultasi/?topik=standar) ## Bacaan terkait - [ISO 22301: manfaat dan persiapan kelangsungan usaha](https://kompli.id/panduan/kelangsungan-usaha/iso-22301-untuk-bisnis/) - [Checklist BCP dan pemulihan layanan digital](https://kompli.id/template/checklist-pemulihan-layanan/) - [Cara menyiapkan penanganan insiden data pribadi](https://kompli.id/panduan/keamanan/penanganan-insiden-data-pribadi/) - [Persiapan audit keamanan website dan aplikasi](https://kompli.id/panduan/keamanan/persiapan-audit-keamanan/)