Pemeriksaan OJK dari Sisi Sistem dan IT: Panduan Persiapan BPR dan BPRS

Kabar pemeriksaan datang pada Kamis sore. Direktur memanggil kepala TI dan kepala operasional. “Siapkan semua dokumen sistem,” katanya. “Pemeriksa datang minggu depan.”

Mereka pun mulai mencari. SOP keamanan informasi sudah ada, tetapi belum ditandatangani direktur. Daftar pengguna sistem ada, tetapi tiga akun masih dipakai bergiliran oleh teller. Backup berjalan setiap malam, tetapi belum pernah ada catatan uji pemulihan. Kontrak vendor aplikasi inti perbankan tidak memuat kewajiban memberi akses kepada OJK. Laporan audit TI tahun lalu menemukan empat belas masalah, dan baru empat yang ditutup.

Bukan karena bank tidak punya sistem. Sistemnya berjalan setiap hari. Yang tidak siap adalah buktinya. Dokumen, konfigurasi, dan catatan operasional tidak saling cocok. Ketika pemeriksa meminta satu contoh transaksi, tim harus mereka-reka urutan kejadian dari ingatan.

Lemahnya kesadaran dari manajemen dalam melakukan evaluasi sistem, menyebabkan situasi ini sering terjadi, terutama di BPR dan BPRS dengan tim TI kecil. Pemeriksaan OJK bukan ujian menghafal nama aplikasi. Pemeriksaan adalah uji kecocokan: apakah yang tertulis di kebijakan benar-benar dipasang di sistem, dan apakah sistem benar-benar dijalankan seperti itu setiap hari.

Artikel ini membahas persiapan pemeriksaan OJK dari sisi sistem dan TI untuk BPR (Bank Perekonomian Rakyat) dan BPRS (Bank Perekonomian Rakyat Syariah). Mulai dari apa yang diperiksa, delapan area yang perlu dibuka, cara menyiapkan bukti, sampai rencana 90 hari menjelang aturan TI baru berlaku.

1. Mengapa Pemeriksa Melihat Sistem dan TI

OJK adalah Otoritas Jasa Keuangan, lembaga yang mengatur dan mengawasi industri jasa keuangan, termasuk BPR dan BPRS. Pemeriksaan OJK diatur dalam POJK 41/POJK.03/2017 tentang Persyaratan dan Tata Cara Pemeriksaan Bank.

Menurut Pasal 4 aturan itu, pemeriksaan terdiri dari dua bentuk: berkala dan sewaktu-waktu. Cakupannya adalah aspek kegiatan usaha bank, termasuk sarana pendukung dan hal-hal lain yang berkaitan dengan keuangan. Sistem dan TI masuk sebagai sarana pendukung. Sistem mencatat transaksi, menghitung bunga atau bagi hasil, menyusun laporan, dan menyimpan data nasabah.

Pasal 5 menjelaskan tujuan pemeriksaan. OJK ingin memperoleh gambaran menyeluruh tentang usaha dan kondisi bank, menguji kebenaran laporan, memastikan kepatuhan, dan meneliti dugaan tindak pidana perbankan. Artinya, pemeriksa tidak hanya membaca laporan akhir bulan. Mereka bisa menelusuri bagaimana angka itu terbentuk, dari transaksi di cabang sampai laporan yang dikirim ke OJK.

Kewajiban bank juga jelas. Pasal 6 menyebut bank wajib segera memperlihatkan dan memberikan buku, berkas, catatan, dokumen, dan data elektronik yang diperlukan. Bank juga wajib memberi keterangan, kesempatan memeriksa sarana fisik, dan bantuan lain. Bank dilarang menghambat pemeriksaan atau memengaruhi penilaian pemeriksa.

Karena itu, persiapan yang baik bukan menyembunyikan masalah. Persiapan yang baik adalah mengetahui masalah, menyiapkan bukti, dan menunjukkan rencana perbaikan yang masuk akal.

Sambungannya dengan tata kelola ada di POJK 9/2024 tentang Penerapan Tata Kelola bagi Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah. Pasal 2 menyebut integritas pelaporan dan sistem TI sebagai bagian dari tata kelola yang baik, bersama manajemen risiko, strategi anti-fraud, dan pengendalian intern. Pasal 97 menegaskan bahwa penggunaan TI harus memperhatikan prinsip tata kelola dan manajemen risiko.

