Seorang pemeriksa membuka daftar transaksi dan menunjuk satu baris. Ada transfer keluar Rp48 juta pada pukul 23.40, jauh setelah jam layanan. Ia bertanya: siapa yang memasukkan transaksi ini? Petugas bank membuka log sistem. Yang muncul hanya satu nama pengguna: admin.

Nama itu dipakai oleh tiga orang. Dua di antaranya sudah pindah tugas, dan kata sandinya tidak pernah diganti. Tidak ada catatan terminal mana yang dipakai, tidak ada alasan transaksi, dan tidak ada bukti siapa yang menyetujui.

Ini merupakah kelemahan yang sering muncul di BPR, BPRS, maupun Koperasi. Pemeriksa tidak menemukan jawaban karena sistem memang tidak menyimpan jawaban. Sistem mencatat bahwa transaksi terjadi, tetapi tidak mencatat siapa yang melakukannya.

Artikel ini membahas audit trail dan keamanan data dari sudut pandang pemeriksaan: apa yang dicari, bukti apa yang harus ada, kontrol apa yang perlu dipasang, dan bagaimana menyiapkannya tanpa menunggu sistem baru.

1. Pemeriksa tidak berhenti pada laporan

Laporan menunjukkan hasil. Audit trail menunjukkan proses. Pemeriksa membutuhkan keduanya karena laporan yang benar bisa dihasilkan dengan cara yang salah.

Contohnya sederhana. Saldo tabungan nasabah bisa tampak benar karena ada transaksi koreksi yang mengembalikan angka. Tanpa jejak, tidak ada yang tahu siapa yang membuat koreksi, atas dasar apa, dan apakah koreksi itu disetujui. Angka akhirnya benar, tetapi prosesnya tidak dapat dipertanggungjawabkan.

Inilah sebabnya pemeriksaan sistem informasi tidak berhenti pada daftar pengguna dan daftar transaksi. Pemeriksa menelusuri satu transaksi dari awal sampai akhir: siapa yang memasukkan, siapa yang menyetujui, kapan, dari perangkat mana, dan apa yang berubah.

Jika rantai itu putus di satu titik, temuan muncul. Bukan karena transaksinya salah, tetapi karena bank tidak bisa membuktikan bahwa transaksi itu sah.

2. Apa yang dimaksud audit trail

PADK 43/2025 mendefinisikan rekam jejak audit sebagai file di komputer yang menyimpan informasi mengenai kegiatan pengguna atau komputer secara kronologis, yang dapat digunakan untuk audit atau penelusuran.

Definisi itu memuat tiga kata kunci. File, artinya catatan tersimpan, bukan hanya tampil di layar. Kronologis, artinya urutan waktu bisa dipertanggungjawabkan. Penelusuran, artinya catatan itu cukup untuk merekonstruksi kejadian.

Kata kronologis sering disederhanakan menjadi “ada tanggal dan jam”. Padahal yang dimaksud lebih dari itu. Urutan kejadian harus masuk akal ketika dibaca berderet: login, buka menu, masukkan transaksi, minta persetujuan, transaksi dibukukan. Jika urutan itu terbalik karena jam antar-server berbeda, log kehilangan makna sebagai bukti.

POJK 34/2025 menempatkan kewajiban ini di dua tempat. Pasal 31 huruf e mewajibkan aplikasi inti perbankan memiliki log aktivitas sistem. Pasal 40 ayat (4) mewajibkan bank memastikan tersedianya jejak audit terhadap seluruh kegiatan penyelenggaraan TI untuk keperluan pengawasan, penegakan hukum, penyelesaian sengketa, verifikasi, pengujian, dan pemeriksaan lainnya.

Perhatikan daftar keperluan itu. Audit trail bukan hanya untuk auditor. Ia dipakai ketika nasabah menyanggah transaksi, ketika penyidik meminta data, dan ketika bank sendiri perlu membuktikan bahwa sistemnya bekerja.

Anatomi satu baris audit trail: identitas pengguna, peran, waktu, terminal, aksi, objek, nilai sebelum dan sesudah, hasil, serta nomor korelasi
Satu baris log yang baik menjawab siapa, kapan, dari mana, melakukan apa, pada data apa, dan dengan hasil apa.

3. Isi minimum satu baris log

Banyak sistem sudah mencatat transaksi, tetapi catatannya tidak cukup untuk menjawab pertanyaan pemeriksa. Sebelum menambah alat baru, periksa apakah log yang ada memuat unsur berikut.

