Siber sigorta poliçesi almak için ERP'nin karşılaması gereken güvenlik şartları

Bir işletmenin siber sigorta başvurusu genellikle basit bir formla başlar: çalışan sayısı, sektör, yıllık ciro. Ama formun ikinci sayfasına geçildiğinde sorular değişir — çok faktörlü kimlik doğrulama var mı, yedekleme ne sıklıkla alınıyor, kim hangi veriye erişebiliyor, son oniki ayda bağımsız bir güvenlik denetimi yaptırıldı mı. Bu soruların büyük kısmının cevabı işletmenin güvenlik duvarında değil; finans, stok, müşteri ve tedarikçi verisinin toplandığı tek sistemde, yani ERP'de saklı.

Türkiye'de siber sigorta ürünleri son yıllarda hem bankalar hem sigorta şirketleri tarafından KOBİ segmentine yaygınlaştırıldı. Ama poliçe almak tek başına yeterli değil: teminatın fiilen devreye girmesi, başvuru sırasında beyan edilen güvenlik seviyesinin gerçekten sağlanmış olmasına bağlı. Bir işletme "düzenli yedekleme alıyoruz" dediği hâlde olay anında güncel ve çalışan bir yedek çıkaramıyorsa, hasar tazminatı tartışmalı hâle gelebilir. Bu yazı, poliçe başvurusunda ve sonrasında sigortacının aradığı güvenlik şartlarının ERP tarafındaki karşılığını tarafsız biçimde ele alıyor.

Sigortacı neden ERP'ye kadar soruyor

Siber sigorta, klasik yangın ya da deprem sigortasından farklı bir mantıkla çalışır: risk büyük ölçüde sigortalının kendi disiplinine bağlı. Bir sigorta şirketi teminatı fiyatlarken şu sorunun cevabını arar: bu işletmede bir saldırı olursa kayıp ne kadar büyür, işletme ne kadar hızlı geri döner? ERP işletmenin en kritik ve en çok veri barındıran sistemi olduğu için bu sorunun cevabı büyük ölçüde ERP'nin güvenlik mimarisinden geçiyor.

Sigorta şirketlerinin başvuru formlarında ve hasar sonrası incelemede tipik olarak aradığı asgari seviyeye sektörde "siber hijyen" deniyor: güncel uç nokta koruması, aktif bir güvenlik duvarı ve düzenli — çoğu üründe en az aylık — yedekleme. Bu üç şart genel BT altyapısına ait gibi görünse de, işletme verisinin neredeyse tamamı ERP'de tutulduğu için yedekleme politikası, erişim kayıtları ve kurtarma süresi pratikte ERP'nin kendisiyle birlikte değerlendiriliyor. Bazı sigorta ürünlerinde yıllık yenileme öncesi güncel bir öz-değerlendirme anketi ya da bağımsız denetim raporu isteniyor; düzenli denetim yaptıran işletmelerin bazı ürünlerde daha uygun prim aldığı gözlemleniyor, ama kesin oran sigorta şirketine ve sektöre göre değişir — net rakam için sigorta acentesinden teklif almak gerekir.

ERP'de karşılanması gereken beş şart

Poliçe başvurusunda ve olay sonrası hasar değerlendirmesinde tekrar eden beş başlık var. Bunların hiçbiri "ekstra" bir güvenlik yatırımı değil; büyük çoğunluğu modern bir ERP'nin zaten sunması gereken temel yapı taşları.

Bu beş başlığın ortak noktası, hiçbirinin tek seferlik bir kurulumla bitmemesi. MFA bir kez açılıp unutulabilir ama yeni kullanıcı eklendiğinde atlanabilir; yedekleme kurulabilir ama geri yükleme hiç test edilmemiş olabilir. Sigorta şirketlerinin sorduğu sorular da tam bu sürekliliği ölçmeye çalışıyor — kurulum anındaki durumu değil, bir yıl sonraki fiili durumu.

Beyan ile gerçek arasındaki fark neden önemli

Sigorta hukukunun genel ilkesi gereği, başvuru formunda verilen bilgi ile hasar anındaki fiili durum arasında ciddi bir fark varsa, tazminat kısmen ya da tamamen reddedilebilir. Bu, siber sigortada özellikle riskli bir nokta: başvuru formunu çoğu zaman BT'den ya da ERP'den sorumlu ekip değil, genel müdürlük ya da satın alma tarafı dolduruyor. "MFA var mı?" sorusuna "var" cevabı verilirken, bunun yalnızca birkaç yönetici hesabında açık olduğu, çoğu kullanıcının hâlâ tek şifreyle giriş yaptığı gözden kaçabiliyor.

Bu riski azaltmanın yolu, poliçe başvurusunu ERP'yi günlük olarak yöneten ekiple birlikte doldurmak ve beyan edilen her maddeyi ERP'de gerçekten kontrol ederek yazmaktır. Bir madde belirsizse "var" ya da "yok" yerine gerçek durumu tarif etmek, hem daha doğru bir teminat hem de hasar anında daha az tartışmalı bir süreç sağlar.

