SaaS hizmeti kesilirse müşterinin zararını kim öder? SLA, veri kaybı ve çıkış hakları

Kısa cevap

Sunucular iki saat erişilemedi. Müşteri o sırada satış yapamadığını, çalışanlarının beklediğini ve sipariş kaybettiğini söylüyor. Yazılım şirketi ise “Bulut sağlayıcısı çöktü, bizim hatamız değil; zaten sözleşmede bir aylık ücret kadar sorumluyuz” cevabını veriyor. Bu cevap tek başına uyuşmazlığı çözmez.

Kısa cevap: Kesintinin yaşanması müşterinin ileri sürdüğü her zararın otomatik ödeneceği anlamına gelmez. Ancak üçüncü kişiden sunucu hizmeti almak veya sözleşmeye sorumluluk sınırı yazmak da SaaS şirketini her durumda sorumluluktan kurtarmaz. Önce müşteriye hangi hizmetin taahhüt edildiği, bunun ihlal edilip edilmediği, zarar ile kesinti arasındaki bağlantı ve sınırlandırma hükmünün geçerliliği belirlenir.

Bu yazı özellikle şirketlere yazılım hizmeti sunan B2B SaaS işletmeleri ve bu hizmeti satın alan şirketler içindir. B2B, iki işletme arasındaki ilişkiyi ifade eder. Tüketiciye sunulan uygulamalarda tüketici hukukunun emredici korumaları ayrıca geçerlidir; kurumsal müşteri sözleşmesi doğrudan tüketiciye kopyalanmamalıdır.

SLA nedir? Yalnız “yüzde 99,9 çalışır” yazmak yeterli mi?

SLA, hizmet seviyesi anlaşmasının İngilizce kısaltmasıdır. Hizmetin hangi düzeyde sağlanacağını ve bu düzeyin altına düşüldüğünde ne olacağını açıklar. Erişilebilirlik oranı, destek, müdahale ve telafi koşulları burada düzenlenebilir. Ana sözleşme bütün ticari ilişkiyi; SLA ise bunun ölçülebilir hizmet tarafını ele alır.

Yüzde 99,9 ifadesi ancak nasıl ölçüldüğü belli olduğunda anlamlıdır. Otuz günlük bir ayın tamamı hesaba katılırsa yüzde 0,1 yaklaşık 43 dakika 12 saniyeye karşılık gelir. Fakat bu sadece matematik örneğidir. Sözleşme çalışma saatlerini esas alabilir, belli bakım sürelerini dışarıda bırakabilir veya erişilememe hâlini farklı tanımlayabilir.

Müşterinin giriş yapabilmesi fakat ödeme alamaması hizmetin çalıştığı anlamına mı gelir? API yanıt veriyor ama işlemler dakikalarca sürüyorsa kesinti var mıdır? Sorun yalnız bir müşteriyi etkiliyorsa bütün sistem ortalaması mı kullanılacaktır? Bu sorular cevaplanmadan oran üzerinde anlaşmak yanıltıcı olabilir.

Örneğin satışların işlendiği hizmet için “ana sayfaya erişilebilmesi” ölçütü çok dar kalabilir. Müşteri, iş açısından kritik işlemlerin kapsama alınmasını ister. Sağlayıcı ise kontrolü dışındaki müşteri interneti, yanlış entegrasyon veya izinsiz kullanım gibi durumların sınırlarını açıklar. İstisnalar hizmet taahhüdünü fiilen boşaltacak kadar geniş yazılmamalıdır.

Müşteri kesinti yaşadı diye bütün kâr kaybını isteyebilir mi?

Talepte bulunabilir; ancak istenen tutarın haklılığı ayrıca belirlenir. Türk Borçlar Kanunu m.112, borcun hiç veya gereği gibi ifa edilmemesi hâlinde borçlunun kusursuzluğunu ispat etmedikçe bundan doğan zararı giderme yükümlülüğünü düzenler. Sözleşmeye aykırılık, zarar ve uygun bağlantı gibi konular somut olayda incelenir. Müşterinin söylediği ciro kaybı, doğrudan aynı tutarda tazminat demek değildir. TBK, m.112 ve 114

Müşteri “Bu iki saatte bir milyon liralık satış yapacaktım” diyorsa sipariş geçmişi, kesilen işlemler, kampanya koşulları ve ertelenen satışların sonradan gerçekleşip gerçekleşmediği önem kazanır. Ciro, kâr ve yapılmayan giderler birbirine karıştırılmamalıdır. Kesintiyle ilgisiz düşüşler de aynı talebe eklenemez.

