Membangun Jejak Audit Siap DORA dengan Webhook Didit (ID)

Digital Operational Resilience Act (DORA) mengajukan pertanyaan yang sulit kepada entitas keuangan: dapatkah Anda membuktikan apa yang terjadi? Ketika pengawas menyelidiki insiden, ketika auditor menguji kontrol Anda, atau ketika pelanggan menyengketakan keputusan orientasi, Anda memerlukan catatan — lengkap, dengan stempel waktu, dan tahan manipulasi — dari setiap peristiwa dalam sistem Teknologi Informasi dan Komunikasi (TIK) Anda. Verifikasi identitas adalah salah satu sistem tersebut, dan itu menghasilkan persis peristiwa yang perlu Anda tangkap.

Posting ini bersifat praktis: bagaimana mengubah webhook verifikasi dan transaksi Didit menjadi jejak audit siap DORA, apa yang harus disimpan, dan bagaimana membuatnya tahan terhadap pengawasan. Ini mencakup contoh webhook yang telah dikerjakan yang dapat Anda bangun hari ini.

Poin-poin Penting

• DORA mengharapkan bukti — catatan yang andal tentang peristiwa TIK untuk respons insiden, pengujian ketahanan, dan tinjauan pengawasan.
• Didit memancarkan peristiwa webhook pada setiap perubahan status yang berarti: status.updated, data.updated, transaction.status.updated, dan business.status.updated.
• Setiap peristiwa adalah fakta diskrit berstempel waktu yang Anda tambahkan ke log yang tidak dapat diubah — blok bangunan jejak audit.
• Verifikasi tanda tangan setiap webhook, simpan payload mentah, dan jangan pernah mengubah catatan yang dicatat — hanya-tambah adalah aturannya.
• Kontrol Didit sendiri mendukung jejak: SOC 2 Tipe 1 (ATOM), ISO/IEC 27001:2022 (sertifikat nomor ES144068), dan iBeta Level 1 PAD — jaminan tingkat vendor untuk daftar pihak ketiga TIK Anda.
• Hasilnya memenuhi catatan apa-yang-terjadi yang diinginkan DORA dan pembuktian siapa-ini yang mendasari kontrol akses.

Apa yang disyaratkan oleh standar

DORA dibangun di atas lima pilar: manajemen risiko TIK, pelaporan insiden, pengujian ketahanan operasional digital, berbagi informasi, dan manajemen risiko pihak ketiga TIK. Jejak audit adalah jaringan penghubung di antara semuanya. Secara khusus, entitas keuangan perlu:

• Mendeteksi, mencatat, dan melaporkan insiden terkait TIK — yang mengandaikan catatan yang cukup terperinci untuk merekonstruksi apa yang terjadi.
• Menguji ketahanan, termasuk kemampuan untuk melacak transaksi dan peristiwa melalui sistem.
• Mengelola risiko pihak ketiga, termasuk catatan yang mengalir dari penyedia seperti vendor verifikasi identitas.
• Menyimpan catatan dalam bentuk yang dapat diminta dan diandalkan oleh pengawas.

Persyaratan implisit dari jejak audit yang dapat digunakan mengikuti dari ini: peristiwa harus lengkap (tidak ada celah senyap), akurat (sesuai dengan apa yang terjadi), berurutan waktu (dengan stempel waktu yang andal), dapat diatribusikan (terkait dengan subjek dan aktor), dan tahan manipulasi (Anda dapat menunjukkan bahwa catatan tidak diubah setelah fakta).

Mengapa itu penting

Ketika suatu insiden terjadi — dugaan pengambilalihan akun, verifikasi yang disengketakan, transaksi yang ditandai — perbedaan antara peristiwa yang terkendali dan masalah regulasi seringkali adalah kualitas catatan Anda. Jejak yang lengkap memungkinkan Anda merekonstruksi urutan, membuktikan kontrol Anda berfungsi sebagaimana mestinya, dan menunjukkan kepada pengawas bahwa Anda menanganinya dengan benar. Jejak yang tidak lengkap membuat Anda menebak-nebak, dan membuat pengawas tidak yakin.

Peristiwa identitas sangat bernilai di sini karena berada di batas sistem: saat seseorang diverifikasi, diverifikasi ulang, atau statusnya berubah adalah saat yang paling Anda inginkan untuk dicatat. Menangkap peristiwa tersebut saat terjadi — daripada merekonstruksinya nanti dari log aplikasi — adalah apa yang mengubah "kami pikir ini yang terjadi" menjadi "ini yang terjadi."

Bagaimana Didit membantu

Didit memancarkan webhook untuk setiap transisi status dalam sesi verifikasi, transaksi, atau bisnis. Anda tidak melakukan polling; Anda menerima peristiwa yang ditandatangani saat sesuatu berubah.

Peristiwa	Terjadi saat	Nilai Audit
status.updated	Sesi verifikasi berubah status (misalnya menjadi Approved, Declined, In Review)	Mencatat keputusan dan waktunya
data.updated	Data terverifikasi pada sesi berubah	Mencatat apa yang ditangkap/berubah
transaction.status.updated	Status transaksi yang dipantau berubah	Mencatat keputusan pemantauan dan resolusi analis
business.status.updated	Status entitas bisnis KYB berubah (ACTIVE/FLAGGED/BLOCKED)	Mencatat hasil orientasi bisnis