Jadi, pertanyaannya bukan lagi “apakah TI akan diperiksa?” Pertanyaan yang lebih tepat: “bukti apa yang harus bisa kami tunjukkan ketika sistem ditanya?”

2. Pemeriksaan Adalah Uji Kecocokan, Bukan Lomba Dokumen

Banyak bank menyiapkan pemeriksaan dengan menambah dokumen. SOP baru dicetak, daftar hadir pelatihan dilengkapi, dan folder dijilid rapi. Cara ini membantu, tetapi belum cukup.

Pemeriksa yang berpengalaman akan mencocokkan tiga lapis bukti.

Lapis pertama adalah kebijakan: apa yang seharusnya terjadi. Isinya berupa SOP, surat keputusan, batas wewenang, dan prosedur yang sudah disetujui serta berlaku.

Lapis kedua adalah konfigurasi: apa yang benar-benar dipasang di sistem. Contohnya, siapa yang boleh menyetujui transaksi, berapa limitnya, apakah jejak audit aktif, dan kapan backup berjalan.

Lapis ketiga adalah jejak operasional: apa yang benar-benar terjadi. Isinya log, tiket gangguan, persetujuan perubahan, laporan uji pemulihan, dan bukti tindak lanjut temuan.

Contohnya begini. Kebijakan mengatakan hak akses ditinjau setiap tiga bulan. Konfigurasi menunjukkan masih ada akun bersama. Jejak operasional tidak punya catatan peninjauan. Ketiga lapis itu saling bertentangan. Pemeriksa tidak perlu mencari kesalahan lain; satu ketidakcocokan sudah cukup untuk menilai pengendalian tidak berjalan.

Sebaliknya, bank bisa terlihat kuat meski belum sempurna. Kebijakan mengakui ada keterbatasan staf. Konfigurasi memakai akun pribadi dan persetujuan berjenjang. Jejak operasional menunjukkan peninjauan akses bulanan dan tindak lanjut atas dua akun yang terlambat dicabut. Yang dinilai bukan kesempurnaan, melainkan apakah bank tahu risikonya dan mengendalikannya.

Karena itu, mulailah dari pertanyaan: “klaim apa yang ingin saya buktikan?” Bukan “dokumen apa yang harus saya cetak?”

3. Delapan Area Sistem yang Paling Sering Dibuka

Tidak ada daftar tunggal yang berlaku untuk semua pemeriksaan. Lingkup bergantung pada profil risiko, temuan sebelumnya, dan permintaan pemeriksa. Namun, delapan area berikut hampir selalu muncul karena semuanya melekat pada kewajiban TI dan tata kelola.

3.1 Tata kelola dan tanggung jawab TI

Pemeriksa biasanya memulai dari atas: siapa yang bertanggung jawab, atas dasar apa, dan bagaimana pengawasan dilakukan. Di BPR dan BPRS, tanggung jawab ini tidak bisa diserahkan seluruhnya kepada vendor.

POJK 75/2016 mewajibkan Direksi dan Dewan Komisaris memiliki wewenang serta tanggung jawab yang jelas. Direksi menetapkan rencana pengembangan TI, kebijakan, dan memantau kinerjanya. Dewan Komisaris mengarahkan dan memantau hal-hal yang mendasar. Aturan yang lebih baru, POJK 34/2025, menambahkan kewajiban menunjuk satuan kerja TI yang independen dari fungsi penghimpunan dana, penyaluran dana, pembukuan, kepatuhan, dan audit intern.

Bukti yang perlu siap:

• Surat keputusan atau penetapan struktur organisasi TI.
• Rencana pengembangan TI dan kaitannya dengan rencana bisnis bank.
• Kebijakan dan prosedur TI yang sudah disetujui dan bertanggal.
• Notulen rapat Direksi atau Dewan Komisaris yang membahas TI, risiko, dan tindak lanjut.
• Daftar risiko TI serta pengendaliannya.

3.2 Hak akses dan pemisahan tugas

Ini area yang paling sering menghasilkan temuan sederhana: akun dipakai bersama, hak akses tidak dicabut saat pegawai pindah, atau satu orang bisa membuat dan menyetujui transaksi.

Kebijakan akses harus menjelaskan siapa boleh mengakses apa. Sistem harus menegakkannya. Pemeriksa dapat meminta daftar pengguna, matriks hak akses, bukti persetujuan, dan catatan peninjauan berkala. Mereka juga bisa memilih satu pegawai yang sudah resign atau pindah tugas, lalu memeriksa apakah akunnya masih aktif.