Sağlayıcı bakımından da yalnız “müşteri ispatlasın” demek yeterli savunma hazırlığı değildir. Taahhüt edilen hizmetin sağlandığı, sorunun müşteri entegrasyonundan kaynaklandığı veya kusur yüklenemeyeceği ileri sürülüyorsa bunu destekleyen teknik bilgiler gerekir. Karşılıklı loglar, yani sistemin olay kayıtları, aynı zaman diliminde karşılaştırılmalıdır.

Zararı artırmamak için makul önlemler de önemlidir. Kullanılabilir bir alternatif yolu bilerek kullanmayan müşteri ile gerçekten hiçbir seçeneği olmayan müşteri aynı durumda değildir. Bununla birlikte sağlayıcı, sözleşmede üstlendiği işi sonradan “müşteri ayrıca yedek sistem kurmalıydı” diyerek bütünüyle müşteriye yükleyemez.

“En fazla son bir aylık ücret kadar sorumluyuz” maddesi geçerli mi?

B2B sözleşmelerde sorumluluğu belirli bir tutarla sınırlandırmak mümkündür; fakat her sınır her olayda geçerli değildir. Özellikle TBK m.115 uyarınca borçlunun ağır kusurundan sorumlu olmayacağına ilişkin önceden yapılan anlaşma kesin hükümsüzdür. Çok düşük bir tavanın somut olayda sorumsuzluk anlaşması niteliği taşıyıp taşımadığı da değerlendirilir. “Taraflar şirket, istedikleri her sınırlamayı yapabilirler” yaklaşımı doğru değildir.

Standart sözleşmede yer alan madde ayrıca genel işlem koşulları denetimine tabi olabilir. Kullanıcıya koşulları öğrenme imkânı sağlanması, belirsiz ifadelerin yorumu ve dürüstlük kuralına aykırı hükümler TBK m.20-25 kapsamında önem taşır. Metne “bütün maddeler tek tek müzakere edildi” yazmak, gerçekte standart hükmün niteliğini kendiliğinden değiştirmez. TBK, m.20-25 ve 115

Müzakerede önce tavanın neyi kapsadığını sorun. Tek olay mı, bütün sözleşme dönemi mi? Hizmet bedelinin hangi kısmı esas alınacak? Gizlilik ihlali, veri kaybı, üçüncü kişi fikrî hak iddiası ve kasıtlı davranış aynı sınıra mı tabi? Hizmet kredisi bu tutardan düşülecek mi? Cevaplar anlaşılmadan yalnız “bir aylık ücret” üzerinde pazarlık etmek yetersizdir.

Şirketin bütün müşterilerine sınırsız sorumluluk vermesi de kendiliğinden iyi çözüm değildir. Taahhüt, ürünün kullanım amacı, teknik kapasite, bedel ve varsa sigortanın gerçek kapsamıyla birlikte belirlenmelidir. Sigorta poliçesinin bulunması, her sözleşmesel taahhüdün sigortalandığını göstermez.

Hizmet kredisi verince tazminat konusu kapanır mı?

Hizmet kredisi, çoğunlukla ilerideki faturalardan düşülen tutar veya ek kullanım hakkıdır. Nakit iade ve tazminatla aynı şey değildir. SLA, erişilebilirlik hedefinin kaçırılması hâlinde krediyi özel telafi olarak düzenleyebilir. Bunun başka talepleri ne ölçüde sınırlandırdığı; metnin kapsamı, geçerliliği ve olayın niteliğine bağlıdır.

Örneğin müşteriye bir sonraki ay yüzde 10 indirim verilmesi, kaybolan veriyi geri getirmez. Müşteri hizmeti bırakıyorsa yalnız gelecekte kullanılabilecek kredi pratikte yararsız kalabilir. Tekrarlayan ağır kesintiler için fesih ve kullanılmayan peşin bedelin durumu, tek kesintiye ilişkin kredi hesabından ayrı konuşulmalıdır.

Sağlayıcı açısından kredi koşulları anlaşılır olmalıdır: Hangi hizmet bedeli üzerinden hesaplanır, talep gerekir mi, hangi kayıtlar sunulur, üst sınır nedir? Çok kısa veya fiilen yerine getirilemez başvuru koşulları koymak uyuşmazlığı azaltmak yerine büyütebilir. Müşteri bakımından ise olaydan sonra SLA'daki başvuru süresini kaçırmamak önemlidir; bu süreyle kanuni talep süreleri aynı değildir.