Pratikte bu genellikle üç kişinin masaya oturmasını gerektirir: poliçeyi değerlendiren mali işler ya da genel müdürlük, ERP'yi işleten BT sorumlusu ve varsa dışarıdan destek veren ERP vendor'ü ya da danışman. Bu üçlünün ayrı ayrı doldurduğu formlar genelde tutarsız çıkıyor; birlikte doldurulan form ise hem daha gerçekçi hem de sigorta şirketi nezdinde daha güvenilir kabul ediliyor.

Bulut ERP mi, şirket içi kurulum mu: sigortacı gözünden fark

Bulut (SaaS) ile şirket içi kurulum ERP arasındaki fark, sigorta başvurusunda da kendini gösteriyor. Bulut ERP'de altyapı güvenliğinin — sunucu yaması, fiziksel erişim, ağ güvenliği — büyük kısmı vendor'un sorumluluğunda; işletmenin sorumluluğu kullanıcı yönetimi, MFA zorunluluğu ve erişim politikasıyla sınırlı kalıyor. Şirket içi kurulumda ise bu sorumluluğun tamamı işletmenin kendi BT ekibinde, ki bu da sigortacının soracağı soru sayısını artırıyor: yama takvimi net mi, sunucu odası fiziksel olarak korunuyor mu, yedekler farklı bir lokasyonda mı tutuluyor.

Bu, bulut ERP'nin otomatik olarak daha ucuz sigortalandığı anlamına gelmiyor — sigorta şirketi her iki modelde de kendi kriterlerini soracak. Ama bulut modelde işletmenin tek başına cevaplaması gereken soru sayısı görece azalıyor, çünkü bir kısmı vendor'un sözleşmesinde ve sertifikasyonunda (ISO 27001 gibi) zaten karşılanmış oluyor. Şirket içi kurulumu tercih eden işletmeler için bu, ek bir yük değil; sadece sorumluluğun nerede durduğunu netleştirmesi gereken bir başlık.

Sektöre göre değişen eşik

Siber sigorta şartları her işletme için aynı katılıkta uygulanmıyor. Finans sektöründeki kuruluşlar için BDDK gözetimi zaten düzenli bilgi sistemleri denetimini ve sızma testini mevzuat gereği zorunlu kılıyor; bu kuruluşlar sigorta başvurusuna genelde hazır bir denetim dosyasıyla giriyor. Holding yapılarında çoklu şirket arasındaki veri izolasyonu ayrı bir soru başlığı oluyor — bir grup şirketindeki ihlalin diğerine sıçramaması sigortacının önem verdiği bir kriter. Üretim işletmelerinde ise MRP ve tedarik zinciri verisinin bütünlüğü öne çıkıyor, çünkü üretimin durması doğrudan ölçülebilir bir operasyonel kayıp anlamına geliyor.

Lojistik ve e-ticaret gibi anlık işlem hacmi yüksek işletmelerde ise farklı bir eşik öne çıkıyor: sistem kısa süreli de olsa durduğunda kayıp hızla katlanıyor, bu yüzden sigortacılar kurtarma süresine (RTO) e-ticaret/lojistik başvurularında daha fazla ağırlık veriyor. Bu, "hangi sektörde daha az güvenlik yeterli" demek değil; her sektörün kendi kırılgan noktasının sigorta değerlendirmesinde öne çıktığı anlamına geliyor.

Bu fark, ERP seçiminde güvenlik özelliklerinin fiyat ya da modül zenginliği kadar önemli bir kriter olduğunu gösteriyor — özellikle denetime tabi sektörlerde ERP değişikliği düşünen işletmeler için. ERP güvenliği ve fidye yazılımı riskine dair yazımızda ele aldığımız gibi, saldırı senaryosu gerçekleştiğinde en çok zaman kaybettiren şey, hangi verinin ne zaman ve nereden geri yüklenebileceğinin belirsiz olmasıdır — bu belirsizlik hem operasyonel hem de sigorta sürecini uzatıyor.

Poliçe öncesi kısa hazırlık listesi

Sigorta başvurusundan önce ERP tarafında gözden geçirilecek noktalar:

1. Kritik ERP modüllerine girişte MFA zorunlu mu, yoksa opsiyonel mi?
2. Son yedek geri yükleme testi ne zaman yapıldı — "yedek alınıyor" ile "yedekten fiilen dönülebiliyor" farklı şeylerdir.
3. İşten ayrılan personelin ERP erişimi ne kadar sürede kapatılıyor?
4. Denetim izi kayıtları değiştirilebiliyor mu, yoksa salt-okunur mu tutuluyor?
5. ERP vendor'ünün güvenlik sertifikaları (ISO 27001 gibi) ve son sızma testi tarihi elde mevcut mu?

Bu listeyi netleştirmek yalnızca daha uygun bir poliçe fiyatı için değil, olay anında tazminatın tartışmasız ödenmesi için de gerekli. ERP değişikliği ya da ilk kurulum aşamasındaki işletmeler için bu güvenlik kriterleri, karar sürecine erken dahil edilmesi gereken bir başlık — sonradan eklenecek bir özellik değil, seçim aşamasında sorulması gereken bir soru seti. Uygun ERP bul aracıyla ihtiyaç profili tanımlanırken güvenlik ve uyum gereksinimlerinin de belirtilmesi, kısa listeye giren ürünlerin bu başlıkta gerçekten karşılaştırılabilmesini sağlıyor.