Backup dan disaster recovery BPR memiliki fungsi yang saling berkaitan. Backup menyediakan salinan data untuk pemulihan, sedangkan disaster recovery mencakup langkah mengembalikan layanan setelah gangguan. Bank membutuhkan keduanya agar dapat menilai data apa yang tersedia, layanan mana yang dipulihkan terlebih dahulu, dan siapa yang menyatakan operasional dapat dilanjutkan.
Status backup “berhasil” belum menjawab apakah aplikasi dapat digunakan kembali. Salinan database mungkin tersedia, sementara konfigurasi, dokumen pendukung, atau akses ke lingkungan pemulihan belum siap. Contoh ilustratif ini menunjukkan mengapa pemeriksaan perlu mengikuti proses pemulihan sampai pengguna dapat menjalankan pekerjaan yang ditetapkan.
Dalam konteks POJK 34 Tahun 2025, bedakan kewajiban rekam cadang, Rencana Pemulihan Bencana, penyediaan Pusat Pemulihan Bencana, dan penempatannya. Masing-masing perlu dibaca sesuai pasal dan kondisi penerapannya.
Apa Yang Diatur POJK Tentang Backup Dan Pemulihan?
Pasal 16 mewajibkan Rencana Pemulihan Bencana dan efektivitas pelaksanaannya. Untuk seluruh data aktivitas bank, Pasal 18 mengatur rekam cadang setiap akhir hari. Pasal 17 mengatur penyediaan Pusat Pemulihan Bencana bagi modal inti paling sedikit Rp50 miliar dan/atau penyedia layanan digital.
Mengenai lokasi, Pasal 32 mengatur penempatan Sistem Elektronik pada Pusat Data dan Pusat Pemulihan Bencana di Indonesia, dengan karakteristik risiko lokasi berbeda. Baca ketentuan tersebut bersama syarat penyediaan pusat pemulihan dan aturan pelaksana. Rujukan utama tersedia dalam naskah POJK 34 Tahun 2025.
Karena ada kondisi penerapan yang perlu diperiksa, hindari menyamakan kebutuhan semua BPR hanya berdasarkan nama layanan hosting. Untuk peta kewajiban lebih luas, gunakan panduan POJK 34 Tahun 2025 untuk BPR.
Bedakan Empat Komponen Dalam Rencana Pemulihan
| Komponen | Fungsi | Contoh Bukti Yang Diperiksa |
|---|---|---|
| Backup atau rekam cadang | Menyediakan salinan data | Cakupan, waktu, hasil pekerjaan, dan pemeriksaan salinan |
| Rencana Pemulihan Bencana | Menetapkan tindakan pemulihan | Urutan kerja, penanggung jawab, dan prosedur keputusan |
| Lingkungan atau pusat pemulihan | Menyediakan sarana untuk menjalankan pemulihan | Kapasitas, konfigurasi, koneksi, dan kesiapan akses |
| Uji pemulihan | Membuktikan bagian rencana dapat dijalankan | Catatan eksekusi, hasil pemeriksaan pengguna, dan tindak lanjut |
Kepemilikan satu komponen belum membuktikan keseluruhan kesiapan. Bank yang memakai jasa vendor tetap perlu mengetahui bagian mana yang dikelola vendor dan bagian mana yang harus disiapkan bank sendiri.
Pembahasan konsep umum tersedia pada disaster recovery aplikasi enterprise. Artikel ini memusatkan penerapannya pada kebutuhan dan ketentuan BPR.
Petakan Layanan Kritikal Dan Ketergantungannya
Mulailah dari analisis dampak bisnis: proses apa yang terganggu ketika suatu aplikasi berhenti, pihak yang terdampak, dan pekerjaan yang harus dipulihkan terlebih dahulu. Bank perlu menetapkan prioritas berdasarkan operasionalnya, bukan mengikuti urutan daftar server.
Satu aplikasi dapat bergantung pada database, penyimpanan dokumen, identitas pengguna, jaringan, serta layanan vendor. Memulihkan aplikasi tanpa salah satu ketergantungan tersebut mungkin belum menghasilkan layanan yang dapat digunakan.
Buat peta sederhana berisi proses, aplikasi, data, ketergantungan, dan penanggung jawab. Cocokkan dengan inventaris aktual. Aplikasi pendukung yang baru dibangun melalui proyek modernisasi perlu masuk peta ini sebelum digunakan untuk proses penting bank.
Tetapkan Target Waktu Dan Titik Data Pemulihan
Recovery Time Objective atau RTO menggambarkan target waktu pemulihan layanan. Recovery Point Objective atau RPO menggambarkan target titik pemulihan data, yang berkaitan dengan rentang perubahan data yang berpotensi belum tercakup. Target harus ditentukan bersama pemilik proses dan pihak teknis. Definisi istilah dapat dirujuk pada glosarium NIST untuk RTO dan RPO.
Artikel ini tidak menetapkan angka RTO atau RPO universal untuk seluruh BPR. Kemampuan pemulihan bergantung pada rancangan, layanan vendor, kapasitas, serta hasil uji. Permintaan target yang sangat ketat perlu disertai evaluasi biaya dan ketergantungan.
Bedakan target dengan hasil terukur. Jika rencana menyebut layanan pulih dalam waktu tertentu tetapi uji belum dilakukan, statusnya masih target. Dokumentasikan waktu mulai, tahapan, dan hasil aktual agar selisih dapat dibahas secara konkret.
Periksa Cakupan Backup Sampai Ke Dokumen Dan Konfigurasi
Daftar backup perlu mencakup data yang diperlukan untuk memulihkan layanan sesuai kewajiban dan rancangan bank. Selain database, periksa dokumen terkait, konfigurasi aplikasi, serta informasi operasional yang diperlukan. Pengelolaan kunci dan akses pemulihan memerlukan perlindungan tersendiri.
Cocokkan jadwal pekerjaan dengan data aktivitas yang seharusnya tercakup. Periksa bagaimana kegagalan diberitahukan dan siapa yang menindaklanjutinya. Status berhasil pada satu pekerjaan tidak membuktikan seluruh aplikasi sudah tercakup.
Uji keterbacaan salinan dan hubungan antara database dengan dokumen. Jika database dipulihkan dari waktu berbeda dibandingkan berkas pendukung, referensi dapat tidak sesuai. Penanganan konsistensi ini perlu dibahas bersama pengelola aplikasi sebelum terjadi gangguan.
Evaluasi Lokasi, Akses, Dan Ketergantungan Vendor
Konfirmasikan lokasi layanan yang sebenarnya, termasuk penyimpanan salinan dan lingkungan pemulihan. Label paket “lokal” saja belum cukup menjelaskan penempatan seluruh komponen. Minta dokumentasi layanan yang relevan dari penyedia.
Periksa pula karakteristik risiko lokasi sebagaimana Pasal 32. Dua lokasi berbeda secara alamat belum otomatis memiliki risiko yang berbeda secara memadai. Penilaian perlu mempertimbangkan keadaan lingkungan dan ketergantungan bersama yang relevan terhadap rancangan bank.
Jika vendor mengelola pemulihan, tentukan jalur aktivasi, bukti pengujian, pembagian tugas, dan tingkat layanan. Gunakan panduan memilih vendor TI BPR untuk meninjau kontrak. Bank tetap memerlukan kemampuan mengawasi layanan yang diselenggarakan pihak lain.
Susun Prosedur Yang Dapat Dijalankan Saat Gangguan
Rencana pemulihan perlu menjelaskan kondisi aktivasi, pihak yang mengambil keputusan, urutan pekerjaan, akses yang dibutuhkan, dan cara memverifikasi hasil. Sertakan kontak kerja yang dipelihara bank serta jalur pengganti bila penanggung jawab utama tidak tersedia.
Tuliskan langkah operasional cukup rinci agar dapat dilaksanakan pihak yang ditugaskan. Instruksi seperti “hubungi vendor dan pulihkan server” masih menyisakan banyak keputusan penting. Jelaskan pula apa yang harus dilakukan pengguna selama layanan belum tersedia.
Untuk sistem terintegrasi, koordinasikan penghentian dan pengaktifan kembali pertukaran data. Antrean yang berjalan ketika salah satu sistem belum siap dapat menghasilkan status tidak konsisten. Masalah tersebut berkaitan dengan integrasi LOS dan core banking BPR.
Uji Backup Dan Disaster Recovery BPR Secara Terarah
Pasal 16 mengatur uji coba paling sedikit sekali dalam dua tahun bagi BPR yang menyediakan layanan digital, atau sekali dalam tiga tahun untuk kelompok selain itu. Cakupannya adalah aplikasi dan infrastruktur kritikal sesuai analisis dampak bisnis, dengan melibatkan pengguna TI. Kaji ulang rencana juga diatur dalam pasal tersebut.
Frekuensi minimum tidak menghapus kebutuhan menilai perubahan besar yang memengaruhi kesiapan pemulihan. Tentukan uji yang relevan dengan perubahan serta kebijakan bank. Gunakan lingkungan terpisah dan kewenangan yang jelas agar pemeriksaan tidak mengganggu layanan nyata.
Tetapkan skenario, data, target, dan hasil yang diharapkan sebelum uji. Catat bagian yang disimulasikan, benar-benar dieksekusi, atau belum diperiksa. Simulasi diskusi tidak boleh dilaporkan sebagai keberhasilan pemulihan teknis seluruh sistem.
Verifikasi Data Dan Proses Setelah Layanan Pulih
Setelah aplikasi dapat dibuka, pengguna perlu memeriksa fungsi yang disepakati. Contohnya membuka dokumen uji, menelusuri status pengajuan, atau membandingkan data pada titik pemulihan. Keberhasilan login merupakan satu pemeriksaan, bukan penutupan seluruh uji.
Periksa pula antrean integrasi, pekerjaan terjadwal, hak akses, dan jejak audit yang diperlukan. Jika terdapat perbedaan data, tentukan bagaimana rekonsiliasi dilakukan dan siapa yang memberi keputusan. Pisahkan kehilangan yang terkonfirmasi dari informasi yang masih belum ditemukan.
Untuk pengujian terstruktur, masukkan bukti tersebut dalam checklist kesiapan TI BPR. Jika cakupan atau prioritas belum jelas, assessment TI BPR dapat membantu menyusun pekerjaan awal.
Menyiapkan Lingkup Implementasi Bersama Layana.id
Pembahasan pemulihan aplikasi perlu membawa daftar layanan kritikal, pengelola, lokasi, cakupan backup, serta hasil uji yang tersedia. Bedakan pekerjaan pengembangan aplikasi, konfigurasi infrastruktur, dan layanan pusat pemulihan. Kebutuhan penyedia spesialis harus dinyatakan dalam pembagian tanggung jawab.
Melalui layanan custom development, Layana.id dapat diajak membahas kebutuhan aplikasi serta integrasi yang mendukung proses pemulihan. Kelayakan, lingkup, dan keterlibatan penyedia infrastruktur perlu ditentukan dari kondisi bank, bukan diasumsikan sebagai paket siap pakai.
Diskusikan kebutuhan backup dan pemulihan aplikasi BPR bersama Layana.id dengan meminta keluaran yang dapat diuji. Tujuannya agar rencana, sarana, serta tanggung jawab dapat dihubungkan dengan bukti pelaksanaan yang jelas.
Aplikasi Finance Karya Layana
Aplikasi nasabah, alur pengajuan kredit, dan web admin untuk KB Bukopin Finance, BPR CMA, serta BPR MSA.
KB Bukopin Finance
Dari Simulasi Ke Pengajuan Pembiayaan
Aplikasi Android dan web admin untuk informasi produk, simulasi pembiayaan, serta pengumpulan pengajuan calon nasabah. Lingkup proyek mencakup perancangan integrasi e-KYC Privy.ID, skor kredit pihak ketiga CLIK, dan pengembangan skoring berbasis data internal.
BPR CMA
Alur Kredit Dalam Genggaman Tim
Aplikasi mobile dan web admin untuk pengajuan serta survei kredit. Cakupannya membantu marketing dan komite kredit mengelola pengecekan data, exposure, serta analisis jaminan. Pengajuan dan status pekerjaan menjadi bagian dari alur yang dapat ditelusuri tim.
MSA On Hand
Layanan Nasabah Dan Komunitas UMKM
Aplikasi BPR Madani Sejahtera Abadi untuk pengajuan kredit, pembukaan rekening dan deposito, pembayaran, serta forum komunitas. Lingkup proyek Layana juga mencakup web admin, pengelolaan pengajuan oleh marketing dan notaris, serta laporan operasional.
MSA on Hand tersedia di Google Play dengan PT. Layana Computindo Sentratama tercantum sebagai developer.
Portofolio aplikasi tersebut tidak menjadi bukti implementasi DRC atau hasil uji pemulihan pada ketiga klien. Dalam pekerjaan baru, lingkup backup, pemulihan aplikasi, tanggung jawab penyedia infrastruktur, serta bukti pengujian harus ditetapkan tersendiri.
Bicarakan Aplikasi BPR Anda
Ceritakan proses yang masih manual, sistem yang digunakan, dan fitur yang ingin dibuat. Tim Layana dapat membantu membahas kebutuhan, batas integrasi, dan tahapan pengembangan.
Referensi
- POJK Nomor 34 Tahun 2025, terutama Pasal 16–18, 27, dan 32.
- PADK Nomor 43/PADK.03/2025, ketentuan pelaksanaan yang perlu dibaca bersama POJK.