AWS veya Google kesildiyse sorumluluk onlarda değil mi?

Müşterinizle sözleşmeyi siz yaptıysanız bulut sağlayıcınızla ilişkiniz, müşteriye karşı borcunuzu otomatik ortadan kaldırmaz. TBK m.116'daki yardımcı kişilerin fiillerinden sorumluluk ve geçerli sözleşme düzeni de olayda önem taşıyabilir. Bulut sağlayıcısının kusuru, sizin altyapı tasarımınız ve müşteriye verdiğiniz taahhüt birlikte değerlendirilir.

Bulut sağlayıcınızın sunduğu telafi de sizin müşteriye vaat ettiğiniz telafiyle aynı olmayabilir. Örneğin Amazon Compute SLA ve Google Compute Engine SLA, belirli koşullarda hizmet kredisi öngörür; kapsam, ölçüm, istisna ve başvuru şartlarını ayrıca tanımlar. Bu metinler, müşterinizin bütün ticari kayıplarının size geri ödeneceği yönünde genel garanti değildir. Amazon Compute SLA, Google Compute Engine SLA

Basit bir örnek: Siz müşteriye kesintisiz ödeme işleme ve yüksek tazminat taahhüt ettiniz; altyapı sağlayıcınız ise yalnız ilgili sunucu bedelinin belli kısmını kredi olarak veriyor. Aradaki risk sizde kalabilir. Çözüm, müşteriye bulut sağlayıcısının sözleşmesini kopyalamak değil; kendi hizmetinizi, teknik dayanıklılığınızı ve verebileceğiniz telafiyi uyumlu kurmaktır.

Aynı sağlayıcının farklı hizmetleri ve kurulum biçimleri farklı SLA koşullarına tabi olabilir. Bir ürüne ait erişilebilirlik oranı bütün bulut hesabı için geçerliymiş gibi kullanılmamalıdır.

Siber saldırı her zaman mücbir sebep sayılır mı?

Hayır. Mücbir sebep, tarafın kontrolü dışındaki her sorun için otomatik etiket değildir. Olayın özellikleri, öngörülebilirlik, önlenebilirlik, alınması gereken tedbirler ve sözleşmedeki risk dağılımı değerlendirilir. Bilinen bir açığın giderilmemesi veya yedeklerin hiç test edilmemesi gibi durumlar varken yalnız “saldırgan yaptı” demek sorumluluğu çözmez.

Diğer yandan gerekli tedbirler alınmış olsa da bütün saldırıların önlenebileceği söylenemez. Tazminat sorumluluğu, hizmet borcu, geçici kesinti ve imkânsızlık farklı konulardır. TBK m.136'daki kusursuz ifa imkânsızlığı, her geçici bulut kesintisinin sözleşmeyi sona erdirdiği anlamına gelmez. TBK, m.112, 115 ve 136

Sözleşmede saldırı veya altyapı arızası sayılmış olsa bile olay bildirimi, zararı azaltma ve hizmeti geri getirme çabası önemini korur. Teknik inceleme sonuçlanmadan “hiç kusurumuz yok” açıklaması yapmak yerine, doğrulanan etkileri ve alınan önlemleri açıklamak daha sağlıklı olur.

“Yedek alıyoruz” sözü veri kaybını karşılıyor mu?

Yedeğin varlığı kadar ne kadar güncel olduğu ve geri yüklenip yüklenemediği önemlidir. Her gece yedeklenen sistemde gün içindeki işlemler kaybolabilir. Ana sistemle anlık eşitlenen bir kopya ise yanlış silmeyi de kopyalayabilir. Müşterinin “yedek” sözcüğünden anladığı ile sağlayıcının yaptığı iş aynı olmayabilir.

İki teknik terimi sadeleştirmek yararlıdır. RPO, olaydan sonra ne kadar geriye dönük veri kaybının hedeflenen sınır içinde kabul edildiğini anlatır. RTO, hizmetin ne kadar sürede geri getirilmeye çalışılacağını ifade eden kurtarma süresi hedefidir. Bunlar sözleşmede hedef mi, bağlayıcı taahhüt mü, hangi koşullarda geçerli mi açık olmalıdır; tek başlarına kesintisizlik garantisi değildir.

