Siber Olay Müdahale Planı: Kararlar, Saatler ve Kanıt

Olay müdahale planı çoğu kurumda bir şablonun indirilip üzerine logo eklenmesiyle başlıyor, denetimde "var" sayılmasıyla bitiyor. Sonra gerçek bir olayda o belgenin tek bir cümlesi kullanılmıyor: gece iki buçukta hiç kimsenin sunucuyu ağdan çıkarma yetkisi yoktur, hukuk ekibi "kişisel veri ihlali mi" sorusunu cevaplayacak teknik kaydı bulamaz, yedekten dönüşün altı saat değil on dört saat sürdüğü ilk kez o gece öğrenilir. Plan kâğıt üzerinde doğruydu; yanlış olan, plandan beklenen şeydi.

Bu rehberin kalkış noktası şu: plan bir belge değil, baskı altında verilmiş kararların listesidir. Kim olay ilan eder, kim komuta eder, kim neyi durdurabilir, hangi eşikte kime haber verilir, kanıtı kim dışa aktarır, dışarıdan yardım hangi imzayla başlar. Bu altı sorunun cevabı yazılı değilse, olay anında cevap aramak için geçen süre olayın kendisinden daha pahalıya mal olur.

Türkiye'de bu işin bir de kendine özgü tarafı var. 7545 sayılı Siber Güvenlik Kanunu bildirimi "gecikmeksizin" diye istiyor ve sayısal bir süre vermiyor; 6698 sayılı Kanun tarafında ise kişisel veri ihlalinde 72 saatlik beklenti var. Yani elinizde iki ayrı saat ve iki ayrı muhatap oluyor, üstüne sektör düzenleyicinizin ve müşteri sözleşmenizin saatleri biniyor. Plan bu saatleri saymak için değil, ilk saatte kimin ne yaptığını önceden yazmak için var. Rehber boyunca üç şey yapıyoruz: kararları yazıyoruz, iki aritmetiği hesaplıyoruz (kanıt saklama ve geri dönüş süresi), ve Türkiye'de denetimde istenen kanıtı madde madde listeliyoruz.

Plan bir belge değil, önceden verilmiş kararlar listesidir

Olay müdahale literatürünün son yirmi yılı faz diyagramıyla geçti: hazırlık, tespit ve analiz, kontrol altına alma, temizleme ve kurtarma, olay sonrası faaliyet. Bu şema neredeyse her planda duruyor. NIST, Nisan 2025'te yayımladığı SP 800-61 Revizyon 3 ile çerçeveyi değiştirdi: artık hazırlık, Govern, Identify ve Protect fonksiyonlarının içinde; müdahale ise Detect, Respond ve Recover olarak üç başlıkta ele alınıyor, sürekli iyileştirme de fonksiyonların arasında ayrı bir katman. Bunun pratik anlamı şu: müdahale, sırayla geçilen aşamalar değil, eksik bilgiyle art arda verilen kararlar.

Bu yüzden planın omurgası fazlar değil dört karar olmalı. Birincisi, olayı kim ilan eder. Bu yetki tek bir role yazılmalı ve o rolün yedeği de yazılmalı; "olay müdahale ekibi karar verir" cümlesi bir komiteyi tarif eder, komite gece üçte toplanmaz. İkincisi, olayı kim komuta eder. Komutan teknik olarak en bilgili kişi olmak zorunda değil; karar veren, kaydı tutan ve iletişimi yöneten kişi olmalı. Üçüncüsü, kim neyi durdurabilir. Ağ izolasyonu, hesap kilitleme, üretim veritabanını salt okunur moda alma, tedarikçi erişimini kesme: her biri bir eşik ve bir üst sınırla önceden yetkilendirilmeli. Dördüncüsü, hangi eşikte kime haber verilir. Yönetim, hukuk, sigorta, müşteri, düzenleyici ve basın için ayrı eşikler gerekir; hepsini aynı eşiğe bağlamak ya erken ve gereksiz bir alarm ya da geç ve pahalı bir sessizlik üretir.

Bu dört kararın ortak özelliği, hepsinin olaydan önce verilebilmesi. Olay sırasında verilemezler, çünkü olay sırasında bilgi eksik, saat geç ve herkes yorgun. Planın değeri tam olarak burada: kararı olay anından alıp sakin bir güne taşıyor.

Sizi bağlayan saatler: dört ayrı katman

Bir olayın bildirim yükümlülüğü tek bir saatle yönetilmiyor. Aynı olay aynı anda dört ayrı rejime düşebilir ve bu rejimlerin başlangıç anları, süreleri ve muhatapları farklı. Planın ilk tablosu bu olmalı, çünkü bildirim kararını veren kişi hangi saatin işlediğini bilmezse ya gereksiz panik ya da sessiz bir gecikme üretir.

