Orta ölçekli bir lojistik firması düşünün: e-Fatura sistemi sabah 08.00’de yanıt vermiyor, ERP ekranları donuyor, muhasebe müdürü sunucuya erişemiyor. BT sorumlusu durumu incelediğinde fidye yazılımının gece boyunca yayıldığını görüyor. Firewall kurulu, antivirüs lisansı güncel — ama şirket ne yapacağını bilmiyor. İşte bu noktada ortaya çıkan boşluk, teknik değil yönetimsel bir boşluktur.
Siber güvenlik tartışmalarının büyük bölümü hâlâ savunma katmanlarına odaklanıyor: güvenlik duvarı, ağ segmentasyonu, uç nokta koruması, çalışan farkındalık eğitimi. Bunların hepsi gerekli. Ancak hiçbir savunma sistemi yüzde yüz koruma sağlamıyor. Güvenlik uzmanlarının uzun süredir dile getirdiği bir gerçek var: saldırının olup olmayacağı değil, ne zaman olacağı sorusu üzerinden planlamak gerekiyor. Bu perspektif, iş sürekliliği planlamasını teknik bir ek olmaktan çıkarıp stratejik bir yönetim aracına dönüştürüyor.
Olay müdahale planı, bir siber saldırı anında kimin ne yapacağını, hangi sırayla yapacağını ve kime raporlayacağını önceden tanımlayan belgedir. Planın dört temel bileşeni var: tespit ve sınıflandırma, müdahale ve izolasyon, kurtarma ve geri yükleme, son olarak olay sonrası analiz. Bu dört aşamanın her biri için sorumlu isimler, yedek sorumlular ve zaman hedefleri önceden belirlenmiş olmalı. Bir şirkette bu belge yoksa saldırı anında yöneticiler birbirini arıyor, kararlar gecikmeli alınıyor ve hasar büyüyor.
Olay müdahale ekibinin yapısı şirketin büyüklüğüne göre değişiyor, ancak temel roller sabittir. Teknik lider sistemi izole eder ve kanıtları korur. İletişim sorumlusu iç ve dış paydaşları bilgilendirir — müşteriler, tedarikçiler, gerekirse yasal merciler. Üst yönetim temsilcisi iş kararlarını alır: hangi sistemler önce kurtarılacak, operasyonun hangi bölümü manuel süreçle devam edecek, kamuoyuna ne zaman açıklama yapılacak. Bu rollerin saldırı anında değil, öncesinde tanımlanmış olması kritik fark yaratıyor.
İletişim protokolü çoğu zaman göz ardı edilen ama maliyeti yüksek bir unsur. Saldırı anında e-posta sistemleri çalışmıyor olabilir; dahili mesajlaşma araçları etkilenmiş olabilir. Şirketin alternatif iletişim kanallarını — şifreli mesajlaşma uygulamaları, önceden belirlenmiş telefon ağaçları, fiziksel toplanma noktaları — önceden kurgulaması gerekiyor. Öte yandan dışa yönelik iletişim de hassas bir denge istiyor: müşterilere çok geç haber vermek güven kaybına yol açıyor, çok erken ve belirsiz açıklama ise paniği büyütüyor. Bu dengeyi saldırı sırasında kurmaya çalışmak neredeyse imkânsız; şablonların ve karar ağaçlarının önceden hazırlanmış olması gerekiyor.
Kurtarma süresi hedefleri — sektörde RTO (Recovery Time Objective) ve RPO (Recovery Point Objective) olarak bilinen kavramlar — iş sürekliliği planının ölçülebilir omurgasını oluşturuyor. RTO, sistemin ne kadar sürede yeniden çalışır hale geleceğini; RPO ise en son hangi noktadaki veriye geri dönülebileceğini tanımlıyor. Bir e-ticaret şirketi için dört saatlik RTO kabul edilemez olabilirken, bir üretim firması için aynı süre tolere edilebilir. Bu hedeflerin gerçekçi biçimde belirlenmesi, yedekleme mimarisini ve felaket kurtarma altyapısını doğrudan şekillendiriyor. Bulut tabanlı yedekleme çözümleri bu hedeflerin daha düşük maliyetle karşılanmasına olanak tanıyor; ancak yedeklerin düzenli test edilmesi şartı burada da geçerliliğini koruyor.
Karar vericiler için asıl soru şu: planı yazmak mı, yoksa planı test etmek mi daha önemli? İkisi de zorunlu, ama öncelik sırası var. Yazılmamış bir plan işe yaramaz; ancak test edilmemiş bir plan da saldırı anında çöküyor. Masaüstü tatbikatlar — gerçek sistemlere dokunmadan senaryo üzerinden yapılan simülasyonlar — hem planın açıklarını ortaya çıkarıyor hem de ekip üyelerinin rollerini içselleştirmesini sağlıyor. Yılda en az bir kez yapılan bu tatbikatlar, sigorta primlerini düşürmek için değil, gerçek hazırlık için yapılmalı. Dijital dönüşüm yatırımları büyüdükçe bu altyapının korunması da stratejik bir öncelik haline geliyor.