Bukti yang perlu siap:

• Daftar pengguna aktif beserta jabatan dan perannya.
• Matriks hak akses per jabatan.
• Formulir permohonan, perubahan, dan pencabutan akses.
• Bukti peninjauan akses, misalnya daftar periksa bertanda tangan.
• Daftar akun istimewa seperti administrator dan bukti pengawasannya.

3.3 Jejak audit dan log

Jejak audit atau audit trail adalah catatan tentang siapa melakukan apa, kapan, dari mana, dan apa yang berubah. Tanpa jejak audit, bank tidak bisa menjawab pertanyaan dasar ketika terjadi sengketa, kesalahan, atau kecurangan. Pola penyalahgunaan akses yang perlu diwaspadai sudah dibahas di artikel fraud di BPR dan BPRS.

POJK 75/2016 mewajibkan jejak audit untuk seluruh kegiatan TI. POJK 34/2025 mengulang kewajiban itu dan menegaskan bahwa jejak audit harus tersedia untuk pengawasan, penegakan hukum, penyelesaian sengketa, verifikasi, pengujian, dan pemeriksaan lainnya. Jejak audit bukan sekadar fitur tambahan; ia adalah alat bukti.

Bukti yang perlu siap:

• Daftar jenis log yang disimpan: log aplikasi, log basis data, log jaringan, dan log administrator.
• Bukti bahwa log tidak bisa diubah atau dihapus oleh pengguna biasa.
• Kebijakan masa simpan log.
• Contoh penelusuran satu transaksi lengkap, dari input sampai persetujuan.
• Bukti pemantauan log, bukan hanya penyimpanannya.

3.4 Data dan laporan

Pemeriksa membandingkan angka di sistem dengan angka di laporan. Kalau selisih, mereka akan menanyakan proses rekonsiliasi, parameter, dan siapa yang menyetujui koreksi.

POJK 9/2024 mewajibkan laporan yang lengkap, akurat, kini, dan utuh. Sistem informasi manajemen harus memadai untuk mendukung keputusan Direksi dan pengawasan Dewan Komisaris. Untuk BPRS, laporan bulanan seperti APOLO dan SLIK menjadi pintu masuk yang sering diperiksa. Tenggat dan isi laporannya bisa dilihat di checklist pelaporan bulanan BPRS. Kalau ada selisih data, pelajari juga error umum SLIK dan cara koreksinya.

Bukti yang perlu siap:

• Prosedur penyusunan dan pengiriman laporan.
• Kertas kerja rekonsiliasi antara aplikasi inti perbankan dan laporan.
• Log perubahan parameter yang memengaruhi perhitungan.
• Daftar koreksi laporan beserta alasan dan persetujuannya.
• Bukti bahwa laporan yang terkirim sama dengan yang diarsipkan.

3.5 Backup dan pemulihan

Backup yang berhasil bukan bukti bahwa data bisa dipulihkan. Pemeriksa biasanya menanyakan dua hal berbeda: apakah backup berjalan, dan apakah pernah ada uji pemulihan.

POJK 75/2016 mewajibkan rekam cadang data aktivitas setiap akhir hari. Aturan itu juga mewajibkan rencana pemulihan bencana yang diuji secara berkala. POJK 34/2025 menegaskan kembali kewajiban backup harian dan mengatur frekuensi uji rencana pemulihan bencana: minimal sekali dalam dua tahun untuk bank yang menyediakan layanan digital, atau sekali dalam tiga tahun untuk bank lain.

Bukti yang perlu siap:

• Jadwal dan status backup harian.
• Bukti backup tersimpan di lokasi terpisah.
• Laporan uji restore dengan tanggal, data yang diuji, hasil, dan waktu pemulihan.
• Rencana pemulihan bencana yang sudah disetujui.
• Bukti uji rencana dan tindak lanjut atas kegagalan yang ditemukan.

3.6 Keamanan informasi dan siber

Keamanan informasi mencakup banyak hal: kata sandi, hak istimewa, patch, antivirus, jaringan, enkripsi, dan penanganan insiden. Pemeriksa tidak harus menguji semuanya. Mereka cukup meminta bukti bahwa pengendalian direncanakan, dijalankan, dan dipantau.