Katman	Ne zaman devreye girer	Süre	Muhatap
7545 sayılı Kanun md.7/1(b)	Tespit edilen zafiyet veya siber olay	Kanunda sayısal süre yok; "gecikmeksizin"	Siber Güvenlik Başkanlığı
6698 sayılı Kanun md.12(5)	Kişisel verilerin kanuni olmayan yollarla elde edilmesi	72 saat (2019/10 sayılı Kurul kararı), gecikmede gerekçe	Kişisel Verileri Koruma Kurulu ve ilgililer
Sektör düzenleyicisi	Sektöre göre değişir: bankacılık, sermaye piyasası, sağlık, enerji, telekom	Sektör tebliğinde yazılı, genelde saatler mertebesinde	İlgili kurum
Sözleşme ve tedarik zinciri	Müşteri verisine veya hizmet sürekliliğine etki	Sözleşmede yazılı; sık görülen 24 saat	Müşteri, iş ortağı, siber sigorta

7545 tarafında durum şu: Kanunun 7 nci maddesinin birinci fıkrasının (b) bendi, kapsamdaki kişilerin "siber güvenliğe yönelik olarak milli güvenlik, kamu düzeni veya kamu hizmetinin gereği gibi yürütülmesi amacıyla mevzuatın öngördüğü tedbirleri almak, hizmet sundukları alanda tespit ettikleri zafiyet veya siber olayları gecikmeksizin Başkanlığa bildirmek" yükümlülüğünü düzenliyor. Metinde gün, saat ya da iş günü yok. Bu boşluk bir rahatlık değil, tersine daha zor bir durum: süreyi kanun söylemediği için "makul süre"yi sizin kayıt düzeniniz kanıtlayacak. Aynı maddenin (c) bendi, kamu kurumları ve kritik altyapı işletmeleri için siber güvenlik ürün ve hizmetlerinin yalnızca Başkanlıkça yetkilendirilmiş ve belgelendirilmiş sağlayıcılardan temin edilmesini şart koşuyor; bu, dışarıdan olay müdahale hizmeti alacak bir kritik altyapı işletmesi için tedarikçi seçimini doğrudan belirleyen bir hüküm. (b) ve (c) bentlerinin ihlalinde idari para cezası öngörülüyor; 2025 nominal tutarlarıyla bir milyon ile on milyon TL aralığında ve her yıl yeniden değerleme oranında güncelleniyor.

6698 tarafında ise md.12(5) uyarınca kişisel verilerin kanuni olmayan yollarla elde edilmesi hâlinde durum en kısa sürede ilgili kişiye ve Kurula bildirilir; 24.01.2019 tarihli ve 2019/10 sayılı Kurul kararı bu süreyi Kurula bildirim için 72 saat olarak yorumluyor ve gecikme varsa gerekçesinin bildirilmesini istiyor. Kritik nokta, saatin "kesinleşme" anında değil "haberdar olma" anında başlaması: yani olayı öğrendiğiniz dakikayı ve o anda elinizdeki kanıtı kaydetmeniz gerekiyor.

Bu iki rejim çakıştığında pratik kural şudur: en kısa saat baskın gelir, ama bildirimler birbirinin yerine geçmez. Başkanlığa yapılan bildirim Kurula yapılmış sayılmaz; Kurula yapılan bildirim de 7545 kapsamındaki olay bildirimini ortadan kaldırmaz. Plan, kimin hangi bildirimi hangi şablonla yaptığını ayrı ayrı yazmalı.

"Gecikmeksizin" ifadesinin ölçülebilir karşılığı: iç saat

Kanunun sayı vermemesi, ölçemeyeceğiniz anlamına gelmiyor. Tersine, savunmanızı kuracağınız tek şey kendi iç saatinizin kaydı olacak. Bu yüzden plana dört eşik yazılmalı: tespitten itibaren 30 dakika içinde olay kaydı açılır ve olay numarası verilir; 2 saat içinde ilk kapsam tahmini ve şiddet sınıflandırması yapılır; 4 saat içinde bildirim kararı (yapılacak / yapılmayacak / veri bekleniyor) gerekçesiyle kayda geçer; 24 saat içinde ilk bildirim gönderilir ve eksik bilgi listesi eklenir.

Bu eşiklerin değeri, hukuki bir süreyi ikame etmeleri değil, gecikmenin nerede oluştuğunu göstermeleri. Bir olayda bildirim 40 saat sonra çıktıysa iki olasılık var: ya kimse olayı fark etmedi, ki bu bir tespit sorunudur; ya da fark eden kişi kime söyleyeceğini bilmedi, ki bu bir eskalasyon sorunudur. Bu ikisi tamamen farklı yatırımlar gerektirir ve ancak zaman damgaları tutulursa ayırt edilebilir. Bu yüzden olay kaydının ilk alanları şunlar olmalı: fark etme zamanı, fark eden kişi, ilk kayıt zamanı, olay komutanı atama zamanı, ilk bildirim zamanı, kapanış zamanı. Bu altı damga, yıl sonunda planın tek gerçek performans ölçümü olur.