Unsur Contoh Mengapa diperlukan
Identitas pengguna user_id, bukan nama bersama Menentukan siapa yang bertindak
Peran dan kewenangan Teller, supervisor, admin Menilai apakah tindakan sesuai hak
Waktu 2026-11-03 23:40:12 WIB Menyusun urutan kejadian
Perangkat dan lokasi Terminal cabang, alamat IP Menghubungkan tindakan dengan tempat
Jenis aksi Ubah, hapus, setujui, ekspor Menjelaskan apa yang dilakukan
Objek Nomor rekening, nomor transaksi Menentukan data yang tersentuh
Nilai sebelum dan sesudah Saldo Rp10 juta menjadi Rp10,5 juta Membuktikan perubahan
Hasil Berhasil atau ditolak Membedakan percobaan dan tindakan
Nomor korelasi trace_id yang sama di beberapa sistem Menyatukan jejak lintas aplikasi

Tidak semua sistem memiliki seluruh unsur itu sejak awal. Namun, kekurangan harus diketahui dan ditutup. Log yang hanya memuat “transaksi berhasil” tidak bisa dipakai untuk memeriksa penyalahgunaan.

Satu hal yang sering terlewat adalah alasan perubahan. Untuk transaksi koreksi, pembatalan, atau perubahan parameter, alasan bukan pelengkap. Ia yang membedakan koreksi yang sah dari manipulasi.

4. Apa yang diuji pemeriksa

Pemeriksa biasanya tidak membaca seluruh log. Mereka mengambil sampel, lalu menguji apakah log itu lengkap, akurat, dan dapat dipercaya. Beberapa pertanyaan berikut sering muncul.

Pertanyaan pemeriksa Bukti yang diminta Celah yang sering ditemukan
Siapa yang mengubah data ini? Log perubahan dengan identitas tunggal Akun dipakai bersama
Kapan perubahan terjadi? Stempel waktu yang sinkron Jam server berbeda antar-cabang
Apakah perubahan disetujui? Log persetujuan dan nama penyetuju Maker-checker hanya formalitas
Apakah log bisa diubah? Hak akses terbatas dan bukti integritas Admin basis data dapat menghapus log
Berapa lama log disimpan? Kebijakan retensi dan arsip Log hilang setelah beberapa minggu
Apakah log diperiksa? Bukti reviu berkala dan tindak lanjut Log ada, tetapi tidak pernah dibaca
Apakah ekspor data tercatat? Log unduhan dan tujuan ekspor Data debitur diunduh tanpa jejak

Pertanyaan-pertanyaan ini mengarah pada satu kesimpulan: log bukan sekadar fitur aplikasi, melainkan bukti pengendalian. Sistem yang mencatat tetapi tidak menjaga catatannya belum memenuhi tujuan audit trail.

Ada satu pengujian yang paling sering membuat bank kesulitan, yaitu menelusuri satu transaksi lengkap. Pemeriksa memilih satu transaksi, lalu meminta jejak dari input sampai pembukuan. Jika jejak terputus di aplikasi teller, di antrean integrasi, atau di jurnal, temuan muncul. Karena itu, nomor korelasi antarsistem penting. Tanpa nomor itu, setiap sistem bercerita sendiri.

Contohnya transaksi setoran di cabang. Aplikasi teller mencatat nomor transaksi TRX-1187. Antrean integrasi mencatat pesan dengan nomor lain. Aplikasi inti mencatat jurnal dengan nomor ketiga. Ketiganya merujuk ke kejadian yang sama, tetapi tidak ada benang merah. Pemeriksa harus mencocokkan nominal dan waktu secara manual. Jika ada dua transaksi bernilai sama pada menit yang sama, pencocokan menjadi tidak mungkin. Nomor korelasi menyelesaikan masalah ini sebelum terjadi.

5. Lima celah yang paling sering

Pertama, akun bersama. Satu akun dipakai beberapa petugas karena shift berganti atau karena lupa membuat akun baru. Akibatnya, log mencatat nama akun, bukan nama orang. Ketika terjadi masalah, tidak ada yang bisa ditunjuk.

Kedua, log yang dapat diubah. Log disimpan di basis data yang sama dengan data transaksi. Administrator basis data dapat menghapus atau mengubah baris log. Dalam kondisi itu, log tidak bisa disebut bukti.

Ketiga, waktu yang tidak sinkron. Server aplikasi, server basis data, dan perangkat jaringan memakai jam berbeda. Selisih beberapa menit terlihat kecil, tetapi cukup untuk membuat urutan kejadian tidak masuk akal. Pemeriksa bisa menemukan transaksi yang tercatat disetujui sebelum dimasukkan.