POJK 34/2025 mewajibkan bank menjaga ketahanan dan keamanan siber, melakukan identifikasi aset dan kerentanan, mendeteksi insiden, serta menanggulangi dan memulihkan insiden. Bank juga wajib menilai maturitas keamanan siber setiap tahun untuk posisi akhir Desember.

Bukti yang perlu siap:

• Kebijakan keamanan informasi dan prosedur penanganan insiden.
• Bukti patch dan pembaruan antivirus.
• Hasil pemindaian kerentanan atau pengujian keamanan, beserta rencana perbaikan.
• Daftar insiden, kronologi, tindakan, dan pelaporannya.
• Bukti penilaian maturitas keamanan siber.

3.7 Vendor aplikasi inti perbankan dan pihak ketiga

Banyak BPR dan BPRS memakai vendor untuk aplikasi inti, pusat data, atau layanan pendukung. Bank tetap bertanggung jawab, meskipun pekerjaannya dilakukan vendor.

Pemeriksa biasanya meminta kontrak, profil vendor, bukti pemantauan layanan, dan jaminan akses. Kontrak harus memuat hak OJK untuk mengakses data dan memeriksa kegiatan vendor. Kontrak juga perlu mengatur kerahasiaan, keamanan, kesepakatan tingkat layanan (SLA), penanganan insiden, subkontrak, dan cara keluar dari kerja sama.

POJK 34/2025 memperkuat aturan ini. Bank wajib memantau reputasi vendor, memastikan vendor memberi data tepat waktu, dan memastikan ada klausul penghentian kerja sama. Kalau layanan vendor terganggu, bank wajib melapor ke OJK paling lama tiga hari kerja sejak kondisi diketahui.

Bukti yang perlu siap:

• Perjanjian kerja sama dan lampiran SLA.
• Hasil uji tuntas vendor.
• Laporan kinerja layanan dan catatan gangguan.
• Bukti hak akses OJK, auditor, dan bank terhadap data.
• Rencana penghentian kerja sama atau exit plan.

3.8 Audit intern TI dan tindak lanjut

Audit intern adalah mata kedua. Ia memeriksa apakah pengendalian TI benar-benar berjalan, bukan hanya ada di kertas.

POJK 75/2016 mewajibkan audit intern TI minimal sekali setahun dan penyampaian laporan pelaksanaannya kepada OJK. POJK 34/2025 mempertahankan kewajiban tahunan itu, menambahkan kewajiban pedoman audit intern TI, dan menegaskan ketersediaan jejak audit. Audit bisa dilakukan auditor internal atau auditor ekstern, tetapi tanggung jawabnya tetap di bank.

Bukti yang perlu siap:

• Program kerja dan laporan audit TI.
• Daftar temuan, risiko, rekomendasi, penanggung jawab, dan tenggat.
• Bukti penyelesaian temuan.
• Laporan kepada OJK.
• Bukti bahwa temuan berulang dibahas oleh Direksi.

Kedelapan area di atas saling terkait. Akun bersama merusak jejak audit. Jejak audit yang buruk melemahkan audit intern. Audit intern yang lemah membuat masalah yang sama muncul lagi. Karena itu, jangan menyiapkan area secara terpisah tanpa melihat hubungannya.

4. Menyiapkan Ruang Bukti dalam Satu Folder

Pemeriksa tidak perlu melihat seluruh isi server. Mereka perlu menemukan bukti yang tepat dengan cepat. Karena itu, buat indeks bukti: satu halaman yang menjelaskan apa klaimnya, di mana buktinya, siapa penanggung jawabnya, dan sampai kapan dokumen itu berlaku.

Susun folder dengan nama yang mudah dipahami, misalnya:

1. Kebijakan dan surat keputusan.
2. Rencana dan arsitektur TI.
3. Daftar risiko dan pengendalian.
4. Hak akses dan otorisasi.
5. Log dan jejak audit.
6. Backup, restore, dan rencana pemulihan.
7. Keamanan informasi dan insiden.
8. Vendor dan aplikasi inti perbankan.
9. Audit intern dan tindak lanjut.
10. Laporan, rekonsiliasi, dan koreksi.
11. Sumber daya manusia dan pelatihan.
12. Daftar demo sistem.