Bir uyarı: tutamayacağınız kadar iddialı eşik yazmak, hiç yazmamaktan kötü. Denetimde "plandaki 4 saatlik hedefi 19 olayın 11'inde tuttuk" cümlesi bir bulgudur ve düzeltilebilir; "hedefimiz yoktu" cümlesi ise planın olmadığını gösterir. Gerçekçi başlangıç, son on iki ayda yaşanan üç olayın gerçek sürelerini ölçüp hedefi o rakamın yüzde 30 altına koymak.

Şiddet sıfatla değil testle yazılır

"Yüksek", "orta", "düşük" gibi etiketler planı okunamaz kılar, çünkü herkesin kafasında farklı bir eşik vardır ve tartışma tam olarak tartışmaya vaktiniz olmayan anda başlar. Şiddet, test edilebilir cümlelerle yazılmalı: etki alanında kişisel veri var mı, üretim sistemleri erişilebilir mi, saldırgan hâlâ içeride mi, finansal işlem yapılmış mı. Her testin cevabı evet ya da hayır olduğu için sınıflandırma tartışma değil, kontrol listesi hâline gelir.

Seviye	Test (biri evet ise)	İlk müdahale	Eskalasyon
S1	Üretim durdu ya da aktif saldırgan erişimi sürüyor	15 dakika içinde olay komutanı, derhal izolasyon yetkisi	Yönetim kurulu bilgilendirmesi aynı gün
S2	Kişisel veriye erişilmiş ya da erişilmiş olma ihtimali makul	1 saat içinde hukuk ve veri sorumlusu devrede	72 saatlik bildirim zinciri başlar
S3	Tek sistem etkilendi, yayılma kanıtı yok	4 saat içinde kapsam ölçümü ve izolasyon kararı	Haftalık olay incelemesine girer
S4	Başarısız girişim, engellenmiş saldırı, tek uç nokta	Kayıt ve izleme, 24 saat içinde kapanış	Eğilim raporuna girer
Bilinmiyor	Kapsam henüz ölçülemedi	S2 varsayılanıyla ilerle, ölçüm bitince indir	Belirsizlik 2 saati geçerse S1'e yükselt

Son satır, planın en çok atlanan ve en çok işe yarayan kısmı. Gerçek olaylarda ilk otuz dakikada kapsam neredeyse hiç bilinmez; bu yüzden "bilmiyoruz" cevabının da bir karşılığı olmalı. Varsayılanı yukarı çekmek, yani bilinmiyorsa bir üst seviye gibi davranmak, hem gecikmeyi önler hem de sonradan indirmeyi kolaylaştırır: yükseltmek için kanıt gerekmez, indirmek için gerekir. Ters kurgu, yani kanıtlanana kadar düşük kabul etmek, ilk saatlerin tamamını tartışmayla geçirir.

Şiddet tablosuna bir de saat eşlik etmeli. Aynı seviye, mesai içinde ve mesai dışında farklı hız demek: S1 gece üçte de on beş dakikada ayağa kalkmalı, bu da nöbet listesi olmadan mümkün değil. Plan "çağrı rotasyonu" ve "hafta sonu komutan yedeği" satırlarını içermiyorsa, tablo kâğıt üzerinde doğru, sahada ölü olur.

Yetki: gece üçte kimse izin aramasın

Gerçek olaylarda en pahalı gecikme teknik değil bürokratik: bir alt ağın ağdan çıkarılması için onay aramak. Bu yüzden izolasyon, hesap kilitleme ve oturum iptali yetkileri önceden, yazılı ve üst sınırıyla verilmeli. İyi bir yetki cümlesi şöyle görünür: "Olay komutanı, S1 ve S2 olaylarında etkilenen segmentin tamamını en fazla 4 saatliğine ağdan izole edebilir; 4 saati aşan izolasyon için bilgi işlem yöneticisinin onayı gerekir." Bu cümle hem hız verir hem de yetkinin sınırsız olmadığını gösterir; denetimde sorulan soru da tam olarak budur.

İki ayrıntı sık atlanır. Birincisi, izolasyon elektrik kesmek değildir. Cihazı kapatmak, bellekte duran ve başka hiçbir yerde bulunmayan kanıtı yok eder; ağ izolasyonu ise sistemi çalışır bırakıp bağlantıyı keser. Plan bu farkı açıkça yazmalı, çünkü panik anındaki ilk refleks fişi çekmek oluyor. İkincisi, yetki erişim yolu olmadan işe yaramaz. Yetkili kişinin o anda o sistemlere gerçekten erişebildiği olaydan önce denenmeli: ayrı bir yönetim ağı, ikinci faktörü ayrı taşınan bir acil durum hesabı, VPN profili, konsol erişimi. Fidye yazılımı olaylarında en sık duyulan cümle "yetkimiz vardı ama giremedik" oluyor, çünkü kimlik altyapısı da saldırının içindeydi.