Müşteri açısından “en son başarılı geri yükleme testi ne zaman yapıldı?” sorusu, sadece “yedek var mı?” sorusundan daha anlamlıdır. Sağlayıcı açısından da müşterinin kendi verisini dışarı alma imkânı, saklama süresi, yedek kapsamına girmeyen dosyalar ve kurtarma maliyeti açıklaştırılmalıdır.

Olay yönetiminin hazırlık, tespit, müdahale ve toparlanma boyutları teknik olarak birlikte ele alınmalıdır. NIST'in 2025 tarihli olay müdahalesi rehberi bu konuda bir teknik referanstır; Türkiye'deki şirketler için tek başına kanuni uygunluk belgesi veya zorunlu sözleşme şablonu değildir. NIST SP 800-61 Rev.3

Kesinti oldu. KVKK'ya her durumda 72 saat içinde bildirim mi gerekir?

Her hizmet kesintisini otomatik olarak aynı bildirim yükümlülüğüne bağlamak doğru değildir. Önce kişisel verilerle ilgili ne olduğu belirlenmelidir. KVKK bakımından işlenen kişisel verilerin kanuni olmayan yollarla başkalarınca elde edilmesi hâlindeki bildirim düzeni ile sıradan performans sorunu aynı şey değildir. Erişilebilirlik kaybı ve güvenlik tedbirleri yine ayrıca değerlendirilir.

Kurulun 2019/10 sayılı kararına göre veri sorumlusu, bu kapsamdaki ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat içinde Kurula bildirir. Etkilenen kişilere bildirim ise kişiler belirlendikten sonra makul olan en kısa sürede yapılır. Veri işleyen de veri sorumlusuna gecikmeksizin haber vermelidir. Bilgiler tamamlanamıyorsa karar aşamalı bildirim imkânını düzenler; bütün teknik incelemenin bitmesini beklemek güvenli bir varsayım değildir. KVKK, 2019/10 sayılı karar

Bildirim konusu yalnız KVKK'dan ibaret değildir. 7545 sayılı Siber Güvenlik Kanunu m.7, kapsamdaki hizmet sunan ve veri işleyenlerin hizmet alanlarında tespit ettikleri zafiyet veya siber olayları gecikmeksizin Siber Güvenlik Başkanlığına bildirmesini düzenler. Kanunun kapsamı, olay tanımı, güncel uygulama usulleri ve varsa sektör yükümlülükleri ayrıca dikkate alınır. KVKK'daki 72 saat, bütün siber bildirimler için ortak bekleme süresi değildir. 7545 sayılı Kanun, m.2, 3 ve 7

Üç saatlik kesintide aynı olay neden farklı sonuçlar doğurabilir?

Varsayımsal olarak bir stok yazılımında üç saat kesinti yaşandığını düşünelim. İlk müşterinin sözleşmesi yalnız iş saatlerinde destek içeriyor; hizmet seviyesi ve telafi koşulları açık. İkinci müşteriye ise satış öncesi yazışmalarda gece de kesintisiz operasyon ve anında müdahale vaat edilmiş. Sağlayıcının standart metnini iki müşteriye de göndermesi, farklı taahhütleri kendiliğinden aynılaştırmaz.

İlk müşteri için SLA kredisi koşulları oluşmuş olabilir. İkinci müşteride ayrıca özel taahhüdün ihlali ve bundan doğan zarar tartışılabilir. Hangi belgenin öncelikli olduğu, teklifin sözleşmeye dahil olup olmadığı ve tarafların gerçek anlaşması incelenir. Satış e-postasındaki “asla durmaz” cümlesi teknik ekibin verebildiği hizmetten daha geniş beklenti yaratabilir.

Çözüm yalnız geriye dönük kredi hesaplamak değildir. Sağlayıcı özel taahhüdü yerine getirecek teknik yapıyı kurabilir, müşteriyle ileriye dönük kapsamı yeniden anlaşabilir veya uygun sona erme ve geçiş koşullarını görüşebilir. Eski sorumluluğu tek taraflı yeni koşul yayımlayarak kaldırdığı varsayılmamalıdır.

Müşteri hesabı kapattı; verilerini vermem gerekiyor mu?

Sözleşme sona erince müşterinin kendi iş kayıtlarına nasıl erişeceği başlangıçta belirlenmelidir. Veriyi dışarı aktarma hakkı, dosya biçimi, kapsam, süre, ücretli geçiş desteği ve sonrasında silme düzeni açıklanabilir. Kişisel veriler söz konusu olduğunda KVKK yükümlülükleri de devam eder. “Veri bizim sunucumuzda, o hâlde istediğimiz gibi tutarız” yaklaşımı doğru değildir.

