Fidye yazılımı kurtarma ve MSP müşteri kaybı

Fidye yazılımı kurtarma işlemi teknik olarak başarıyla bitse bile yönetilen hizmet sağlayıcıların (MSP) müşteri ilişkisi risk altında kalabiliyor. Sistemler geri gelmiş olsa da müşteri, bilgilendirmenin neden iki gün boyunca durduğunu soruyor. Kaseya'nın 2026 Cybersecurity Outlook raporuna göre MSP'lerin yüzde 12'si, güvenlik olaylarının ardından müşteri kaybetti.

Senaryo tanıdık. Veriler geri yüklenmiş, sistemler çalışıyor, operasyon yoluna girmiş. Ama müşteri kurtarma maliyetinin neden yükseldiğini öğrenmek istiyor. Faturadaki 31 saatlik acil mesainin nereden çıktığını da soruyor.

Fidye yazılımı kurtarma süreleri

Yedeği ve müdahale planı olan ekipler için bile toparlanma günler sürebiliyor. Sektör raporlarına göre saldırıya uğrayan kuruluşların yalnızca yüzde 16'sı bir gün içinde tamamen toparlandı. Yüzde 55'i ise bir hafta içinde normale döndü.

Müşteri hizmet verebilmek ve gelir elde etmek için sistemlerine bağlı. Bu yüzden her ek gün bir maliyet demek. Normale ne zaman döneceğini bilmeyen ya da faturada beklemediği kalemler gören müşteri, sağlayıcının durumu kontrol edip etmediğini sorgulamaya başlıyor.

Aynı raporda müşteri kaybının başlıca nedenleri fidye yazılımı, hesap ele geçirme ve iş e-postası ihlali (BEC) olarak sıralanıyor. Müşteriler saldırıların yaşanacağını zaten biliyor. Beklentileri, MSP'nin hızlı yanıt vermesi, kurtarmayı koordine etmesi ve kendilerini bilgilendirmesi.

Süreç nerede aksıyor

Çoğu MSP'de yetenekli insanlar var. Sorun, bu insanların kriz anında birbirinden kopuk araçlarla çalışmasıyla başlıyor.

• Araç dağınıklığı: Yedekleme, izleme, bilet ve faturalama ayrı konsollarda duruyor. Teknisyenler sistemleri onarmak yerine bağlam toplamaya vakit harcıyor.
• Kopan devirler: Bir araçta alarm çalıyor, başka birinde bilet açılıyor, üçüncüsünde geri yükleme başlıyor. Aralarında bağ olmadığı için saldırının nelere dokunduğu ve nelerin hala kapalı olduğu net söylenemiyor.
• Faturalama boşluğu: Acil mesai, geri yükleme süresi ve mesai dışı çalışma çoğu zaman kayda geçmiyor. Saatler günler sonra hafızadan çıkarılıyor. Ya marj kaybediliyor ya da müşterinin tanımadığı bir fatura gidiyor.
• Dağınık iletişim: Tek bir bilet kaydı yoksa bilgilendirme, boş vakti olan kişiye kalıyor. Kimi müşteri birkaç saatte bir aranıyor, kimi iş bitene kadar ses duymuyor.

Müşterinin güncelleme için MSP'nin peşinden koşması, faturada açıklanmamış acil mesai kalemleri görmesi ve olayın sonunda neyin yaşandığına dair net cevap bulamaması, sürecin aksadığını gösteren işaretler.

Ölçülecek üç süre

İyi işleyen bir fidye yazılımı kurtarma süreci tek bir zaman çizelgesi ve tek bir veri kaynağı üzerinden yürüyor. Ekipteki herkes aynı bilgiyi görüyor, böylece müşteri kimi ararsa aynı hikayeyi duyuyor. Güncellemeler müşteri sormadan, önceden belirlenen düzende gidiyor. Olay kapandığında fatura yapılan işle örtüşüyor, çünkü iş yapılırken kayda geçiyor.

Sürecin durumunu üç süreyle ölçmek mümkün:

• İlk müşteri güncellemesine kadar geçen süre: Tespitten ne kadar sonra müşteriye haber veriliyor?
• Geri yükleme süresi: Kritik sistemler ne zaman yeniden çalışıyor?
• Faturalama süresi: Olay kapandıktan sonra doğru fatura ne kadar hızlı gönderiliyor?

Bunlardan biri uzuyorsa müşterinin fark edeceği bir süreç açığı var demektir. Bu açıkları kapatmak, olay sırasında daha çok çalışmaktan fazlasını gerektiriyor. Verinin baştan paylaşıldığı araçlara ihtiyaç var.

Kaseya'nın 2026 raporu da bunu destekliyor. Olay sonrası toparlanmayı hızlandıran iki etken öne çıkıyor: iyi eğitilmiş iç BT ya da güvenlik ekipleri (yüzde 35) ve entegre güvenlik ile BT yönetim araçları (yüzde 18).