Acil durum hesapları da planın parçası. Kaç tane var, kimde, hangi kasada, en son ne zaman test edildi, parolası hangi prosedürle değiştirilir? Bu hesaplar normal kimlik doğrulama altyapısına bağımlı olmamalı; aksi hâlde tam ihtiyaç duyulan anda çalışmazlar. Buna karşılık her acil hesabın kullanımı otomatik olarak olay kaydına düşmeli ve kullanım sonrası parola değişimi zorunlu olmalı; aksi hâlde acil erişim, kalıcı bir arka kapıya dönüşür.

İlk saat: delili yok etmeyen sıra

İlk saatte yapılan her müdahale aynı zamanda bir kanıt kaybı riski taşıyor. Bu yüzden sıra önemli: önce doğrula, sonra ölç, sonra dışa aktar, en son izole et. İzolasyonu en sona bırakmak saldırganın birkaç dakika daha içeride kalması anlamına gelebilir; bu yüzden gerçek uygulamada sıra şöyle kurulur: doğrulama ve ilk dışa aktarma paralel yürür, izolasyon dışa aktarma başladığı anda yapılır, cihaz kapatılmaz.

1. Doğrula ve zamanı yaz. İhbar doğru mu, hangi sistem, hangi kullanıcı, hangi zaman aralığı? Bu aşamada "olay yok" demek için acele etmeyin; oltalama sonrası oturum çerezi hırsızlığında teknik hiçbir uyarı çıkmaz, tek işaret olağandışı oturum kaydıdır.
2. Kapsamı ölç. Etkilenen kimlik sayısı, etkilenen sistem sayısı, veri hacmi, veri kategorisi. Bu dört sayı hem şiddeti hem bildirim kararını belirler.
3. Kanıtı dışa aktar. Kimlik sağlayıcı (giriş kayıtları, MFA değişiklikleri, uygulama onayları), posta platformu (posta kutusu kuralları, yönlendirmeler, temsilci erişimi), uç nokta konsolu (süreç ağacı, kalıcılık noktaları), bulut denetim izi ve VPN kayıtları. Dışa aktarım, saldırganın kontrol etmediği bir depoya tarih damgalı ve hash'lenmiş olarak yapılır.
4. İzole et. Ağ izolasyonu, hesap kilitleme, oturum belirteçlerinin iptali, tedarikçi erişiminin kesilmesi. Sıra, yayılma yönüne göre belirlenir.
5. Kaydı aç ve komutan ata. Olay numarası, zaman damgaları, ilk kararlar ve gerekçeleri. Bu kayıt sonradan hem bildirimin hem de olası bir davanın temeli olur.

Kanıt önceliği uçuculuk sırasına göre yazılmalı: önce bellek ve açık oturumlar, sonra ağ bağlantıları ve süreç durumu, sonra disk, en son yedek ve arşiv. Disk görüntüsü almak iyi bir uygulamadır ama bellekteki oturum belirtecini kaçırdıysanız saldırganın hangi hesapla gezdiğini asla öğrenemezsiniz. Aynı şekilde "sistemi temizleyip yeniden kuralım" kararı inceleme bitmeden verilirse kanıt kaynağı yok olur; temiz kurulum kararı, inceleme kapsamı yazılı hâle geldikten sonra verilmeli.

Kanıt saklama süresi tespit süresinden kısa: aritmetik

Olay müdahale planının en sık görülen tasarım hatası, kanıt saklama süresini platformun varsayılanına bırakmak. Varsayılanlar kısa: AWS CloudTrail olay geçmişi 90 gün, Okta sistem günlüğü 180 gün. Buna karşılık IBM'in 2025 Cost of a Data Breach çalışması, Mart 2024 ile Şubat 2025 arasında ihlal yaşamış 600 kuruluşta ortalama tespit ve kontrol altına alma süresini 241 gün, kurum içi tespit edilen olaylarda ise 172 gün olarak veriyor.

Ölçüm	Değer	Plan açısından anlamı
Ortalama tespit ve kontrol (2025)	241 gün	Yaklaşık 8 ay; yıllık bütçe döngüsünden uzun
Kurum içi tespit edilenlerde	172 gün	Kendi ekibiniz bulduğunda bile yaklaşık 6 ay
Kimlik sağlayıcı varsayılan saklama	90-180 gün	172 günlük tespitte 82 günlük kanıt boşluğu