Setiap item sebaiknya punya keterangan singkat: nama dokumen, nomor versi, tanggal berlaku, pemilik, dan lokasi berkas. Kalau pemeriksa bertanya “mana bukti peninjauan akses kuartal lalu?”, jawabannya bukan “saya cari dulu”, tetapi satu tautan atau satu folder yang sudah ditentukan.

Ada tiga aturan penting.

Pertama, jangan membuat dokumen baru yang isinya belum pernah dijalankan. Dokumen yang baru dicetak menjelang pemeriksaan mudah terlihat dari tanggal, tanda tangan, dan ketidakcocokan dengan log.

Kedua, bedakan dokumen yang mengatur dan dokumen yang membuktikan. SOP mengatur. Log membuktikan. Keduanya diperlukan.

Ketiga, simpan bukti dalam bentuk yang bisa dibaca pemeriksa. File scan yang miring dan tidak bisa dicari mungkin masih diterima, tetapi memperlambat semua orang. Beri nama file yang menjelaskan isinya, bukan “IMG_20261027”.

Indeks bukti juga membantu saat terjadi pergantian staf. Pengetahuan tidak hilang bersama orang yang menyiapkannya.

5. Saat Pemeriksa Meminta Melihat Sistem

Dokumen bisa disiapkan sebelumnya. Demo sistem tidak. Karena itu, latih satu atau dua orang untuk menunjukkan sistem dengan tenang, jujur, dan runtut.

Pilih pengguna demo yang sesuai perannya. Jangan memakai akun administrator untuk semua demonstrasi. Tunjukkan bahwa teller tidak bisa menyetujui kredit, bahwa pembuat transaksi tidak otomatis menjadi penyetuju, dan bahwa perubahan data meninggalkan jejak.

Susun urutan demo yang sederhana:

1. Tunjukkan struktur peran dan hak akses.
2. Buat satu transaksi contoh dari awal sampai disetujui.
3. Buka jejak audit transaksi itu: siapa, kapan, dari perangkat mana, dan apa yang berubah.
4. Tunjukkan daftar pengguna serta bukti peninjauan akses terakhir.
5. Tunjukkan status backup dan laporan uji restore.
6. Tunjukkan bagaimana laporan dihasilkan dan direkonsiliasi.
7. Tunjukkan catatan insiden dan tindak lanjutnya.

Saat demo, hindari tiga hal. Jangan mengarang jawaban. Jangan menyalahkan vendor di depan pemeriksa tanpa bukti. Jangan berjanji menyelesaikan sesuatu tanpa tenggat dan penanggung jawab.

Kalau ada pengendalian yang belum berjalan, katakan dengan jelas: “Pengendalian ini belum berjalan penuh. Yang sudah kami lakukan adalah X. Rencana penutupannya Y, dengan penanggung jawab Z dan tenggat tanggal tertentu.” Jawaban seperti ini lebih baik daripada klaim kosong.

Pasal 6 POJK 41/2017 mewajibkan bank memberi data dan keterangan dengan segera serta tidak menghambat pemeriksaan. Karena itu, siapkan akses baca, ruang kerja, dan orang yang berwenang menjawab sebelum pemeriksa datang. Jangan membuat pemeriksa menunggu persetujuan internal berhari-hari untuk dokumen yang seharusnya sudah tersedia.

6. Aturan TI Baru Berlaku 18 Desember 2026

Ada perubahan besar yang perlu masuk ke rencana persiapan. POJK 34/2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah menggantikan POJK 75/2016. Menurut Pasal 53 dan abstrak resmi OJK, aturan ini berlaku 18 Desember 2026. Pedoman teknisnya, PADK 43/PADK.03/2025, menggantikan SEOJK 15/2017 dan berlaku sehari sebelumnya, 17 Desember 2026.

Sampai kedua aturan baru berlaku, POJK 75/2016 dan SEOJK 15/2017 masih menjadi acuan. Pemeriksaan yang berlangsung sebelum masa itu akan menilai kepatuhan pada kerangka yang berlaku saat itu. Namun, bank yang baru selesai menutup temuan lama lalu mengabaikan aturan baru akan segera menghadapi celah yang sama.

Berikut pergeseran yang paling terasa.

