Komunikasi insiden: pesan untuk pimpinan, pengguna dan pihak terkait

Siapa perlu mengetahui apa?

Tentukan penerima, pemilik pesan dan tujuan komunikasi sejak awal. Tim teknis memerlukan rincian untuk bertindak; pengguna memerlukan dampak dan petunjuk yang dapat dipahami. Menyalin satu pesan lengkap ke semua kanal dapat menyebarkan informasi yang tidak perlu.

Komunikasi membantu koordinasi dan keputusan. Ia tidak menggantikan pembatasan dampak, pemeriksaan bukti atau penilaian hukum. Gunakan rencana komunikasi insiden bersama koordinator dan penanggung jawab privasi/hukum yang sesuai.

Pisahkan tujuan pesan

Tujuan / penerima	Informasi yang diperlukan
Koordinasi teknis / petugas berwenang	ID kejadian, fakta teknis, tindakan, bukti terbatas dan pemilik pekerjaan.
Keputusan / pimpinan	Dampak yang diketahui, ketidakpastian, pilihan tindakan, kebutuhan sumber daya dan keputusan yang diminta.
Bantuan / pengguna atau mitra	Dampak pada mereka, langkah yang benar-benar diperlukan, kanal bantuan dan pembaruan berikutnya.
Kewajiban / penerima sesuai aturan atau kontrak	Pemicu, penerima, isi, tenggat dan saluran yang telah dinilai untuk organisasi tersebut.
Pesan publik / masyarakat atau media	Fakta yang dapat dipublikasikan, status layanan dan pembaruan; hindari bukti sensitif atau rincian yang membantu penyalahgunaan.

Tidak setiap peringatan perlu diumumkan sebagai kebocoran, tetapi ketidakpastian teknis juga bukan alasan menunda penilaian kewajiban. Jalankan keduanya bersama dan catat statusnya.

Pilih penulis, penyetuju dan kanal pengganti

Tetapkan koordinator yang menerima fakta dari petugas, penulis pesan, pemeriksa dampak/privasi, penyetuju sesuai kewenangan, serta pengganti bila mereka tidak tersedia. Batas persetujuan perlu jelas; jangan membiarkan draft berhenti di antrean tanpa pemilik.

Siapkan kanal yang masih dipercaya jika email atau akun admin utama bermasalah. Verifikasi kontak penerima melalui cara yang disepakati. Jangan mengirim bukti melalui akun yang sedang dicurigai atau membagikan lampiran pelanggan ke grup umum.

Tulis fakta, ketidakpastian dan tindakan nyata

Gunakan versi dan waktu pada setiap pesan. Sebutkan yang telah dikonfirmasi, apa yang masih diperiksa, dampak yang diketahui, tindakan yang telah dilakukan dan kapan pembaruan berikutnya diberikan. Jika belum ada jawaban, katakan bagian mana yang belum diketahui.

Hindari “semua aman”, “tidak ada kebocoran” atau “masalah selesai” tanpa dasar dan cakupan pemeriksaan. Penggantian kata sandi atau layanan yang kembali hidup belum membuktikan seluruh akses/data telah diperiksa. Jangan menebak pelaku.

Contoh draft dari log buatan

Contoh berikut memakai lab analisis insiden 1.0, bukan kejadian nyata. Analisis log mencatat EXP-A dengan artefak dan respons 200, sementara penyelesaian EXP-B belum diketahui. Isi artefak, identitas manusia dan riwayat jalur lain belum diperiksa.

Ringkasan internal buatan:

INS-LOG-DEMO-01, versi 1. Log memuat respons unduhan EXP-A dan awal pekerjaan EXP-B. Isi berkas, identitas manusia serta cakupan jalur lain belum dipastikan. Koordinator perlu menetapkan pemeriksaan tambahan dan penanggung jawab penilaian pemberitahuan. Target pembaruan contoh: 2 Oktober 2026, 09.00 WIB.

Draft pengguna buatan:

Kami sedang memeriksa laporan aktivitas ekspor pada layanan contoh. Dampak terhadap data masih diperiksa. Pembaruan berikutnya pada 2 Oktober 2026, 09.00 WIB, melalui kanal yang telah diverifikasi.

Kedua teks ini draft latihan yang belum disetujui atau dikirim. Jadwal tersebut target contoh, bukan tenggat hukum. Tambahkan dampak/petunjuk yang relevan setelah tersedia; jangan menyalin teks pendek ini sebagai pemberitahuan wajib yang dianggap lengkap.

Runner Node 24.21.0 dijalankan 2 Oktober 2026. Tiga pemeriksaan komunikasi hanya memeriksa field model: draft belum siap, status approved dengan nama peran memenuhi field, dan waktu pembaruan tidak valid ditolak. Script mengisi peran buatan; ia tidak memverifikasi kewenangan manusia, fakta pesan atau kepatuhan, dan tidak mengirim pesan/email. Jangan memakai validator contoh sebagai alur persetujuan produksi.

Nilai pemberitahuan wajib secara terpisah

Pasal 46 UU PDP mengatur pemberitahuan tertulis oleh pengendali dalam hal kegagalan pelindungan data pribadi. Ayat (2) menetapkan isi minimal mengenai data yang terungkap, kapan/bagaimana terungkap, serta upaya penanganan dan pemulihan. Ayat (3) mengatur pemberitahuan kepada masyarakat dalam hal tertentu.

Detail pemicu, penerima dan perbedaan tenggat tetap di panduan insiden data pribadi. Periksa kewajiban sektor dan kontrak yang berlaku; jangan memakai satu tenggat untuk seluruh pesan. Contoh buatan di atas belum menetapkan kewajiban hukum atau alamat regulator bagi organisasi nyata. Mulai penilaian saat diperlukan, jangan menunggu laporan penutupan.

Simpan bukti pengiriman dan koreksi

Catat versi yang disetujui, siapa menyetujui, penerima, kanal, waktu serta bukti pengiriman/penerimaan yang tersedia. Status “terkirim” pada satu kanal belum selalu membuktikan diterima. Simpan kegagalan, pengiriman ulang dan koreksi tanpa menghapus versi lama.

Sesudah pemulihan, perbarui status berdasarkan hasil yang telah diperiksa, pekerjaan tersisa dan kanal bantuan. Pengiriman pesan penutupan tidak menutup pemeriksaan teknis secara otomatis. Hubungkan catatan pesan dengan laporan insiden, bukan membuat kronologi kedua yang berbeda.