Son satırın hesabı basit: kurum içi ortalama tespit süresi 172 gün, kimlik günlüklerinin varsayılan saklaması 90 gün ise, olayı fark ettiğiniz gün ilk 82 günün kanıtı çoktan silinmiş oluyor. Saldırganın ilk girişini, ilk kalıcılık kurulumunu ve yatay hareketin başlangıcını göremezsiniz; elinizde yalnızca son 90 gün kalır, ki bu genellikle hikâyenin ortasıdır. Bu yüzden plan her sistem sınıfı için dört şeyi yazmalı: ne toplanıyor, kaç gün saklanıyor, nereye gidiyor, kim dışa aktarabiliyor. Saklama süresi umulan tespit süresine değil gerçekçi tespit süresine göre belirlenmeli. Pratik kural: gerçekçi tespit süresinin en az bir buçuk katı, alt sınır 180 gün.

Burada bir maliyet gerçeği var: kimlik ve bulut denetim günlüklerini 365 güne çıkarmak çoğu sağlayıcıda pahalı değil, çünkü depolama maliyeti ihmal edilebilir; pahalı olan sorgu ve analiz lisansları. Bu yüzden doğru mimari her şeyi sıcak tutmak değil, sıcak veriyi 90 gün, soğuk ama sorgulanabilir arşivi 400 gün tutmak. Arşivin anahtarı da saldırganın erişemeyeceği bir hesapta olmalı; fidye yazılımı olaylarında ilk hedef yedekler ve günlük arşivi oluyor.

Geri dönüş süresi: plana yazılan sayı ile gece öğrenilen sayı

Kurtarma hedefi (RTO) çoğu planda tek bir sayı olarak yazılıyor, örneğin "kritik sistemler 4 saat içinde". Bu sayının gerçekten tutup tutmadığı ise hiçbir şablon testiyle ortaya çıkmıyor, çünkü asıl belirleyici yedekten dönüşün toplam verimi. Aritmetik basit: 12 TB veriyi tek akışta saniyede 250 MB hızla geri yazarsanız süre yaklaşık 13,98 saat; saniyede 500 MB ile yaklaşık 6,99 saat. Yani 4 saatlik bir kurtarma hedefi için yaklaşık 916 MB/s toplam verim, 8 saat için 458 MB/s, 24 saat için 153 MB/s gerekiyor.

Kurtarma hedefi	12 TB için gereken toplam verim	Tek akışla gerçekleşir mi
4 saat	Yaklaşık 916 MB/s	Hayır; 250 MB/s akışta 13,98 saat sürer
8 saat	Yaklaşık 458 MB/s	Tek akışta 500 MB/s varsa sınırda
24 saat	Yaklaşık 153 MB/s	Evet, 250 MB/s akışla rahatça

Bu tablo iki şeyi görünür kılıyor. Birincisi, 4 saatlik bir hedef tek akışla matematiksel olarak imkânsız; dört paralel akış ve yedek deposunun o verimi kaldırabilmesi gerekir. İkincisi, hedefi tutmak için gereken yatırım bir yedek yazılımı lisansı değil, depolama ve ağ bant genişliği. Denetimde "RTO'nuzu test ettiniz mi" sorusuna verilecek doğru cevap, bir tarih ve ölçülen süre: "son testte 12 TB, 3 paralel akışla 15 saat 20 dakikada döndü, hedef 4 saat, fark kapatılmadı, aksiyon şu."

Sayıya eklenmesi gereken üç kalem var, çünkü gerçek süre bunların toplamı: doğrulama süresi (geri yazılan verinin bütünlük kontrolü), bağımlılık sırası (kimlik, DNS, sertifika, uygulama, veritabanı; yanlış sırada başlatılan sistem çalışmaz) ve trafik geri açma. Ayrıca fidye yazılımı sonrası "temiz yedek" seçimi kendi başına bir süre kalemi: hangi yedeğin bulaşmadan önce alındığını bilmek için yedek kataloğunun zaman damgaları ve dosya bütünlüğü kontrolü gerekiyor. Plan bu üç kalemi ayrı ayrı yazmazsa kurtarma hedefi kâğıt üzerinde tutulur, sahada tutulmaz.

Kanıtın denetimde ve mahkemede ayakta kalması

Olay incelemesinin çıktısı bir rapor değil, bir kanıt zinciri. Denetçinin ve hukukçunun aradığı üç şey var: kanıtın nereden alındığı, kimin eriştiği ve değişmediğinin nasıl gösterildiği. Bu üçü yoksa, doğru bir teknik analiz bile savunmada işe yaramıyor.

• Kaynak ve zaman: her dışa aktarımın hangi sistemden, hangi sorguyla, hangi saat diliminde alındığı yazılır. Saat dilimi farkı, olay kronolojisini bozan en yaygın hatadır; tüm kayıtlar UTC tutulmalı, sunulurken yerel saate çevrilmeli.
• Bütünlük: her dosya için SHA-256 özeti alınır ve olay kaydına yazılır. Özet, kanıtın sonradan değişmediğini göstermenin en basit yolu.
• Zincir: kanıtı kimin aldığı, nerede sakladığı, kimin eriştiği. Yazma izni olmayan bir depo, tek yönlü kopya, erişim günlüğü.
• Bütünlük iddiasının sınırı: "hiçbir şey değişmedi" demek yerine "şu dosyalar şu özetlerle alındı, şu aralıkta şu hesaplar erişti" demek. İkincisi kanıtlanabilir, birincisi değil.