Keempat, retensi yang terlalu pendek. Log hanya disimpan sampai pemeliharaan berikutnya. Ketika pemeriksaan dilakukan enam bulan kemudian, data yang dibutuhkan sudah hilang. Retensi harus ditetapkan dalam kebijakan dan diuji, bukan diserahkan pada pengaturan bawaan aplikasi.

Kelima, log tidak pernah dibaca. Bank memiliki log, tetapi tidak ada yang memeriksa. Padahal PADK 43/2025 meminta jejak audit dipantau secara teratur untuk mendeteksi penyimpangan sedini mungkin. Log yang tidak dibaca hanya menambah biaya penyimpanan.

Tujuh pengujian audit trail oleh pemeriksa: identitas pelaku, waktu kejadian, persetujuan, integritas log, retensi, reviu berkala, dan pencatatan ekspor data
Pemeriksa menguji apakah log lengkap, akurat, terjaga, dan benar-benar dipakai, bukan hanya ada.

6. Kontrol yang membuat log layak dipercaya

Tidak semua kontrol membutuhkan biaya besar. Beberapa yang paling penting justru berkaitan dengan kebiasaan dan pengaturan hak akses.

Satu orang, satu akun. Setiap petugas memakai akun sendiri. Akun bersama dihapus, termasuk akun admin yang dipakai bergantian. Jika jumlah akun menjadi mahal, itu masalah lisensi, bukan alasan berbagi identitas.

Pemisahan hak akses. Petugas yang menjalankan transaksi tidak boleh menghapus log. Administrator sistem tidak boleh menyetujui transaksi bisnis. Prinsip ini membatasi kemungkinan satu orang menutup jejaknya sendiri.

Penyimpanan log terpisah. Log dikirim ke server atau layanan penyimpanan terpisah dari basis data transaksi. Akses tulis ke penyimpanan itu dibatasi, dan perubahan pada log menghasilkan peringatan.

Catatan tambah-saja. Log tidak boleh diubah atau dihapus melalui aplikasi. Jika memungkinkan, gunakan penyimpanan yang hanya menerima penambahan, atau buat sidik jari digital atas berkas log secara berkala untuk membuktikan tidak ada perubahan.

Sinkronisasi waktu. Semua perangkat memakai sumber waktu yang sama. Selisih waktu dipantau, dan peringatan muncul jika melewati batas yang ditetapkan.

Reviu berkala. Log akses istimewa, perubahan hak akses, transaksi di luar jam kerja, dan ekspor data diperiksa setiap periode. Hasil reviu disimpan sebagai bukti, termasuk tindak lanjut atas kejadian yang mencurigakan.

Pemantauan otomatis. Untuk bank dengan volume transaksi besar, reviu manual tidak cukup. Sistem pemantauan dapat memberi peringatan atas pola tertentu, misalnya banyak percobaan login gagal, perubahan parameter di luar jam kerja, atau satu pengguna mengakses rekening yang tidak biasa.

Kontrol Tujuan Bukti yang dihasilkan
Akun tunggal per petugas Menentukan pelaku Daftar pengguna dan log login
Pemisahan tugas Mencegah penutupan jejak Matriks hak akses
Penyimpanan terpisah Menjaga integritas Konfigurasi dan uji akses
Sinkronisasi waktu Menjaga urutan kejadian Laporan selisih waktu
Reviu berkala Mendeteksi penyimpangan Kertas kerja reviu
Retensi dan arsip Menjaga ketersediaan bukti Kebijakan dan uji pemulihan

Kontrol yang dipasang belum tentu berjalan. Karena itu, setiap kontrol perlu diuji dengan cara sederhana: coba hapus satu baris log dari aplikasi dan pastikan sistem menolak; ubah jam perangkat dan lihat apakah peringatan muncul; minta satu petugas membuka log transaksi yang bukan tugasnya dan periksa apakah akses ditolak. Hasil pengujian dicatat, termasuk tanggal, penguji, dan temuan. Tanpa pengujian, bank hanya memiliki daftar niat, bukan kontrol yang terbukti bekerja.

Enam lapis pengamanan audit trail: akun tunggal per petugas, pemisahan tugas, penyimpanan log terpisah, sinkronisasi waktu, reviu berkala, dan retensi yang diuji pemulihannya
Kontrol audit trail bertumpu pada identitas, pemisahan, integritas, dan reviu yang benar-benar dijalankan.

7. Keamanan data di dalam log