Setiap peristiwa adalah fakta yang mandiri. Tugas Anda adalah memverifikasinya, menyimpannya mentah, dan tidak pernah mengubahnya. Bersama-sama, peristiwa-peristiwa tersebut membentuk buku besar hanya-tambah dari semua yang Didit lakukan atas nama Anda — jejak audit yang diinginkan DORA untuk bagian verifikasi identitas dari aset TIK Anda.

Dan karena Didit sendiri telah diakui — SOC 2 Tipe 1 (ATOM, per 09-04-2026), ISO/IEC 27001:2022 (Bureau Veritas, sertifikat nomor ES144068, berlaku hingga 03-06-2027), dan iBeta Level 1 PAD — penyedia di balik peristiwa-peristiwa tersebut membawa bukti sendiri untuk daftar pihak ketiga TIK DORA Anda.

Pembahasan mendalam: mengubah webhook menjadi catatan audit

Berikut adalah webhook status.updated untuk sesi verifikasi yang baru saja diselesaikan menjadi Approved:

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

Untuk mengubahnya menjadi catatan audit siap DORA, lakukan empat hal saat diterima:

1. Verifikasi tanda tangan. Hitung ulang HMAC pada badan permintaan mentah menggunakan rahasia penandatanganan titik akhir Anda dan bandingkan dengan header signature sebelum Anda memercayai payload. Tolak apa pun yang gagal — peristiwa yang tidak diverifikasi tidak memiliki nilai bukti.
2. Simpan payload mentah secara verbatim. Pertahankan byte persis yang Anda terima, bersama dengan stempel waktu penyerapan Anda sendiri. Jangan normalisasi atau membentuk ulang sebelum penyimpanan; peristiwa mentah adalah buktinya.
3. Tambahkan, jangan pernah perbarui. Tulis ke penyimpanan hanya-tambah (atau tabel tanpa izin UPDATE/DELETE untuk peran aplikasi). Jika peristiwa selanjutnya menggantikan peristiwa sebelumnya, tulis baris baru yang mereferensikan session_id lama — jangan pernah menimpa.
4. Buat itu tahan manipulasi. Hash setiap catatan dan rantai hash ke yang berikutnya (setiap baris menyimpan hash baris sebelumnya), atau tulis ke penyimpanan sekali-tulis. Sekarang Anda dapat membuktikan log tidak diubah setelah fakta.

Hasilnya adalah buku besar kronologis, dapat diatribusikan, dan tahan manipulasi: untuk setiap session_id Anda dapat memutar ulang setiap perubahan status, melihat pemeriksaan mana yang lulus, dan menunjukkan dengan tepat kapan keputusan dibuat — dan membuktikan catatan belum disentuh sejak itu. Itulah standar yang dicari oleh pengawas atau auditor, dan itu adalah pola yang sama yang akan Anda terapkan pada transaction.status.updated untuk keputusan pemantauan dan business.status.updated untuk hasil KYB.

Kasus penggunaan

• Bank dan EMI membangun log peristiwa TIK yang selaras dengan DORA yang mencakup keputusan identitas.
• VASP Kripto yang harus membuktikan keputusan orientasi dan pemantauan transaksi kepada pengawas.
• Tim kepatuhan yang bersiap untuk pengujian ketahanan yang melacak peristiwa ujung-ke-ujung.
• Tim rekayasa mengganti polling yang rapuh dengan penyerapan peristiwa yang ditandatangani dan hanya-tambah.

Pertanyaan yang sering diajukan

Peristiwa webhook mana yang harus saya tangkap untuk jejak audit?

Minimal status.updated dan data.updated untuk verifikasi; tambahkan transaction.status.updated untuk pemantauan transaksi dan business.status.updated untuk KYB. Tangkap setiap peristiwa — kelengkapan adalah intinya.

Apakah saya perlu memverifikasi tanda tangan webhook?

Ya. Webhook yang tidak diverifikasi dapat dipalsukan dan tidak memiliki bobot bukti. Hitung ulang tanda tangan pada badan mentah dan tolak ketidaksesuaian sebelum mencatat.

Mengapa hanya-tambah? Tidakkah saya bisa memperbarui catatan saat status berubah?

DORA menghargai bukti tahan manipulasi. Jika Anda menimpa catatan, Anda tidak dapat membuktikan bahwa riwayat tidak diubah. Menambahkan peristiwa baru untuk setiap perubahan mempertahankan urutan yang lengkap dan dapat dibuktikan.

Apakah menangkap peristiwa Didit memenuhi semua DORA?

Tidak — DORA luas. Peristiwa Didit mencakup bagian verifikasi identitas dan pemantauan dari aset TIK Anda. Anda akan menggabungkannya dengan log dari sistem Anda yang lain untuk jejak yang lengkap.

Apakah Didit memiliki pengesahan sendiri untuk daftar pihak ketiga DORA?

Ya — SOC 2 Tipe 1 (ATOM), ISO/IEC 27001:2022 (sertifikat nomor ES144068, berlaku hingga 03-06-2027), dan iBeta Level 1 PAD, semuanya tersedia untuk mendukung uji tuntas vendor Anda.

Siap untuk memulai?

Lihat pengesahan Didit di pusat kepercayaan, baca detail integrasi webhook di dokumen, dan tinjau harga transparan di halaman harga. Ketika Anda siap, mulai gratis — 500 pemeriksaan KYC gratis setiap bulan, dengan alur verifikasi inti mulai dari $0.33.