ISO/IEC 27001:2022 bu konuyu ayrı bir kontrol olarak ele alıyor: Ek A 5.24 hazırlık ve planlama, 5.25 olayların değerlendirilmesi ve karar, 5.26 müdahale, 5.27 olaylardan öğrenme, 5.28 kanıt toplama. Denetimde en çok zorlanılan madde 5.28 oluyor, çünkü politika metni kolay yazılıyor ama kanıt toplama prosedürünün çalıştığını gösteren kayıt istiyor. Bu yüzden plan, kanıt toplama adımını bir tatbikatta bir kez gerçekten çalıştırmalı ve çıktısını saklamalı.

Tatbikat: senaryoyu değil varsayımı test et

Masa başı tatbikatların çoğu, katılımcıların bildiği bir senaryoyu canlandırıyor ve herkesin doğru cevabı verdiği bir toplantıyla bitiyor. Bu bir prova değil, bir sunum. İşe yarayan tatbikat, planın dayandığı varsayımları tek tek kaldırıyor: olay komutanına ulaşılamıyorsa ne olur, yedek deposu da etkilenmişse ne olur, tedarikçinin 4 saatlik taahhüdü tutmazsa ne olur, hukuk ekibi şehir dışındaysa ne olur. Her kaldırılan varsayım, ölçülebilir bir karar gecikmesine dönüşmeli.

Ölçüm tasarımı basit olabilir: üç ayda bir, dört enjeksiyonlu bir masa başı; her enjeksiyonda "karar verildi mi, kaç dakikada, kim verdi" kaydı. Yılda dört tatbikat, üç yılda kırk sekiz gözlenmiş karar demek; bu sayı bir medyan okumak için yeterli, tek bir tatbikatın sonucu ise değil. Tutulacak iki ölçüt: izolasyon kararının medyan süresi 30 dakikanın altında mı, bildirim kararı verilen enjeksiyonların tamamında 4 saat içinde mi.

Tatbikatın çıktısı rapor değil, sahipli bulgu listesi olmalı. "İletişim zayıf" bir bulgu değil; "olay komutanı yedeği tanımlı değil, sahibi bilgi işlem müdürü, kapanış tarihi şu" bir bulgu. Ve bulgu listesi bir sonraki tatbikatın gündemi olmalı; aynı bulgu iki tatbikatta kapanmadan kalıyorsa sorun plan değil, planın sahibinin olmaması.

Dışarıdan yardım: sözleşme olmadan saat başlamaz

Olay anında dışarıdan bir ekibi aramak, ilk saatlerin en pahalı hatası. Çünkü dışarıdan bir ekip, telefonla arayarak sizin sistemlerinizden kanıt toplamaya başlayamaz: hangi tüzel kişinin varlığı üzerinde çalışacağı, kapsamın ne olduğu, hangi eylemlere yetkili olduğu, veriyi nasıl işleyeceği ve nereye çıkaracağı yazılı olmalı. Bu imza atılmadan geçen her saat, kanıt toplamanın gecikmesidir.

İyi bir çerçeve sözleşmenin en az şu başlıkları içermesi gerekir: taraflar ve varlığın sahibi, kapsamdaki sistemler, izin verilen eylemler (yalnızca tespit ve kanıt mı, yoksa temizleme de mi), veri işleme ve saklama koşulları, yurt dışına aktarım olup olmayacağı, raporlama formatı, gizlilik, ve olay komutanı ile tedarikçi arasındaki karar yetkisi. Bu maddeler ticari ayrıntı değil, hukuki dayanak: yetkisiz bir inceleme, kanıtı kullanılamaz hâle getirebilir.

Türkiye'ye özgü bir katman daha var. 7545 sayılı Kanunun 7 nci maddesinin (c) bendi, kamu kurumları ve kritik altyapı işletmelerinin siber güvenlik ürün ve hizmetlerini yalnızca Başkanlıkça yetkilendirilmiş ve belgelendirilmiş sağlayıcılardan temin etmesini istiyor. Bu kapsamda bir işletmeyseniz, olay anında arayacağınız ekibin bu yetkilendirmeye sahip olup olmadığını olaydan önce kontrol etmeniz gerekiyor; olay sırasında öğrenilen bir uyumsuzluk, hem bildirim yükümlülüğü hem tedarik riski doğurur.

Ayrıca kişisel veri içeren bir incelemede verinin yurt dışına çıkması ihtimali varsa 6698 sayılı Kanunun md.9 kapsamındaki aktarım rejimi devreye girer. Tedarikçi sözleşmesinde hangi verinin hangi ülkeye gittiği, veri işleyen yükümlülükleri ve sözleşme sonunda iade ya da silme taahhüdü yazılı olmalı. Kamu kurumlarında ve kritik altyapıda bu madde, tedarikçi seçimini fiilen belirliyor.

