Pernah ada keputusan penting yang dipertanyakan karena tidak jelas siapa yang menyetujui, kapan, dan dengan dasar apa? Masalah ini sering muncul saat alur persetujuan tersebar di email, chat, dan spreadsheet, sementara tim keamanan diminta memastikan kontrol akses dan jejak audit rapi. Dengan checklist audit trail teknis di bawah ini, Anda bisa menilai apakah sistem persetujuan internal punya bukti yang kuat, mudah diaudit, dan tahan terhadap penyalahgunaan maupun kesalahan operasional.
1) Definisikan peristiwa yang wajib terekam dan bentuk buktinya
Log yang sekadar ada belum tentu bisa dijadikan bukti. Mulailah dengan memetakan peristiwa operasional dan risiko yang memang harus terekam, lalu tentukan atribut minimal agar rekonstruksi kejadian bisa dipercaya.
Untuk sistem persetujuan internal, peristiwa kritikal meliputi pembuatan permintaan, perubahan data inti, pengajuan untuk persetujuan, persetujuan atau penolakan, delegasi, pembatalan, dan eskalasi. Sertakan juga kejadian administratif seperti perubahan role, konfigurasi workflow, dan aturan otorisasi karena dampaknya sering besar.
- Identitas subjek: user ID yang stabil (bukan sekadar nama tampilan), asal autentikasi (SSO/IdP), dan role saat kejadian.
- Objek dan versinya: ID dokumen/permintaan, versi atau hash payload, serta field yang berubah (before/after bila memungkinkan).
- Waktu yang dapat dipercaya: timestamp dengan timezone konsisten, sinkronisasi NTP, dan pencatatan “received time” vs “processed time” untuk sistem terdistribusi.
- Konteks akses: IP, device/session ID, client aplikasi, serta hasil policy check (allowed/denied + alasan).
- Hasil dan alasan: status akhir (approve/reject/return), komentar, dan kode alasan terstruktur untuk pelaporan.
Contoh praktis: untuk persetujuan vendor baru, auditor biasanya meminta bukti siapa yang memasukkan data rekening, siapa yang menyetujui, dan apakah ada perubahan setelahnya. Jika log tidak menyimpan versi data saat disetujui, Anda akan kesulitan menjelaskan rekening yang dimaksud.
2) Pastikan integritas, ketertelusuran, dan ketahanan terhadap manipulasi
Langkah berikutnya fokus pada integritas audit trail: apakah catatan dapat dipercaya atau bisa diubah tanpa jejak. Desain penyimpanan log dan kontrol pada pipeline logging sama pentingnya dengan event yang dicatat.
Checklist teknis yang biasa dipakai saat menilai kontrol antara lain:
- Immutability: log disimpan di media append-only atau mekanisme WORM, atau minimal ada proteksi perubahan (misalnya object lock) dan audit log terpisah untuk modifikasi.
- Chain of custody: ada jejak dari aplikasi ke log store (misalnya signing/hashing per batch) dan proses pengambilan bukti terdokumentasi.
- Segregation of duties: admin aplikasi tidak punya hak menghapus log; akses ke log dipisahkan dari akses konfigurasi workflow.
- Anti-tamper monitoring: alert untuk anomali seperti lonjakan error logging, log drop, perubahan kebijakan retensi, atau pemutusan integrasi SIEM.
- Rekonsiliasi: metrik yang membandingkan jumlah transaksi vs jumlah event log agar kehilangan log cepat terdeteksi.
- Clock hygiene: deteksi drift waktu; gunakan server-side timestamps untuk keputusan otorisasi, bukan waktu dari klien.
Jika Anda memakai arsitektur microservices, perhatikan korelasi antar layanan. Praktik yang membantu adalah menetapkan correlation ID end-to-end dari UI sampai service yang memutuskan authorize atau approve, sehingga satu permintaan mudah ditelusuri meski melewati banyak komponen.
Risiko besar sering muncul dari perubahan konfigurasi approval di menit terakhir. Pastikan setiap perubahan rule workflow (misalnya ambang nominal, jalur approver, atau kondisi bypass) tercatat sebagai configuration change event lengkap dengan siapa, kapan, dan nilai sebelum-sesudah.
3) Audit kontrol akses dan desain persetujuan: mencegah approve yang tidak sah
Audit trail yang baik harus didukung kontrol akses yang benar. Tanpa itu, log hanya akan membuktikan bahwa sistem mengizinkan tindakan yang seharusnya dilarang.
Gunakan pendekatan gabungan: nilai kebijakan (policy) dan pastikan implementasinya (enforcement) sesuai. Sering terlewat hubungan antara identitas, role, dan kondisi bisnis saat keputusan diambil.
- RBAC/ABAC yang jelas: definisi role dan atribut (unit, lokasi, cost center) terdokumentasi; perubahan role terekam dan dapat diaudit.
- SoD (segregation of duties): pembuat tidak boleh menjadi penyetuju untuk objek yang sama; tangani juga skenario delegasi.
- Step-up authentication: untuk persetujuan berisiko tinggi (misalnya pembayaran besar), pertimbangkan MFA atau re-auth.
- Least privilege pada integrasi: service account untuk integrasi (ERP, HRIS, ticketing) memiliki scope minimal dan rotasi kredensial.
- Access review berkala: laporan siapa bisa menyetujui apa dibanding struktur organisasi aktual; offboarding harus menutup akses dan sesi.
Contoh nyata: seorang manajer pindah unit tetapi role approver lamanya masih aktif karena sinkronisasi HRIS terlambat. Audit trail seharusnya menunjukkan role yang dipakai saat approval dan kapan role itu diberikan, sehingga Anda bisa menilai apakah approval sah menurut kebijakan saat itu.
Untuk perspektif implementasi, Anda bisa melihat contoh perbaikan alur persetujuan dan dampaknya pada waktu proses di studi kasus workflow internal, lalu menurunkannya menjadi kontrol yang bisa diaudit.
4) Retensi, privasi, dan kesiapan audit di Indonesia
Setelah pencatatan dan kontrol akses, pastikan log disimpan sesuai kebutuhan audit dan tidak melanggar prinsip privasi. Di Indonesia, kepatuhan sering bersinggungan dengan kebutuhan internal audit, persyaratan sektor (misalnya keuangan), dan tata kelola data pribadi berdasarkan UU PDP.
Langkah teknis yang umumnya aman dan praktis antara lain:
- Kebijakan retensi tertulis: tentukan durasi simpan per tipe event (approval, config change, access log) dan alasan bisnisnya.
- Data minimization: hindari menyimpan data sensitif berlebihan di log (misalnya nomor rekening lengkap); gunakan masking atau tokenisasi.
- Encryption: enkripsi in transit dan at rest; kunci dikelola dengan kontrol akses ketat dan audit untuk key usage.
- eDiscovery internal: prosedur pencarian bukti yang repeatable, termasuk siapa yang berwenang mengekspor log dan bagaimana hasilnya disimpan.
- Uji pemulihan: pastikan log tetap tersedia saat incident; uji restore dan verifikasi integritas secara berkala.
Dalam audit, yang dicari biasanya bukan hanya log mentah, melainkan kemampuan menjawab pertanyaan cepat: siapa menyetujui apa, di jalur mana, dengan kebijakan apa, dan apakah ada perubahan setelahnya. Menyiapkan dashboard ringkas untuk approval berisiko tinggi (misalnya nominal besar, vendor baru, atau bypass) sering mempercepat audit tanpa membuka akses log terlalu luas.
Jika checklist ini dipakai sebagai baseline, Anda akan lebih mudah menutup celah manipulasi, memperjelas akuntabilitas, dan menyiapkan bukti yang konsisten saat audit.
Jika perlu, jadwalkan sesi singkat untuk menyamakan definisi event dan prioritas risiko lintas tim.
Ketahui aspek keamanan dan integrasi di Epruvo