Fase 1: Persiapan (Preparation)
Respons insiden yang efektif dimulai jauh sebelum breach terjadi. Organisasi harus memiliki Incident Response Policy yang komprehensif, menetapkan tim IR yang jelas (dengan roles dan responsibilities), mengidentifikasi tools dan resources yang diperlukan, membangun contact lists (vendor, legal counsel, PR, forensics experts), dan menjalin retainer agreements dengan forensics firms dan legal counsel agar mereka dapat segera diaktifkan ketika diperlukan. Tim IR harus terdiri dari representasi dari IT security, IT operations, legal, DPO, communications/PR, dan executive sponsor (biasanya CRO atau CEO delegated). Tim harus melakukan training reguler dan simulasi tabletop exercises setidaknya sekali per tahun untuk menguji prosedur dan mengidentifikasi gap.
Persiapan juga harus mencakup dokumentasi infrastruktur kritis: data flow diagrams menunjukkan di mana data pribadi disimpan, diproses, dan ditransmisikan; inventory sistem dan aplikasi yang memproses data pribadi; backup dan disaster recovery information; contact information untuk cloud providers atau vendor lain yang mungkin perlu dihubungi. Informasi ini harus disimpan di tempat yang aman dan accessible oleh tim IR, tetapi tidak disimpan di sistem yang mudah dikompromikan selama breach.
Fase 2: Deteksi dan Analisis (Detection and Analysis)
Deteksi breach dapat berasal dari berbagai sumber: monitoring system otomatis (SIEM alerts, intrusion detection system alerts), report dari vendor/cloud provider, laporan dari karyawan, notifikasi dari pihak eksternal, atau even discovery selama audit keamanan rutin. Ketika indikasi potensi breach diterima, tim IR harus segera melakukan triage dan konfirmasi untuk menentukan apakah ini benar-benar breach atau false alarm.
Analisis awal harus mencakup:
(1) identifikasi sistem atau data yang terdampak;
(2) timetable kejadian (kapan penyerang pertama kali mendapatkan akses, kapan ditemukan, proses apa yang dilakukan);
(3) preliminary assessment tentang jumlah record yang mungkin terkompromi;
(4) preliminary assessment tentang sensitifitas data yang terdampak;
(5) penentuan severity level insiden berdasarkan defined criteria (critical/high/medium/low). Severity level menentukan escalation path dan resource allocation.
Untuk insiden yang bersifat critical (misalnya breach yang luas dari data sensitif atau customer PII), ir team harus immediately activate forensics investigation dengan external forensics firm. Forensics investigation adalah "destructive" dalam hal bahwa penyidik akan shutdown sistem terdampak untuk preserved evidence dalam forensically sound manner, yang berarti operasi bisnis mungkin akan terganggu. Keputusan untuk melakukan forensics investigation penuh harus dibuat oleh executive sponsor, biasanya dengan konsultasi dari legal counsel.
| PENTING | Preservation of evidence adalah kunci untuk investigasi keberhasilan dan untuk potential legal action (baik criminal investigation oleh police, maupun civil litigation). Organisasi harus menghindari upaya "cleanup" atau "remediation" sebelum forensics investigation complete, karena ini dapat menghapus bukti penting yang diperlukan untuk memahami scope dan cause dari breach. |
Fase 3: Containment (Containment)
Containment memiliki dua aspek: short-term containment (stop the bleeding) dan long-term containment (eradicate the threat). Short-term containment mencakup: isolasi sistem yang terdampak dari network jika memungkinkan tanpa menghentikan operasi bisnis kritis; menghenti akses penyerang (reset passwords, revoke tokens, block IP addresses); mencegah akses lebih lanjut dengan patching vulnerability yang digunakan untuk initial compromise. Long-term containment mencakup: penghapusan malware atau backdoor yang ditinggalkan penyerang; patching semua sistem terdampak; rebuild sistem dari clean backups jika diperlukan; implementation of monitoring controls yang lebih ketat untuk mendeteksi upaya re-compromise di masa depan.
Tantangan dalam containment adalah balancing antara security imperatives dan business continuity imperatives. Isolasi sistem dapat mengganggu operasi bisnis, tetapi kegagalan untuk isolasi dapat memperluas scope breach. Keputusan containment harus dibuat oleh tim IR dengan input dari business leaders, dan trade-off harus didokumentasikan.
Evidence preservation harus tetap menjadi prioritas selama containment. Jika sistem perlu diiso atau shutdown, log dan data yang relevan harus di-capture terlebih dahulu dan disimpan di lokasi yang aman. Jika forensics investigation sedang berlangsung, containment actions harus dikoordinasikan dengan forensics firm untuk memastikan bahwa containment actions tidak menghapus bukti yang diperlukan.
Fase 4: Pengambilan Keputusan Notifikasi dan Penilaian Risiko
Saat investigasi berlangsung dan scope breach menjadi jelas, tim harus melakukan risk assessment formal untuk menentukan apakah notifikasi kepada subjek data diperlukan. Risk assessment harus mempertimbangkan: sifat data yang terdampak, kategori subjek data yang terdampak (apakah termasuk anak-anak?), apakah data terenkripsi atau terunmasked (data yang terenkripsi memiliki risiko lebih rendah), apakah ada bukti bahwa penyerang benar-benar mengakses dan exfiltrate data atau hanya akses tanpa data exfiltration, konteks praktis (risiko fraud, discrimination, identity theft, financial loss).
Risk assessment harus didokumentasikan secara formal dalam risk assessment worksheet atau memo yang menjabarkan: temuan investigasi, faktor-faktor yang dipertimbangkan, conclusional judgment mengenai apakah risiko tinggi, dan approval dari executive decision-maker. Jika legal counsel dan DPO tersedia, mereka harus terlibat dalam penilaian risiko. Keputusan notifikasi yang didokumentasikan dengan baik adalah defensible jika LPDP kemudian mempertanyakan keputusan tersebut.
| KONSEP KUNCI | Penilaian risiko untuk notifikasi bukan latihan matematika. Ini adalah judgment call yang mempertimbangkan konteks bisnis, teknologi, dan hukum. LPDP mungkin mempertanyakan penilaian risiko selama investigasi, oleh karena itu dokumentasi yang matang adalah penting untuk menunjukkan bahwa organisasi telah melakukan reasonable inquiry. |
Fase 5: Eksekusi Notifikasi (Notification Execution)
Jika keputusan adalah untuk melakukan notifikasi kepada LPDP dan/atau subjek data, tim harus mempersiapkan konten notifikasi yang akurat dan lengkap. Notifikasi kepada LPDP harus berisi semua elemen required yang dijelaskan dalam Pasal 46(1), dengan level detalnya yang sesuai dengan informasi yang tersedia pada waktu notifikasi. Notifikasi harus dikirim melalui channel yang aman dan resmi; organisasi harus mempertahankan proof of submission (delivery receipt atau signed confirmation).
Untuk notifikasi kepada subjek data, organisasi harus mempertimbangkan delivery method yang paling efektif dan aman: email jika email addresses diketahui dan akurat; SMS untuk update cepat; postal mail untuk formal notification; atau public notice melalui website jika jumlah affected subjects sangat besar. Konten notifikasi harus dalam bahasa yang jelas dan mudah dipahami (bukan jargon teknis), dan harus memberikan informasi konkrit yang dapat diambil subjek data (contoh: langkah-langkah untuk monitoring akun, contact information untuk customer service untuk pertanyaan).
Koordinasi dengan PR/Communications team adalah penting untuk memastikan message consistency dan untuk mempersiapkan media response jika breach menjadi berita publik. Organisasi harus mengantisipasi bahwa notifikasi kepada subjek data mungkin akan menjadi public knowledge, dan harus siap untuk komunikasi proaktif kepada media dan public.
Fase 6: Post-Incident Activities (Post-Incident Activities)
Setelah insiden contained dan notifikasi lengkap, tim IR harus melakukan post-incident activities yang komprehensif. Root cause analysis harus mengidentifikasi why the breach terjadi: apakah ada configuration error? Unpatched vulnerability? Weak password policy? Lack of security awareness training? Failures in access control? Failures in monitoring? Root cause analysis harus go beyond the immediate vulnerability (misalnya, "penyerang memanfaatkan SQL injection vulnerability") untuk menyurvei systematic failures yang memungkinkan vulnerability tersebut untuk exis dan untuk dimanfaatkan tanpa terdeteksi.
Lessons learned session harus melibatkan representasi dari IR team, IT security, IT operations, business leaders, dan DPO. Sesi ini harus mengidentifikasi what went well dan what can be improved. Lessons learned harus diterjemahkan menjadi concrete security improvement actions: contohnya, implementasi of WAF (Web Application Firewall) untuk prevent SQL injection, implementasi of vulnerability scanning dalam CI/CD pipeline, revision of access control policies, additional staff training. Improvement actions harus tracked dan assigned kepada responsible parties dengan target completion dates.
LPDP mungkin meminta follow-up report tentang actions yang diambil untuk prevent similar breaches di masa depan. Organisasi harus mendokumentasikan semua improvement actions dan dapat menunjukkan bukti implementasi (contoh: screenshot dari WAF logs menunjukkan bahwa aplikasi sekarang dilindungi, audit report menunjukkan bahwa vulnerability management telah ditingkatkan).
Template Praktis untuk Incident Response Documentation
Organisasi harus mengembangkan template standar untuk mendokumentasikan incident response, memastikan konsistensi dan completeness. Template minimal harus mencakup: Incident Reporting Form (initial report dari tim IR ke management dengan insiden ID, severity level, preliminary scope, estimated timeline), Incident Investigation Log (chronological record dari semua investigasi actions, findings, dan decision points), Risk Assessment Worksheet (untuk penilaian risiko notifikasi), dan Post-Incident Report (root cause analysis, lessons learned, improvement actions).
| Fase IR | Durasi Target | Key Activities | Outputs/Documentation |
|---|---|---|---|
| Preparation | Ongoing (1-2x per year) | Develop IR policy, train team, conduct tabletop, establish vendor relationships | IR plan, team roster, contact lists, retainer agreements |
| Detection | < 24 hours | Receive alert, triage, confirm breach, escalate to IR team | Incident report form, severity level assignment |
| Analysis | Day 1-3 | Scope investigation, timeline, affected data categories, forensics decision | Investigation log, preliminary risk assessment |
| Containment | Day 1-5 | Isolate systems, stop attacker access, preliminary remediation, preserve evidence | Containment action log, system isolation documentation |
| Risk Assessment | Day 3-7 | Formal risk evaluation, notification decision, legal review | Risk assessment worksheet, notification decision memo |
| Notification Execution | Day 14 (deadline for LPDP) | Prepare LPDP report, notify subjects, coordinate PR | LPDP notification, subject notification records |
| Post-Incident | Day 20-60 | Root cause analysis, lessons learned, improvement planning, LPDP follow-up | Post-incident report, improvement action plan |
Tabel Perbandingan: Incident Response Dalam Konteks UU PDP vs. Standar Industri Lain
Tabel di bawah membandingkan bagaimana persyaratan IR dalam UU PDP berinteraksi dengan standar industri lain seperti GDPR, NIST Cybersecurity Framework, dan ISO 27001.
| Aspek | UU PDP Pasal 46 | GDPR Pasal 33-34 | NIST CSF Respond | ISO 27001 A.16 |
|---|---|---|---|---|
| Deteksi & Triage | Must determine breach vs. incident | Determine if high risk to individuals | Activate response team | IR procedure invoked |
| Evidence Preservation | Implied (untuk forensics future) | Implied (untuk regulatory investigation) | Explicit requirement | Explicit requirement |
| Notification Timeline | 14 hari kalender ke LPDP; wajib | Maximum 72 hours ke DPA; conditional | Varies by incident type | Not prescriptive |
| Risk Assessment | Yes, untuk notifikasi subject | Yes, untuk notifikasi DPA/individuals | No specific requirement | Qualitative assessment |
| Documentation | Notification memo, risk assessment | Data controller assessment | IR logs & reports | Incident log & analysis |
| Post-Incident Review | Implied (untuk improvement) | Implied (untuk future prevention) | Explicit (Lessons Learned) | Management review required |