Fidye: teknik değil hukuki ve mali bir karar

Fidye yazılımı olaylarında planın en kritik boşluğu, ödeme kararının kim tarafından verileceğinin yazılı olmaması. Bu karar teknik bir ekip tarafından verilemez, çünkü üç ayrı sonucu var: hukuki (yaptırım listeleri, terör finansmanı düzenlemeleri, sigorta poliçesi şartları), mali (geri dönüş garantisi olmayan ödeme, ayrıca kurtarma maliyeti) ve itibari (müşteri ve düzenleyici iletişimi). Plan bu kararı bir role değil, bir kurula ve bir prosedüre bağlamalı.

Prosedür şu soruları içermeli: ödeme yapılacak adres yaptırım listelerinde mi, sigorta poliçesi ödemeyi kapsıyor mu ve önceden bildirim istiyor mu, adli makamlarla temas kuruldu mu, ödeme sonrası veri geri gelmezse B planı ne? Bu soruların cevabı olay anında değil, olaydan önce hazırlanan bir karar ağacında olmalı. Pratikte en sık yapılan hata, ödeme kararını teknik ekibin "başka çare yok" değerlendirmesine bırakmak; oysa aynı ekip, kurtarma süresini ölçmemişse "çare yok" sonucuna varmak için yeterli bilgiye sahip değildir.

Bir de zaman baskısı var: fidye notları genelde 48 ile 96 saat arasında süre veriyor ve bu süre, kurtarma testinin yapılması için gereken süreden kısa. Bu yüzden plan, fidye senaryosunda ilk yapılacak işi net yazmalı: ödeme görüşmesini kimin yürüteceği (genelde dışarıdan bir müzakere uzmanı), kurtarma testinin paralel başlatılacağı, ve "süre doldu" baskısının karar sürecini sıkıştırmayacağı. Karar verilmeden önce kurtarma süresinin ölçülmüş olması, bu baskının tek panzehiri.

İletişim: sahip olmadığınız kanaldan konuşmayın

Olay anında iletişim altyapısı genellikle olayın içinde. Posta sunucusu etkilenmişse e-posta ile koordinasyon yürümez; kimlik sağlayıcı ele geçirilmişse kurumsal sohbet uygulaması da güvenilmez. Plan, kurumsal altyapıdan bağımsız bir yedek iletişim kanalı tanımlamalı: ayrı bir mesajlaşma grubu, telefonla arama ağacı, gerekiyorsa basit bir konferans köprüsü. Bu kanalın katılımcı listesi ve test tarihi de planda yazılı olmalı.

İlk 48 saatte söylenmemesi gereken üç cümle var: failin kim olduğu iddiası, kesin neden açıklaması ve "hiçbir veriye erişilmedi" cümlesi. Üçü de kanıtlanmadan söyleniyor ve sonradan geri alınması gerekiyor; geri alınan bir cümle, olayın kendisinden daha uzun konuşuluyor. Yerine kullanılacak dil daha sıkıcı ama savunulabilir: "inceleme sürüyor, doğrulanmış bilgiyi şu kanaldan paylaşacağız, etkilenmiş olabilecek kişilere doğrudan ulaşacağız."

Müşteri, düzenleyici ve basın için ayrı eşikler tanımlanmalı. Müşteriye bilgi verme eşiği genellikle hizmet etkisiyle, düzenleyiciye bildirim eşiği kişisel veri ve kritik hizmet tanımıyla, basına açıklama eşiği ise olayın kamuya yansıma ihtimaliyle ilgili. Bu üç eşiği tek bir "kriz toplantısı" altında birleştirmek, hem gereksiz erken açıklama hem de geç bildirim üretiyor.

Denetimde istenen madde listesi

Planın iyi olması yetmiyor; denetimde aranan şey, planın maddelerinin hangi kayda bağlandığı. Aşağıdaki tablo, en sık sorulan soruların karşılığını gösteriyor. Bu tabloyu planın eki olarak tutmak, denetim görüşmesini bir savunma değil, bir gösterim hâline getiriyor.

Talep	Kaynak	İstenen kanıt
Olay müdahale planı ve roller	ISO 27001 A.5.24, KVKK md.12	Onaylı plan sürümü, rol matrisi, iletişim listesi ve son gözden geçirme tarihi
Olay değerlendirme ve karar	ISO 27001 A.5.25	Şiddet tablosu, son on iki ayda alınmış sınıflandırma kararları
Müdahale kayıtları	ISO 27001 A.5.26	Olay kayıtları, zaman damgaları, kapanış ve kök neden notu
Öğrenme	ISO 27001 A.5.27	Tatbikat raporları, bulgu listesi, kapanan ve açık kalan aksiyonlar
Kanıt toplama	ISO 27001 A.5.28	Dışa aktarım prosedürü, hash kayıtları, erişim günlüğü
Olay bildirimi	7545 md.7/1(b)	İç bildirim prosedürü, bildirim yazışması, süre ölçümü
Kişisel veri ihlali bildirimi	6698 md.12(5), 2019/10	Bildirim formu, haberdar olma zamanı kaydı, gecikme gerekçesi