Aspek	Kerangka lama	Kerangka baru
Tata kelola TI	Tanggung jawab Direksi dan Dewan Komisaris diatur	Ditambah kewajiban satuan kerja TI yang independen dan penguatan pengawasan
Uji pemulihan	Minimal sekali dalam tiga tahun	Dua tahun untuk bank dengan layanan digital; tiga tahun untuk bank lain
Pusat pemulihan bencana	Diwajibkan bagi bank dengan modal inti minimal Rp50 miliar	Diwajibkan bagi bank dengan modal inti minimal Rp50 miliar dan/atau yang menyediakan layanan digital
Keamanan siber	Pengamanan informasi dan penanganan insiden	Ditambah penilaian maturitas keamanan siber tahunan
Vendor TI	Kerja sama dan pengawasan vendor	Kewajiban kontrak yang lebih rinci, laporan gangguan, dan exit plan
Audit intern TI	Minimal sekali setahun	Tetap tahunan, dengan pedoman audit dan jejak audit yang ditegaskan
Pelaporan insiden	Laporan kejadian kritis	Notifikasi awal 24 jam dan laporan insiden 7 hari kerja
Pelindungan data	Kewajiban menjaga data nasabah	Pengelolaan data dan pelindungan data pribadi ditegaskan

Jangan menunggu Desember untuk mulai. Lakukan penilaian celah pada November. Bandingkan kebijakan, kontrak vendor, jadwal uji pemulihan, dan prosedur insiden dengan POJK 34/2025 serta PADK 43/2025. Tandai mana yang sudah sesuai, mana yang perlu diubah, dan mana yang belum ada.

Beberapa hal sebaiknya selesai sebelum 18 Desember 2026: kebijakan TI yang diperbarui dan disetujui, prosedur pelaporan insiden dengan tenggat 24 jam dan 7 hari kerja, jadwal penilaian maturitas siber, rencana uji pemulihan, dan addendum kontrak vendor untuk klausul akses serta exit plan.

7. Temuan yang Sering Berulang dan Cara Menutupnya

Temuan pemeriksaan jarang berupa kecurangan besar. Sebagian besar adalah pengendalian yang direncanakan, tetapi tidak dijalankan secara konsisten. Berikut delapan contoh yang sering muncul.

Temuan	Akar masalah	Bukti penutupan
SOP belum ditandatangani atau kedaluwarsa	Dokumen dibuat tanpa persetujuan resmi	SOP bertanda tangan, tanggal berlaku, dan bukti sosialisasi
Akun dipakai bersama	Tidak ada akun pribadi atau proses pencabutan	Daftar akun unik, pencabutan akun lama, dan peninjauan akses
Jejak audit tidak pernah diperiksa	Log disimpan, tetapi tidak dipantau	Jadwal dan laporan pemantauan log
Backup berhasil, restore belum pernah diuji	Keberhasilan backup dianggap cukup	Laporan uji restore dengan hasil dan waktu pemulihan
Rencana pemulihan tidak pernah diuji	Tidak ada jadwal atau anggaran uji	Laporan simulasi, daftar kegagalan, dan tindak lanjut
Kontrak vendor tidak memberi akses kepada OJK	Kontrak lama belum disesuaikan	Addendum kontrak dan bukti pemantauan SLA
Temuan audit tahun lalu tidak ditutup	Tidak ada pemilik dan tenggat	Action plan dengan status, bukti, dan tanggal selesai
Angka laporan berbeda dengan aplikasi inti perbankan	Rekonsiliasi tidak rutin	Kertas kerja rekonsiliasi dan log koreksi

Perhatikan kolom terakhir. Pemeriksa tidak hanya ingin tahu apa yang diperbaiki. Mereka ingin melihat bukti bahwa perbaikan itu bertahan. Ganti “sudah kami sosialisasikan” dengan daftar hadir dan materi. Ganti “sudah diperbaiki” dengan tangkapan layar konfigurasi, log, dan uji ulang.

Temuan yang berulang biasanya bukan masalah teknis. Ia masalah kepemilikan: tidak ada satu orang yang bertanggung jawab, tidak ada tenggat, dan tidak ada bukti penyelesaian.

8. Rencana 90 Hari

Gunakan rencana berikut sebagai kerangka. Sesuaikan dengan ukuran bank, jumlah cabang, dan temuan sebelumnya.

Waktu	Fokus	Keluaran
0–30 hari	Inventaris sistem, dokumen, dan temuan lama; tetapkan pemilik setiap area	Daftar sistem, indeks bukti, peta celah, dan penanggung jawab
31–60 hari	Tutup celah berisiko tinggi: akun bersama, backup, kontrak vendor, akses istimewa	Akun bersih, laporan uji restore, addendum kontrak, dan bukti peninjauan akses
61–90 hari	Simulasi pemeriksaan, demo sistem, wawancara, dan tindak lanjut	Laporan simulasi, daftar perbaikan, dan laporan kepada Direksi