İkinci varsayımsal örnekte müşteri altı aylık bedeli peşin ödemiş, tekrarlayan kesintiler nedeniyle hizmetten çıkmak istiyor. Sadece “CSV indirebilir” denmesi yeterli olmayabilir: Ekli belgeler, işlem ilişkileri ve gerekli açıklamalar aktarım dışında kalıyorsa müşteri fiilen işini taşıyamaz. Hangi verinin hangi biçimde verileceği somutlaştırılmalıdır.

Peşin ücretin kalan kısmı, fesih sebebi ve sözleşmenin hükümlerine göre değerlendirilir. Sağlayıcı geçiş desteği için ayrıca ücret isteyebilecekse kapsamı önceden açık olmalıdır. Temel veri teslimini belirsiz ek ücrete veya keyfî onaya bağlamak uyuşmazlık yaratabilir. Ödeme anlaşmazlığı varsa veri erişimini baskı aracı yapmadan önce sözleşmesel ve kanuni sınırlar incelenmelidir.

Veri aktarımı tamamlandıktan sonra neyin silineceği ve hangi kaydın kanuni gerekçeyle tutulacağı ayrılır. Süresiz saklama veya bütün yedekleri aynı dakika içinde silme sözü, gerçek teknik ve hukuki duruma uymayabilir. Müşteriye uygulanabilir, açık ve doğru bilgi verilmelidir.

Sözleşmeyi imzalamadan önce hangi soruları sormalıyım?

SaaS şirketiyseniz şu cümleyi tamamlayın: “Bu özellik çalışmazsa müşteriye hangi çözümü, hangi koşullarda verebiliyoruz?” Müşteriyseniz karşılığını sorun: “İşimin durduğu anda bu sözleşme bana gerçekten ne sağlıyor?” Bu iki cevap aynı metinde buluşmalıdır.

En azından erişilemeyen hizmetin tanımı, ölçüm yöntemi, destek kapsamı, kredi veya iade koşulları, sorumluluk sınırı, yedekten dönüş ve veriyi çıkarma hakkı anlaşılır olmalıdır. Tekrarlayan kesintide çıkış imkânı ve geçişin nasıl yapılacağı da unutulmamalıdır. Büyük bir müşterinin her şartını kabul etmek de, sağlayıcının bütün riskleri dışlayan metnini okumadan onaylamak da sonradan çözümü zorlaştırır.

Sık sorulan sorular

Destek mesajına bir saat içinde dönmek, sorunu bir saatte çözmek midir?

Hayır. İlk yanıt, müdahaleye başlama, geçici çözüm ve kalıcı giderim farklı aşamalardır. Sözleşme bunları birbirine karıştırmamalıdır. “Bir saatte destek” gibi belirsiz ifade iki tarafta farklı beklenti yaratır.

Her bakım kesinti hesabının dışında bırakılabilir mi?

Bakım istisnasının kapsamı sözleşmede açık olmalıdır. Bildirim, zaman aralığı ve süre sınırı belirlenebilir. Sonradan her arızaya “bakım” adı verilmesi, sözleşmede üstlenilen hizmetin yerine getirildiğini göstermez.

Müşterimiz banka diye biz de otomatik olarak bütün bankacılık kurallarına mı tabi oluruz?

Müşterinin düzenlenen sektörde olması, her yükümlülüğü aynen size taşımaz. Ancak hizmetin niteliğine göre doğrudan hükümler, dış hizmet alımı kuralları ve sözleşmeyle üstlenilen yükümlülükler gündeme gelebilir. Sektörel kapsam ayrı belirlenmelidir.

Hizmet kredisi talebiyle tazminat talebi aynı süreye mi tabi?

Hayır. SLA'daki kredi başvuru şartı ile kanundan doğan dava veya bildirim süreleri farklı olabilir. Kredi talebinin kaçırılması, bütün hakların otomatik kaybı şeklinde genellenmemelidir; ilgili talep ayrı değerlendirilir.

Kesinti ve veri güvenliği boyutu için veri ihlalinde bildirim ve kayıt yükümlülüğü, hizmet ilişkisinin genel çerçevesi için teknoloji ve SaaS çalışma alanı incelenebilir.

Bu yazı genel bilgilendirme amacı taşır. Kesintinin teknik nedeni, sözleşmeler, zarar ve güncel mevzuat birlikte incelenmeden sorumluluk veya tazminat sonucu hakkında kesin değerlendirme yapılamaz.