Bu tablodaki her satırın bir sahibi ve bir tarihi olmalı. Denetimde en sık duyulan cümle "bu bizde var" oluyor; sorulan soru ise "gösterin". Bu yüzden plan, kendisinin kanıtını üretecek şekilde tasarlanmalı: her tatbikat bir rapor, her olay bir kayıt, her bildirim bir yazışma bırakmalı.

Hukuka uygun dış yardım nerede devreye girer

Buraya kadar yazılanların hepsi, olay anında yapılacak işin önemli bir kısmının olaydan önce yapıldığını gösteriyor: yetki, sıra, saklama süresi, kurtarma süresi ve karar ağacı. Dışarıdan bir ekibin katkısı tam olarak bu boşluğu doldurduğunda değerli oluyor; yani planı yazmak, tatbikatı yürütmek, kanıt toplama prosedürünü bir kez gerçek veriyle çalıştırmak ve ölçülen süreleri raporlamak.

Böyle bir çalışma yazılı yetkiyle başlar ve savunma tarafında kalır: hangi sistemler kapsamda, hangi eylemler izinli, hangi veri toplanacak, ne zaman teslim edilecek. Saldırganın altyapısına yönelik hiçbir eylem bu kapsama girmez; inceleme, kurbanın kendi varlığındaki kanıtla sınırlıdır. Kişisel veri içeren incelemelerde aydınlatma ve gerekiyorsa açık rıza, veri işleyen sözleşmesi ve saklama süresi baştan yazılır.

Ölçüm tarafında beklenti gerçekçi tutulmalı: hiçbir plan olayı önlemez, hiçbir tedarikçi de olayın maliyetini sıfırlamaz. Ölçülebilir olan şey sürelerdir: fark etme süresi, izolasyon kararına kadar geçen süre, kanıt dışa aktarma süresi, kurtarma süresi ve bildirim süresi. Bu beş sayıyı ölçen bir kurum, planının işleyip işlemediğini tahmin etmek zorunda kalmaz. Olay müdahale desteği, planın kendisini ve bu beş ölçümü kapsayan bir çerçeve olarak değerlendirilmeli; hizmet kapsamını bu çerçeveyle karşılaştırmak doğru başlangıç.

Aynı ölçüm mantığı, olayın insan tarafında da geçerli. Bu rehberdeki plan, çalışanın şüpheli bir mesajı ne hızla bildirdiğine dayanıyor; bildirim kültürünün kurulmadığı bir kurumda teknik tespit süresi ne kadar iyi olursa olsun ilk saat kaybediliyor. Bu yüzden olay müdahale planı ile oltalama farkındalık programı birbirini tamamlayan iki belge olarak okunmalı. E-posta hesabı ele geçirilmiş bir olayın ilk saatini adım adım görmek için de BEC olayında ne yapılmalı rehberi bu planın sahadaki karşılığı.

Kısa özet

• Plan bir belge değil karar listesi: olayı kim ilan eder, kim komuta eder, kim neyi durdurabilir, hangi eşikte kime haber verilir.
• Türkiye'de iki saat işliyor: 7545 md.7/1(b) sayısal süre vermeden "gecikmeksizin" diyor, 6698 md.12(5) tarafında 2019/10 kararıyla 72 saatlik beklenti var; ikisi birbirinin yerine geçmiyor.
• Kanun süre vermediği için savunma kayıtla kuruluyor: 30 dakikada olay kaydı, 2 saatte kapsam, 4 saatte bildirim kararı, 24 saatte ilk bildirim.
• Şiddet sıfatla değil testle yazılır; "bilmiyoruz" cevabının varsayılanı bir üst seviye olmalı.
• İzolasyon elektrik kesmek değil; yetki, denenmiş bir erişim yoluyla birlikte anlam kazanıyor.
• Saklama süresi tespit süresinden kısaymış: 172 günlük tespit ile 90 günlük kimlik günlüğü arasında 82 günlük kanıt boşluğu kalıyor.
• Kurtarma hedefi aritmetikle sınanmalı: 12 TB için 4 saatlik hedef yaklaşık 916 MB/s toplam verim istiyor, tek akışta bu 13,98 saat demek.
• Tatbikat senaryoyu değil varsayımı kaldırmalı ve karar sürelerini ölçmeli; bulguların sahibi ve kapanış tarihi olmalı.
• Dış yardım sözleşmeyle başlar; kritik altyapıda 7545 md.7/1(c) yetkilendirmesi, kişisel veride 6698 md.9 aktarım rejimi devreye girer.