Ilustrasi respon insiden dan pemulihan sistem pasca bencana digital — cyber resilience concept

Hari kedua belajar cybersecurity lewat ISC² Certified in Cybersecurity (CC).
Topiknya: Incident Response, Business Continuity, and Disaster Recovery — bagian yang benar-benar menguji kesiapan organisasi menghadapi kekacauan.


🌪️ Dari Krisis ke Ketahanan

Kalau Domain 1 berbicara soal “mencegah”, Domain 2 berbicara soal “bertahan dan pulih”.
Tidak peduli seberapa kuat sistem keamanan dibangun, insiden pasti akan terjadi — entah karena kesalahan manusia, serangan siber, atau bencana alam.

Kuncinya bukan hanya mencegah insiden, tapi bagaimana merespons dan bangkit kembali dengan cepat.
Itulah esensi dari tiga rencana penting ini: Incident Response (IR), Business Continuity (BC), dan Disaster Recovery (DR).


🎯 Fokus Hari Ini


🧠 Catatan Belajar

1. Incident Response (IR)

IR adalah garis depan saat ada insiden.
Tujuannya sederhana tapi penting: kendalikan kerusakan, kumpulkan bukti, dan pulihkan sistem secepat mungkin.

Tahapannya biasanya:

  1. Preparation – siapkan kebijakan, tim, dan alat deteksi.
  2. Detection & Analysis – identifikasi insiden dengan log, alert, atau anomali.
  3. Containment – hentikan penyebaran (misalnya isolasi host yang terinfeksi).
  4. Eradication & Recovery – hapus penyebabnya dan kembalikan layanan.
  5. Lessons Learned – dokumentasikan, perbaiki SOP, dan latih ulang tim.

🔎 Menariknya, fase terakhir ini yang paling sering dilupakan di dunia nyata — padahal di sinilah organisasi tumbuh lebih kuat.


2. Business Continuity (BC)

BC lebih strategis: bagaimana bisnis tetap berjalan selama krisis.
Kalau IR fokus ke sistem, BC fokus ke operasional manusia dan proses bisnis.

Contohnya:

Yang saya suka dari konsep ini: BC bukan soal teknologi, tapi soal kesiapan mental dan koordinasi.


3. Disaster Recovery (DR)

Jika IR dan BC gagal menjaga kestabilan, maka DR mengambil alih.
Fokusnya: mengembalikan infrastruktur dan data ke kondisi normal.

Ada beberapa strategi pemulihan:

Dari ketiganya, saya jadi sadar bahwa waktu pemulihan (RTO) dan data yang boleh hilang (RPO) bukan sekadar angka —
mereka adalah komitmen organisasi terhadap pelanggan dan publik.


💭 Refleksi Pribadi

Domain ini membuat saya berpikir ulang tentang arti “resilience”.
Sebagai engineer, saya sering fokus pada uptime dan bug fix, tapi jarang mikir: kalau sistem saya benar-benar jatuh, apa rencana cadangannya?

⚡️ Keamanan bukan hanya mencegah jatuh, tapi juga tahu bagaimana bangkit dengan cepat.

Saya juga mulai melihat bagaimana IR, BC, dan DR bukan proyek terpisah, tapi satu ekosistem kesiapan.
Dalam konteks kerja, saya ingin mulai dengan hal sederhana:


🔍 Catatan Kecil