Audit trail sendiri mengandung data pribadi. Log dapat memuat nomor rekening, nama nasabah, nomor identitas, dan nominal transaksi. Karena itu, melindungi log sama pentingnya dengan melindungi basis data utama.

Beberapa prinsip yang perlu dipegang:

  • Jangan mencatat yang tidak perlu. Kata sandi, kode OTP, dan nomor kartu lengkap tidak boleh masuk log.
  • Samarkan data sensitif. Nomor identitas dan nomor rekening dapat ditampilkan sebagian, selama masih cukup untuk penelusuran.
  • Batasi akses ke log. Tidak semua staf perlu membaca seluruh log. Akses diberikan berdasarkan tugas, dan setiap akses ke log dicatat.
  • Simpan sesuai tujuan. Log disimpan untuk keperluan tertentu, bukan untuk dikumpulkan tanpa batas. Kebijakan retensi harus menjelaskan tujuan dan jangka waktunya.
  • Hapus secara terkendali. Setelah masa retensi berakhir, penghapusan dilakukan sesuai prosedur dan dicatat.

UU 27/2022 tentang Pelindungan Data Pribadi berlaku ketika log memuat data pribadi. Kewajiban ini sejalan dengan POJK 34/2025 Pasal 36, yang mewajibkan bank melaksanakan prinsip pelindungan data pribadi dalam pemrosesan data. Penjelasan lengkapnya ada di artikel UU PDP untuk BPR dan BPRS.

Satu kesalahan yang sering terjadi adalah memberi akses log kepada tim TI tanpa batas, dengan alasan “untuk troubleshooting”. Akses itu wajar, tetapi harus melalui prosedur, tercatat, dan ditinjau. Tanpa itu, tim yang seharusnya menjaga log justru menjadi pihak yang paling sulit diaudit.

Hal yang sama berlaku untuk akses vendor. Penyedia jasa TI kadang memerlukan akses ke log untuk menangani gangguan. Akses itu sebaiknya diberikan untuk jangka waktu terbatas, dengan tiket yang jelas, didampingi petugas bank, dan dicatat dalam log akses istimewa. Setelah pekerjaan selesai, akses dicabut dan bukti pencabutan disimpan. Tanpa pengaturan ini, vendor memiliki jalan masuk yang tidak terlihat dalam laporan pengguna biasa.

8. Menyiapkan bukti sebelum diminta

Pemeriksaan berjalan lebih lancar jika bukti sudah tersusun. Bank tidak perlu membangun arsip baru; cukup merapikan yang sudah ada dan memastikan bisa ditemukan.

Bukti yang sebaiknya siap:

  1. Kebijakan dan prosedur pengelolaan log, hak akses, dan retensi.
  2. Daftar pengguna beserta peran, tanggal aktif, dan tanggal pencabutan akses.
  3. Matriks hak akses yang menunjukkan pemisahan tugas.
  4. Konfigurasi penyimpanan log, sinkronisasi waktu, dan masa retensi.
  5. Kertas kerja reviu log untuk beberapa periode terakhir.
  6. Catatan insiden yang ditemukan melalui log, beserta tindak lanjutnya.
  7. Bukti uji pemulihan log dari arsip.
  8. Bukti pencabutan akses untuk petugas yang berhenti atau pindah.

POJK 41/2017 Pasal 6 mewajibkan bank segera memperlihatkan buku, dokumen, data elektronik, dan keterangan yang diperlukan saat pemeriksaan. Log dan bukti pengelolaannya termasuk data elektronik yang harus bisa disediakan. Jika log hanya bisa dibuka oleh satu orang yang sedang cuti, kewajiban itu praktis tidak terpenuhi.

Saat menyerahkan cuplikan log kepada pemeriksa, bank perlu menjaga rantai penguasaan bukti. Cuplikan diberi keterangan tanggal pengambilan, sistem asal, periode, dan petugas yang mengambil. Jika memungkinkan, sertakan nilai hash berkas agar pemeriksa dapat memastikan cuplikan tidak berubah. Cara ini sederhana, tetapi menunjukkan bahwa bank memperlakukan log sebagai bukti, bukan sebagai file kerja biasa.

9. Rencana 90 hari

Waktu Fokus Keluaran
30 hari Petakan log yang ada, pemilik akun, dan hak istimewa Daftar sistem, akun, dan celah
45 hari Tutup akun bersama dan pisahkan hak akses Akun tunggal dan matriks akses
60 hari Pindahkan log ke penyimpanan terpisah dan sinkronkan waktu Konfigurasi dan uji akses
75 hari Tetapkan retensi, prosedur reviu, dan format kertas kerja Kebijakan dan jadwal reviu
90 hari Jalankan reviu pertama dan uji penelusuran satu transaksi Laporan reviu dan perbaikan

