Checklist kesiapan TI BPR membantu manajemen memeriksa aplikasi, akses pengguna, backup, vendor, dan bukti pengendalian sebelum menentukan pekerjaan perbaikan. Cara menggunakannya sederhana: setiap jawaban harus disertai dokumen atau hasil pemeriksaan. Jawaban “sudah ada” belum cukup jika bukti tidak tersedia atau tidak sesuai kondisi sistem saat ini.
Bayangkan tim TI menjawab bahwa backup berjalan setiap malam. Saat ditanya kapan terakhir dipulihkan, belum ada catatannya. Dalam checklist, backup dan keberhasilan pemulihan harus menjadi dua pemeriksaan berbeda. Pemisahan ini membantu bank melihat celah yang tidak tampak dalam daftar fitur aplikasi.
Daftar berikut merupakan alat kerja awal, bukan formulir resmi OJK atau penetapan bahwa bank telah patuh. Gunakan bersama panduan POJK 34 Tahun 2025 untuk BPR serta ketentuan pelaksana yang berlaku.
Tetapkan Cakupan Sebelum Mengisi Checklist
Libatkan pemilik proses bisnis, fungsi TI, manajemen risiko, kepatuhan, dan audit sesuai peran masing-masing. Tentukan pula aplikasi yang diperiksa. Core banking, aplikasi pengajuan kredit, penyimpanan dokumen, dan koneksi vendor dapat memiliki pengelola berbeda.
Catat apakah bank menyediakan layanan digital dan berapa modal inti yang menjadi dasar penilaian. Informasi ini relevan untuk membaca ketentuan seperti arsitektur TI dan penyediaan Pusat Pemulihan Bencana. Jangan menyamakan semua persyaratan tanpa memeriksa kondisi penerapannya.
Tuliskan tanggal pemeriksaan dan versi dokumen. Hasil tahun sebelumnya bisa menjadi petunjuk, tetapi bukan bukti kondisi terbaru. Penambahan aplikasi atau perpindahan vendor dapat membuat catatan lama tidak lagi memadai.
Cara Menggunakan Checklist Kesiapan TI BPR
Untuk setiap butir, pilih salah satu status: terverifikasi, ditemukan celah, belum diperiksa, atau tidak berlaku dengan alasan. Hindari persentase kesiapan yang dihitung hanya dari jumlah kotak terisi. Satu akses administrator yang tidak terkendali dapat lebih mendesak daripada beberapa dokumen yang belum dirapikan.
Tabel kerja minimal dapat berisi kolom berikut:
| Butir | Bukti Yang Diperiksa | Status | Penanggung Jawab | Tindakan Berikutnya |
|---|---|---|---|---|
| Pencabutan akses pegawai keluar | Daftar akun dan sampel permintaan penutupan | Belum diperiksa | Ditentukan bank | Cocokkan data kepegawaian dengan akun aktif |
| Pemulihan backup | Catatan uji dan hasil verifikasi data | Ditemukan celah bila belum diuji | Ditentukan bank | Susun uji di lingkungan terpisah |
Contoh tersebut bukan temuan pada bank tertentu. Fungsinya menunjukkan bahwa status harus menghasilkan tindakan, bukan sekadar warna pada laporan.
1. Inventaris Aplikasi Dan Pemiliknya
Periksa apakah bank memiliki daftar aplikasi yang benar-benar digunakan, termasuk aplikasi kecil di unit kerja. Untuk setiap aplikasi, catat fungsi, pemilik proses, pengelola teknis, lokasi penempatan, vendor, dan sumber datanya. Tambahkan ketergantungan pada jaringan atau layanan lain.
Selanjutnya, cocokkan inventaris dengan kenyataan. Apakah masih ada aplikasi lama yang menyimpan data? Adakah integrasi yang disebut tidak aktif tetapi ternyata masih berjalan? Apakah dokumen nasabah tersimpan di luar sistem yang dikelola resmi?
Bukti yang berguna meliputi daftar aset, diagram aliran data, kontrak, serta konfirmasi pemilik proses. Inventaris perlu cukup rinci untuk mengetahui siapa yang harus dihubungi ketika gangguan muncul.
2. Tanggung Jawab Dan Kebijakan TI
Pasal 3, 6, dan 7 pada POJK 34 Tahun 2025 menjadi rujukan awal. Periksa penetapan tanggung jawab, kebijakan penyelenggaraan, dan fungsi TI. Pastikan dokumen disahkan sesuai kewenangan serta memiliki mekanisme penginian.
Ambil satu perubahan aplikasi sebagai sampel. Telusuri siapa yang meminta, menyetujui, menguji, dan menerima hasilnya. Bila seluruh keputusan hanya tercatat dalam percakapan informal, tentukan bagaimana catatan tersebut akan dibakukan.
Jangan berhenti pada ketersediaan SOP. Cocokkan satu atau dua prosedur dengan praktik aktual. Perbedaan antara dokumen dan pelaksanaan merupakan bahan perbaikan yang perlu dijelaskan secara terbuka.
3. Hak Akses Dan Akun Istimewa
Bandingkan daftar pengguna aktif dengan pegawai dan pihak eksternal yang masih berwenang. Periksa akun bersama, akun administrator, akun integrasi, serta akses vendor. Setiap jenis akun membutuhkan pemilik dan alasan penggunaan yang jelas.
Berikut pertanyaan yang layak diuji melalui akun uji berizin:
- Dapatkah pengguna membuka data cabang di luar kewenangannya?
- Apakah pembuat pengajuan bisa menyetujui pengajuannya sendiri?
- Saat jabatan berubah, apakah akses ikut ditinjau?
- Apakah akses vendor dibatasi masa berlaku dan cakupannya?
Hasil uji perlu menyebut tindakan yang dicoba dan respons sistem. Tangkapan layar menu saja belum membuktikan pembatasan akses pada seluruh jalur aplikasi. Rincian pemeriksaan dokumen, ekspor, dan akun vendor tersedia pada keamanan data nasabah BPR.
4. Jejak Audit Yang Bisa Ditelusuri
Pasal 40 ayat (4) mengatur ketersediaan jejak audit. Pilih contoh proses, seperti perubahan data pengajuan atau persetujuan. Telusuri apakah bank dapat mengetahui pelaku, waktu, objek, tindakan, dan hasil aktivitasnya.
Periksa pula siapa yang dapat menghapus atau mengekspor catatan tersebut. Riwayat yang lengkap tetapi bisa diubah tanpa jejak oleh pengguna operasional masih menyisakan risiko. Hindari mencatat data sensitif secara berlebihan hanya untuk memperpanjang log.
Gunakan panduan audit trail sistem BPR untuk menyusun skenario pemeriksaan. Bila catatan belum tersedia pada aplikasi lama, tandai kebutuhan pengembangan beserta batas data historis yang masih dapat dibuktikan.
5. Backup Dan Kesiapan Pemulihan
Pasal 18 mengatur rekam cadang setiap akhir hari untuk seluruh data aktivitas. Periksa cakupan, keberhasilan, penanganan kegagalan, dan pihak yang menerima pemberitahuan. Status pekerjaan backup perlu dibandingkan dengan daftar sistem yang seharusnya tercakup.
Kemudian periksa Rencana Pemulihan Bencana menurut Pasal 16. Uji coba paling sedikit sekali dalam dua tahun berlaku bagi penyedia layanan digital; kelompok selain itu paling sedikit sekali dalam tiga tahun. Pengguna TI perlu dilibatkan sesuai ketentuan tersebut.
Pasal 17 mengatur penyediaan pusat pemulihan untuk modal inti paling sedikit Rp50 miliar dan/atau penyedia layanan digital. Bedakan kondisi ini dari kewajiban backup dan rencana pemulihan. Penerapan lokasi pada Pasal 32 juga perlu diperiksa bersama aturan pelaksana. Gunakan panduan backup dan disaster recovery BPR untuk membedakan bukti salinan data dan bukti pemulihan layanan.
6. Pengelolaan Data Dan Pelindungan Nasabah
Periksa sumber data utama, aturan validasi, proses koreksi, serta pihak yang boleh melakukan ekspor. Sampelkan satu perubahan data untuk melihat apakah pembaruan mencapai aplikasi terkait atau justru menghasilkan versi berbeda.
Pasal 35–36 mengatur pengelolaan data dan pelindungan data pribadi. Untuk pemeriksaan awal, kumpulkan kebijakan pemrosesan, pembagian akses, serta dokumentasi persetujuan ketika relevan. Penilaian dasar pemrosesan dan kewajiban hukum perlu melibatkan fungsi yang berwenang.
Gunakan data sintetis atau data yang telah disamarkan saat berdiskusi dengan calon pengembang. Kebutuhan assessment tidak otomatis membenarkan penyalinan seluruh database produksi ke perangkat pihak lain.
7. Kontrak Dan Ketergantungan Vendor
Cocokkan layanan yang berjalan dengan kontraknya. Periksa cakupan, tingkat layanan, kerahasiaan, penanganan kejadian kritis, akses pemeriksaan, subkontrak, dan mekanisme penghentian. Ketentuan penyedia jasa TI terdapat pada Pasal 27–28.
Tanyakan siapa yang menyediakan data saat bank memerlukannya dan apa yang terjadi ketika vendor tidak dapat melanjutkan layanan. Pastikan bank mengetahui cara memperoleh ekspor data serta dokumen yang diperlukan untuk perpindahan pengelolaan.
Untuk pengadaan baru, gunakan pertanyaan pemilihan vendor TI BPR. Untuk kontrak lama, periksa ketentuan peralihan Pasal 51 secara khusus; jangan menganggap seluruh hubungan kerja harus dihentikan atau diganti sekaligus.
8. Pengujian Aplikasi Dan Tindak Lanjut Temuan
Ambil satu alur bisnis dari awal sampai akhir. Pada pengajuan kredit, misalnya, periksa input, revisi, persetujuan, pengiriman ke sistem lain, dan rekonsiliasinya. Gunakan skenario gagal selain skenario berhasil.
Jika pengiriman data terputus, apakah petugas mengetahui statusnya? Apakah pengulangan proses berpotensi membuat data ganda? Temuan seperti ini perlu diterjemahkan menjadi kriteria penerimaan dalam pengembangan aplikasi BPR.
Catat hasil pengujian ulang setelah perbaikan. Temuan tidak selesai hanya karena pengembang menyatakan perubahan sudah dikirim. Pemilik proses perlu melihat bahwa masalah awal memang tidak terulang pada skenario yang diperiksa.
Mengubah Hasil Checklist Menjadi Rencana Kerja
Urutkan temuan berdasarkan dampak, kemungkinan kejadian, ketergantungan, dan waktu perbaikan. Tetapkan siapa yang memutuskan prioritas serta siapa yang menerima risiko sementara. Pengelompokan ini lebih berguna daripada menumpuk semua kebutuhan dalam satu proyek besar.
Untuk pekerjaan software, siapkan uraian masalah, proses terdampak, bukti, dan hasil yang diharapkan. Jangan langsung meminta daftar fitur tanpa menjelaskan kegagalan yang hendak dicegah. Spesifikasi yang jelas membantu membandingkan penawaran dan menilai hasil pengembangan. Jika pemeriksaan perlu melibatkan pihak lain, tetapkan lingkup serta keluaran melalui panduan assessment TI BPR.
Layana.id dapat diajak membahas kebutuhan aplikasi melalui layanan custom development. Bawa inventaris dan daftar prioritas tanpa data nasabah sensitif. Pembahasan awal sebaiknya menghasilkan lingkup yang terukur, termasuk bagian yang menjadi tanggung jawab bank, vendor lama, dan pengembang.
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.
Untuk checklist kesiapan TI BPR, bawa contoh alur yang bermasalah beserta aplikasi yang terlibat. Dari situ, bank dan pengembang dapat membedakan kebutuhan pembenahan proses, konfigurasi, integrasi, atau modul baru.
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
- Naskah POJK Nomor 34 Tahun 2025, terutama Pasal 3, 6–7, 15–18, 27–28, 35–40, dan 51.
- PADK Nomor 43/PADK.03/2025 untuk ketentuan pelaksanaan dan lampiran terkait.