Kebanyakan organisasi gagal merespons kebocoran data bukan karena tidak punya rencana. Mereka gagal karena hitungan waktunya sudah berjalan berminggu-minggu sebelum ada yang menyadarinya.
Sebagian besar tenggat notifikasi mulai berjalan sejak Anda mengetahui adanya kebocoran. Satu kata itu, “mengetahui”, menentukan semua langkah sesudahnya. Organisasi yang mendeteksi penyusupan dalam satu jam punya tiga hari untuk menilai, mengisolasi, dan melapor. Organisasi yang baru mendeteksinya setelah sembilan puluh hari tetap hanya punya tiga hari yang sama. Bedanya, kerusakan sudah terjadi, datanya sudah hilang, dan regulator akan bertanya mengapa butuh waktu selama itu untuk mengetahuinya.
Panduan ini membahas apa yang perlu dilakukan sejak jam pertama hingga 72 jam, serta apa yang diwajibkan hukum di Indonesia, Singapura, Malaysia, Vietnam, dan Eropa. Panduan ini juga menunjukkan di tahap mana sebagian besar upaya respons gagal.
Apa itu respons kebocoran data perusahaan?
Respons kebocoran data adalah rangkaian langkah yang diambil organisasi sejak mengetahui data pribadi telah bocor. Langkahnya: isolasi insiden, cek data apa saja yang terpapar, beri tahu orang dan regulator yang perlu tahu, lalu perbaiki penyebabnya.
Dua hitungan waktu berjalan sekaligus, dan keduanya tidak sama.
Yang pertama soal teknis. Seberapa cepat Anda bisa mengisolasi sistem yang terdampak, mengamankan barang bukti, dan menutup titik masuknya? Hitungan ini diukur dalam menit dan jam, serta ditentukan oleh pemantauan dan playbook Anda.
Yang kedua soal hukum. Berapa lama sampai Anda wajib melapor ke regulator, dan kapan hitungan mundurnya dimulai? Hitungan ini diukur dalam hari dan ditentukan oleh undang-undang.
Menurut IBM Cost of a Data Breach Report 2026, organisasi butuh rata-rata 247 hari untuk mengidentifikasi dan mengisolasi kebocoran. Sebagian besar aturan notifikasi di artikel ini memberi Anda tiga hari. Selisih antara kedua angka itulah inti masalahnya.
Respons kebocoran data vs penanganan insiden
Respons kebocoran data adalah bagian dari penanganan insiden. Setiap kebocoran data adalah insiden. Namun, sebagian besar insiden bukan kebocoran data.
Respons kebocoran data | Penanganan insiden | |
Pemicu | Data pribadi telah bocor | Peristiwa keamanan apa pun: lonjakan login gagal, deteksi malware, server yang salah konfigurasi, percobaan phishing |
Kewajiban hukum | Kewajiban menurut undang-undang langsung berlaku | Hanya pada kasus tertentu (di Indonesia: serangan yang berdampak serius pada sistem, serta insiden di bank, penyedia jasa pembayaran, dan Infrastruktur Informasi Vital) |
Siapa yang terlibat | Tim keamanan, legal, komunikasi, DPO, dan regulator | Tim keamanan |
Tenggat | Biasanya 72 jam, ditetapkan undang-undang | SLA internal, atau tenggat sektoral (1 sampai 24 jam di Indonesia) |
Pekerjaan forensik | Sama | Sama |
Akibat jika salah langkah | Sanksi regulator, pemberitahuan ke publik, tindakan penegakan hukum | Operasional |
Respons kebocoran data jam demi jam
Empat fase di bawah ini mengikuti jalannya insiden sungguhan dan tenggat yang sedang Anda kejar. Pembagian waktunya bukan asal-asalan. Itulah sisa waktu yang diberikan aturan 72 jam kepada Anda.
Jam 0 sampai 1: isolasi dan barang bukti
Isolasi sistem yang terdampak dari jaringan. Jangan matikan sistemnya.
Instruksi kedua ini sering sekali diabaikan, dan itu merusak investigasi. Memori volatil menyimpan proses yang sedang berjalan, koneksi aktif, dan malware yang tak pernah tersimpan ke disk. Begitu listriknya dicabut, semua itu hilang. Sebaliknya, putuskan koneksinya di switch: perangkat tetap menyala, akses penyerang terputus.
Amankan log sebelum ada proses lain yang menyentuhnya. Rotasi log tidak berhenti hanya karena ada insiden. Dengan masa retensi 30 hari, bukti penyusupan yang dimulai 45 hari lalu akan tertimpa.
Lalu ganti kredensial. Menghapus tool penyerang tidak sama dengan mencabut aksesnya. Ganti kredensial service account, API key, dan privileged access (PAM), lalu cek akun yang dibuat selama masa penyusupan.
Terakhir, cek vendor Anda. Panduan Federal Trade Commission AS tegas soal ini: kalau kontraktor punya akses jaringan, cek apa yang masih bisa dijangkaunya sebelum menganggap perimeter sudah tertutup.
Jam 1 sampai 24: investigasi dan penilaian cakupan
Buat image forensik sebelum remediasi dimulai. Begitu server dibangun ulang, kondisinya saat dibobol ikut hilang.
Lalu jawab pertanyaan yang penting di mata hukum. Bukan data apa yang dicuri, melainkan data apa yang bisa dijangkau penyerang. Di sebagian besar aturan, pemicunya adalah akses tanpa izin, bukan pencurian yang terbukti. Kalau penyerang memegang kredensial administrator database pelanggan selama enam hari, tidak adanya bukti penyalinan bukan berarti data tidak disalin.
Di suatu titik dalam rentang waktu ini, dugaan berubah menjadi kepastian. Anda beralih dari “sepertinya ada yang tidak beres” ke “data pribadi telah bocor.” Di sebagian besar negara, saat itulah hitungan waktu hukum dimulai. Jadi, momen itu perlu punya timestamp, nama pengambil keputusan, dan catatan tertulis. Kalau regulator bertanya kapan Anda mengetahuinya, jawabannya harus berupa dokumen.
Jam 24 sampai 72: notifikasi
Bandingkan kebocoran itu dengan ambang batas yang berlaku bagi Anda, lalu laporkan. Laporan ke regulator biasanya memuat jenis kebocoran, kategori dan volume data terdampak, jumlah orang terdampak, langkah remediasi yang sudah diambil, dan nama narahubung.
Lebih baik melapor dengan informasi yang belum lengkap daripada terlambat. Kebanyakan tim engineering enggan melakukannya karena ingin melihat gambaran lengkap dulu sebelum melapor. Sebagian besar aturan di artikel ini menerima laporan awal, lalu laporan tambahan menyusul. Terlambat berarti sanksi. Laporan parsial yang ditindaklanjuti jarang dikenai sanksi.
Memberi tahu individu adalah pekerjaan lain: masalah komunikasi dengan tenggat hukum. Karena itu, template pemberitahuannya harus sudah siap sebelum insiden terjadi. Orang butuh empat hal: kronologi kejadian, data mereka yang terdampak, langkah Anda saat ini, dan tindakan yang perlu mereka ambil sekarang. Tunjuk satu juru bicara dan terbitkan satu halaman sebagai acuan tunggal.
Hari 3 sampai 30: remediasi dan pemulihan
Tutup akar masalahnya, bukan gejalanya. Kalau titik masuknya kredensial yang dicuri, mem-patch server tidak menyelesaikan apa pun. Setelah itu, uji apakah perbaikannya bertahan, misalnya dengan pentest pada titik masuk yang sama.
Pulihkan dari titik yang bersih. Titik pemulihan harus berada sebelum akses awal penyerang, bukan sebelum kerusakan pertama terlihat. Dalam kasus ransomware, kedua tanggal itu sering berselisih berminggu-minggu. Kalau Anda memulihkan ke hari sebelum enkripsi berjalan, pijakan (foothold) penyerang biasanya ikut pulih bersama file-file Anda.
Lalu jalankan tinjauan pascainsiden dan tuliskan hasilnya. Dokumen inilah yang diminta regulator. Dokumen ini juga bukti bahwa organisasi Anda memahami apa yang terjadi dan sudah berbenah karenanya.
Kewajiban notifikasi kebocoran data
Sebagian besar undang-undang pelindungan data memberi organisasi waktu 72 jam sejak mengetahui adanya kebocoran untuk memberi tahu regulator.
Uni Eropa menjadikannya patokan saat GDPR mulai berlaku pada 2018 (Pasal 33). Indonesia, Malaysia, Filipina, Thailand, dan Vietnam semuanya memakai angka yang sama. Tenggatnya sudah seragam. Aturan di baliknya belum.
Siapa lagi yang wajib diberi tahu
- GDPR: individu, hanya jika kebocoran menimbulkan risiko tinggi bagi mereka
- Indonesia: regulator dan pemilik data yang terdampak, tanpa ambang risiko, serta masyarakat dalam hal tertentu, misalnya jika pelayanan publik terganggu atau kepentingan masyarakat terdampak serius
- Malaysia: regulator lebih dulu, lalu individu dalam tujuh hari berikutnya jika besar kemungkinan timbul kerugian signifikan
- Vietnam: regulator dan individu sekaligus, dalam 72 jam yang sama, untuk jenis data tertentu
Tenggat pelaporan kebocoran data
Yurisdiksi | Regulator | Tenggat ke regulator | Hitungan dimulai | Pemberitahuan ke individu |
Indonesia | Lembaga PDP (belum dibentuk; sementara ini Komdigi yang mengawasi) | 3 x 24 jam | Saat kegagalan Pelindungan Data Pribadi diketahui (mulai 16 Januari 2027: saat diketahui secara pasti, patut, dan wajar, menurut PP 33/2026) | Ya, dalam 3 x 24 jam yang sama, tanpa ambang risiko |
Singapura | PDPC | 3 hari kalender setelah penilaian selesai | Saat penilaian selesai (seharusnya dalam 30 hari) | Jika besar kemungkinan timbul kerugian signifikan |
Malaysia | Personal Data Protection Commissioner | 72 jam | Saat kebocoran terjadi (contoh dalam pedoman itu sendiri menghitung sejak kebocoran diketahui) | Dalam 7 hari setelah memberi tahu Komisioner, jika besar kemungkinan timbul kerugian signifikan |
Vietnam | MPS A05 | 72 jam | Deteksi | 72 jam yang sama, untuk data keuangan, perbankan, biometrik, dan lokasi |
Uni Eropa / Inggris | Otoritas pengawas utama / ICO | 72 jam | Saat kebocoran diketahui | Tanpa penundaan yang tidak semestinya, jika berisiko tinggi |
Filipina | NPC | 72 jam | Saat mengetahui, atau secara wajar meyakini, terjadinya kebocoran | Jika ada risiko nyata kerugian serius, dalam 72 jam yang sama |
Thailand | PDPC | 72 jam (keterlambatan bisa diterima jika alasannya dijelaskan dalam 15 hari) | Saat kebocoran diketahui | Jika berisiko tinggi terhadap hak dan kebebasan individu |
Australia | OAIC | Penilaian dalam 30 hari | Saat mengetahui ada dasar yang wajar untuk menduga terjadi kebocoran | Jika besar kemungkinan timbul kerugian serius |
Amerika Serikat | Regulator negara bagian; CISA untuk infrastruktur kritis (CIRCIA, setelah mulai berlaku) | Tidak ada tenggat federal yang berlaku umum; CIRCIA akan mewajibkan 72 jam untuk infrastruktur kritis setelah aturan finalnya berlaku | Berbeda-beda | Berbeda di tiap negara bagian |
Sumber: Pasal 46 UU PDP (Indonesia), PDPC Singapura, Department of Personal Data Protection Malaysia, Dekret Vietnam 356/2025/ND-CP, Pasal 33 GDPR, ICO, OAIC.
Aturan pelaksana UU PDP, yaitu Peraturan Pemerintah (PP) No. 33 Tahun 2026, berlaku mulai 16 Januari 2027. PP ini mempertahankan tenggat 3 x 24 jam (72 jam). Hitungannya dimulai sejak kegagalan Pelindungan Data Pribadi diketahui secara pasti, patut, dan wajar. PP ini juga mewajibkan pemberitahuan memuat detail Pejabat atau Petugas Pelindungan Data Pribadi (PPDP) Anda, yang dikenal sebagai DPO, atau narahubung yang ditunjuk.
Beberapa sektor di Indonesia juga punya tenggat lebih pendek untuk insiden siber, baik melibatkan data pribadi maupun tidak. Bank umum mengirim notifikasi awal ke OJK paling lama 24 jam setelah mengetahui insiden (SEOJK 29/2022). Penyedia jasa pembayaran dan perusahaan lain yang diatur Bank Indonesia mengirim notifikasi awal ke BI paling lama 1 jam setelah mengetahuinya (PBI 2/2024). Penyelenggara Infrastruktur Informasi Vital (IIV) melapor ke CSIRT (Tim Tanggap Insiden Siber) sektornya, dengan tembusan ke CSIRT nasional di BSSN. Batasnya 1 x 24 jam setelah insiden ditemukan (Perpres 82/2022). Di luar sektor-sektor itu, PP 71/2019 tetap mewajibkan setiap Penyelenggara Sistem Elektronik melaporkan serangan yang berdampak serius pada sistemnya. Laporan itu wajib disampaikan dalam kesempatan pertama kepada aparat penegak hukum serta kementerian atau lembaga terkait.
Kesalahan umum dalam merespons kebocoran data
Sebagian besar kegagalan di bawah ini bukan masalah teknis, melainkan keputusan yang diambil saat situasi genting oleh orang yang ingin berbuat benar. Pada saat itu, setiap keputusan masih bisa dipertanggungjawabkan. Keputusan itu baru terlihat salah belakangan, di berkas regulator.
1. Mematikan perangkat yang sudah dibobol
Nalurinya: hentikan kerusakan secepatnya. Akibatnya, bukti di memori ikut hancur, padahal bukti itulah yang menunjukkan apa yang dilakukan penyerang dan seberapa jauh jangkauannya. Sebaliknya, putuskan koneksi jaringannya dan biarkan perangkat tetap menyala.
2. Menunda penilaian agar hitungan waktu belum dimulai
Memperpanjang penilaian, atau menjalankan investigasi santai yang tak pernah secara formal disebut kebocoran, terlihat seperti cara mengulur waktu. Apa pun caranya, kesalahannya sama. Regulator mengharapkan penilaian dimulai secepatnya. Menangani insiden sederhana dengan lamban justru mengundang sorotan yang sedang Anda hindari.
3. Menganggap tak ada bukti pencurian berarti tak ada kebocoran
Di sebagian besar aturan, pemicu notifikasi adalah akses tanpa izin, bukan eksfiltrasi data yang sudah terkonfirmasi. Kalau penyerang bisa menjangkau data, kewajiban Anda sudah berlaku. Tidak adanya bukti pengambilan data bukan bukti bahwa data itu tidak diambil.
4. Memulihkan dari backup yang sudah disusupi
Titik pemulihan harus berada sebelum akses awal, bukan sebelum kerusakan pertama terlihat. Dalam kasus ransomware, kedua tanggal itu sering berselisih berminggu-minggu. Kalau Anda memulihkan ke hari sebelum enkripsi berjalan, biasanya pijakan penyerang ikut pulih bersama file-file Anda.
5. Memberi tahu tanpa juru bicara yang ditunjuk
Kalau beberapa orang berbicara kepada pelanggan, media, dan regulator, akan muncul versi yang sedikit berbeda tentang insiden yang sama. Perbedaan itu terbaca sebagai kontradiksi, dan kontradiksi itulah yang diingat regulator.
6. Mengira tenggat adalah kendala utamanya
Tenggatnya tetap. Waktu deteksi Anda tidak. Organisasi yang melewatkan tenggat notifikasi hampir tidak pernah gagal karena urusan administrasinya lambat.
Contoh kasus kebocoran data dan responsnya
PDNS 2 (2024)
Pusat Data Nasional Sementara Indonesia dibobol kelompok ransomware Brain Cipher. Lebih dari 200 instansi pemerintah kehilangan akses ke layanan, sistem imigrasi di bandara lumpuh, dan penyerang meminta tebusan USD 8 juta. Kepala BSSN, lembaga siber nasional Indonesia, kemudian menyampaikan kepada DPR bahwa hanya 2% data di pusat data itu yang punya backup.
Insiden ini contoh paling jelas di Indonesia untuk argumen artikel ini: kegagalannya bukan pada respons, melainkan pada semua yang seharusnya sudah siap sebelumnya. Deteksi, segmentasi, dan backup yang bisa dipulihkan bukan langkah respons. Semuanya prasyarat agar respons bisa berjalan.
SingHealth (2018)
Penyerang mengakses catatan data pribadi nonmedis milik sekitar 1.5 juta pasien, termasuk Perdana Menteri. Committee of Inquiry yang dibentuk setelahnya menemukan bahwa staf sebenarnya sudah melihat aktivitas mencurigakan, tetapi eskalasinya lambat dan tidak tuntas.
PDPC Singapura menjatuhkan denda gabungan SGD 1 juta kepada SingHealth dan IHiS. Temuan yang penting justru bukan soal teknis. Orang yang melihat tanda bahayanya tidak punya jalur untuk bertindak cukup cepat.
Kedua insiden punya pola yang sama. Organisasinya tidak tumbang karena kecanggihan serangan. Mereka tumbang karena jeda antara saat dibobol dan saat mereka memahami apa yang terjadi.
Kecepatan deteksi menentukan waktu respons
Sebagian besar tenggat di artikel ini mulai berjalan saat kebocoran diketahui. Justru bagian inilah yang paling bisa dikendalikan organisasi, tetapi paling jarang dipikirkan.
Laporan IBM 2026 mencatat rata-rata waktu untuk mengidentifikasi dan mengisolasi kebocoran mencapai 247 hari. Pedoman Malaysia merumuskan tenggatnya sebagai 72 jam sejak kebocoran terjadi. Jika dibaca harfiah, waktu deteksi langsung memotong jatah waktu Anda. Organisasi yang butuh berbulan-bulan untuk mendeteksi sudah lewat tenggat berbulan-bulan sebelum tahu ada masalah.
Kendalanya bukan seberapa cepat Anda bisa melapor. Kendalanya adalah seberapa cepat Anda bisa mengetahuinya.
Ini mengubah arti kesiapan menghadapi kebocoran. Kesiapan bukan dokumen di dalam laci, melainkan jawaban atas pertanyaan berikut. Apakah log Anda tersimpan cukup lama untuk merekonstruksi penyusupan yang dimulai enam minggu lalu? Apakah pemantauan Anda mencakup sistem tempat data pribadi benar-benar disimpan? Apakah alert pukul 3 pagi pada hari Minggu sampai ke orang yang bisa menindaklanjutinya?
Semua itu pertanyaan engineering. Jawabannya harus ada sebelum insiden, atau tidak akan pernah ada.
Managed SOC Zentara hadir dengan pemantauan terus-menerus dan SLA respons 15 menit untuk alert kritis. Deteksi ancamannya disetel khusus untuk sistem penyimpan data Anda yang diatur regulator. Tujuannya memangkas jarak antara saat sistem dibobol dan saat Anda mengetahuinya. Jadi, saat hitungan waktu dimulai, Anda masih punya 72 jam penuh.
Kalau hitungan waktunya sudah berjalan, tim penanganan insiden Zentara bisa membantu Anda mengisolasi kebocoran dan mengamankan barang bukti.
Diskusikan cakupan deteksi Anda dengan tim kami.
Pertanyaan yang sering diajukan
1. Apa langkah pertama untuk mengatasi kebocoran data?
Isolasi sistem yang terdampak tanpa mematikannya karena memori volatil adalah barang bukti. Amankan log sebelum mengganti kredensial. Setelah itu, mulai penilaian cakupan untuk menentukan data mana saja yang bisa dijangkau penyerang.
2. Berapa lama batas waktu untuk melaporkan kebocoran data?
Sebagian besar aturan memberi waktu 72 jam, biasanya sejak kebocoran diketahui. Contohnya GDPR serta aturan di Indonesia, Malaysia, Thailand, dan Vietnam. Australia memberi 30 hari untuk penilaian, sedangkan Amerika Serikat tidak punya tenggat tunggal di tingkat federal. Di Indonesia, bank dan penyedia jasa pembayaran juga punya tenggat insiden siber yang lebih pendek. Bank mengirim notifikasi awal ke OJK paling lama 24 jam, dan penyedia jasa pembayaran ke Bank Indonesia paling lama 1 jam.
3. Kapan hitungan 72 jam dimulai?
Menurut GDPR serta aturan Indonesia, Thailand, dan Vietnam, hitungannya dimulai sejak kebocoran diketahui atau terdeteksi. Di Indonesia, mulai 16 Januari 2027, PP 33/2026 menghitungnya sejak kebocoran diketahui secara pasti, patut, dan wajar. Di Singapura, hitungannya dimulai saat penilaian selesai dan menyimpulkan kebocoran wajib dilaporkan. Namun, penilaian itu sendiri harus segera dilakukan.
4. Siapa yang harus diberi tahu jika terjadi kebocoran data di Indonesia?
UU PDP mewajibkan Anda memberi tahu pemilik data yang terdampak (Subjek Data Pribadi) dan lembaga PDP. Lembaga ini belum dibentuk. Sampai lembaga itu terbentuk, Komdigi mengawasi pelindungan data pribadi melalui Direktorat Jenderal Pengawasan Ruang Digital. Belum ada regulasi yang menetapkan saluran untuk notifikasi kebocoran data. Jadi, konfirmasikan salurannya ke Komdigi sebelum Anda melapor. Aturan sektoral juga mewajibkan laporan tersendiri. Bank umum mengirim notifikasi awal ke OJK paling lama 24 jam. Penyedia jasa pembayaran mengirimnya ke Bank Indonesia paling lama 1 jam. Penyelenggara Infrastruktur Informasi Vital (IIV) melapor ke CSIRT sektornya, dengan tembusan ke CSIRT nasional di BSSN, paling lambat 1 x 24 jam setelah insiden ditemukan.
5. Bagaimana jika fakta belum lengkap dalam 72 jam?
Laporkan berdasarkan informasi yang ada. Sebagian besar regulator menerima notifikasi awal yang disusul laporan tambahan. Laporan yang terlambat biasanya disikapi lebih keras daripada laporan yang belum lengkap.
6. Apakah kebocoran yang sudah diisolasi tetap wajib dilaporkan?
Tergantung aturannya. Singapura, Malaysia, dan GDPR mengaitkan kewajiban notifikasi dengan ambang kerugian atau risiko. Jadi, remediasi yang efektif bisa menghapus kewajiban memberi tahu individu. Kebocoran besar tetap harus dilaporkan ke regulator di Singapura (500 orang atau lebih) dan Malaysia (lebih dari seribu orang). Pasal 46 UU PDP di Indonesia tidak punya ambang risiko yang tegas. Karena itu, tetap kirim notifikasi dan dokumentasikan alasan Anda dalam kondisi apa pun.