Rencana ini tidak menuntut penggantian core banking. Sebagian besar perbaikan dapat dilakukan pada konfigurasi, prosedur, dan disiplin pengguna. Jika sistem lama tidak mendukung pemisahan log, bank perlu menilai risiko dan menyiapkan langkah sementara, misalnya pengiriman log ke server terpisah dan reviu manual yang lebih ketat.

10. Kesalahan umum

Pertama, menganggap log sama dengan laporan transaksi. Laporan menunjukkan hasil, log menunjukkan proses. Keduanya diperlukan.

Kedua, membiarkan akun bersama. Ini kesalahan yang paling sering dan paling merusak. Tanpa identitas tunggal, audit trail kehilangan nilai utamanya.

Ketiga, menyimpan log di tempat yang dapat diubah oleh penggunanya. Log harus berada di luar kendali aplikasi dan administrator basis data.

Keempat, mengabaikan waktu. Stempel waktu yang tidak sinkron membuat urutan kejadian tidak dapat dipercaya.

Kelima, menetapkan retensi tanpa menguji pemulihan. Log yang disimpan tetapi tidak bisa dibuka sama saja dengan log yang hilang.

Keenam, mencatat data pribadi secara berlebihan. Log yang terlalu banyak memuat data sensitif menambah risiko kebocoran.

Ketujuh, tidak pernah mereviu. Log yang tidak dibaca tidak mendeteksi apa pun.

11. Kesimpulan

Audit trail adalah bukti bahwa bank tahu apa yang terjadi di sistemnya. Ia menjawab pertanyaan yang tidak bisa dijawab oleh laporan: siapa, kapan, dari mana, dan atas dasar apa.

POJK 34/2025 mewajibkan aplikasi inti memiliki log aktivitas sistem dan mewajibkan jejak audit tersedia untuk pengawasan, penegakan hukum, penyelesaian sengketa, verifikasi, pengujian, dan pemeriksaan. PADK 43/2025 menambahkan kewajiban memantau log dan meninjau hak akses secara berkala.

Yang paling menentukan bukan jenis aplikasinya, melainkan disiplin penggunaannya. Akun tunggal, pemisahan tugas, penyimpanan terpisah, waktu yang sinkron, dan reviu yang benar-benar dilakukan adalah fondasi yang bisa dibangun sekarang.

Jika pemeriksa meminta penelusuran satu transaksi, bank yang siap akan membuka satu layar dan menunjukkan rantainya. Bank yang belum siap akan mencari orang yang mungkin masih ingat. Perbedaan itu tidak ditentukan pada hari pemeriksaan, tetapi pada kebiasaan berbulan-bulan sebelumnya.

Referensi

  1. Otoritas Jasa Keuangan — “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
  2. Otoritas Jasa Keuangan — “PADK Nomor 43/PADK.03/2025 tentang Penyelenggaraan Teknologi Informasi oleh BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/PADK-43-PADK03-2025-Penyelenggaraan-Teknologi-Informasi-oleh-BPR-BPRS.aspx
  3. Otoritas Jasa Keuangan — “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
  4. Otoritas Jasa Keuangan — “SEOJK Nomor 15/SEOJK.03/2017 tentang Standar Penyelenggaraan Teknologi Informasi bagi BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/SEOJK-tentang-Standar-Penyelenggaraan-Teknologi-Informasi-bagi-Bank-Perkreditan-Rakyat-dan-Bank-Pembiayaan-Rakyat-Syariah.aspx
  5. Otoritas Jasa Keuangan — “POJK Nomor 41 Tahun 2017 tentang Persyaratan dan Tata Cara Pemeriksaan Bank”. https://ojk.go.id/id/regulasi/Pages/Persyaratan-dan-Tata-Cara-Pemeriksaan-Bank-.aspx
  6. Otoritas Jasa Keuangan — “POJK Nomor 12 Tahun 2024 tentang Strategi Anti Fraud”. https://peraturan.bpk.go.id/Details/301737/peraturan-ojk-no-12-tahun-2024
  7. Republik Indonesia — “Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi”. https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022
  8. Otoritas Jasa Keuangan — “POJK Nomor 9 Tahun 2024 tentang Penerapan Tata Kelola bagi BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/POJK-9-2024-Penerapan-Tata-Kelola-bagi-BPR-dan-BPRS.aspx