Tiga hal yang membuat rencana ini berjalan.

Pertama, satu pemilik per area. Jangan membuat panitia besar tanpa pembagian tugas. Setiap area punya satu nama yang bertanggung jawab dan satu tenggat.

Kedua, bukti dikumpulkan sambil bekerja. Jangan menunggu akhir bulan untuk mencari log, tiket, atau persetujuan. Simpan bukti saat pekerjaan dilakukan.

Ketiga, Direksi memeriksa kemajuan. Pemeriksaan bukan urusan tim TI sendirian. Direksi perlu melihat daftar celah, risiko, dan keputusan yang dibutuhkan. Kalau ada perbaikan yang butuh anggaran, putuskan lebih awal.

Setelah pemeriksaan selesai, jangan membubarkan tim. Simpan indeks bukti, catat permintaan pemeriksa, dan buat rencana tindak lanjut. Pemeriksaan berikutnya akan lebih mudah karena pekerjaan hari ini tidak hilang.

9. Kesimpulan

Pemeriksaan OJK dari sisi sistem dan TI bukan soal memiliki aplikasi yang paling canggih. Yang dinilai adalah apakah kebijakan, konfigurasi, dan catatan operasional berbicara hal yang sama.

Mulailah dari tiga lapis bukti. Pastikan kebijakan disetujui dan berlaku. Pastikan konfigurasi sistem sesuai kebijakan. Pastikan log, tiket, dan laporan menunjukkan bahwa keduanya benar-benar dijalankan.

Siapkan indeks bukti dengan pemilik yang jelas. Latih demo sistem dengan akun yang sesuai peran. Jawab pertanyaan pemeriksa dengan fakta, bukan janji. Kalau ada celah, tunjukkan rencana penutupan beserta tenggat dan buktinya.

POJK 34/2025 akan berlaku 18 Desember 2026. Bank yang mulai merapikan bukti sekarang tidak hanya siap menghadapi pemeriksaan tahun ini. Mereka juga siap menghadapi aturan baru tanpa harus memulai dari nol.

Referensi

1. OJK — “POJK Nomor 41/POJK.03/2017 tentang Persyaratan dan Tata Cara Pemeriksaan Bank”. https://ojk.go.id/id/regulasi/Pages/Persyaratan-dan-Tata-Cara-Pemeriksaan-Bank-.aspx
2. OJK — “POJK Nomor 75/POJK.03/2016 tentang Standar Penyelenggaraan Teknologi Informasi bagi Bank Perkreditan Rakyat dan Bank Pembiayaan Rakyat Syariah”. https://peraturan.bpk.go.id/Details/129781/peraturan-ojk-no-75-pojk032016-tahun-2016
3. OJK — “SEOJK Nomor 15/SEOJK.03/2017 tentang Standar Penyelenggaraan Teknologi Informasi bagi Bank Perkreditan Rakyat dan Bank Pembiayaan Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/SEOJK-tentang-Standar-Penyelenggaraan-Teknologi-Informasi-bagi-Bank-Perkreditan-Rakyat-dan-Bank-Pembiayaan-Rakyat-Syariah.aspx
4. OJK — “POJK Nomor 9 Tahun 2024 tentang Penerapan Tata Kelola bagi Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/POJK-9-2024-Penerapan-Tata-Kelola-bagi-BPR-dan-BPRS.aspx
5. OJK — “POJK Nomor 12 Tahun 2024 tentang Penerapan Strategi Anti Fraud bagi Lembaga Jasa Keuangan”. https://peraturan.bpk.go.id/Details/301737/peraturan-ojk-no-12-tahun-2024
6. OJK — “POJK Nomor 34 Tahun 2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/POJK-34-Tahun-2025-Penyelenggaraan-Teknologi-Informasi-oleh-Bank-Perekonomian-Rakyat-dan-Bank-Perekonomian-Rakyat-Syariah.aspx
7. OJK — “PADK Nomor 43/PADK.03/2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/PADK-43-PADK03-2025-Penyelenggaraan-Teknologi-Informasi-oleh-BPR-BPRS.aspx