SaaS Sözleşmesinde SLA, Kesinti, Veri İadesi ve Fesih Maddeleri

Kısa cevap: Kurumsal bir SaaS sözleşmesinde yalnız “yüzde 99,9 çalışma süresi” yazması yeterli değildir. Ölçüm yöntemi, planlı bakım, kesintinin başlangıcı, hizmet kredisi, kritik olay müdahalesi, fesih eşiği ve verinin hangi formatta geri verileceği açıkça düzenlenmelidir. Kesinti yaşandığında tazminat veya fesih hakkı; sözleşmenin niteliğine, sağlayıcının kusuruna, kararlaştırılan sorumluluk sınırına ve zararın ispatına göre belirlenir. Hizmet kredisi de açıkça münhasır çözüm olarak yazılmadıkça her uyuşmazlıkta diğer talepleri kendiliğinden ortadan kaldırmaz. En kritik koruma, hizmet sona ermeden önce çalışan bir veri çıkarma ve geçiş planına sahip olmaktır.

SaaS sözleşmesi hukuken nedir?

SaaS, yazılımın müşterinin cihazına kalıcı biçimde teslim edilmesinden çok, internet üzerinden belirli süreyle kullandırıldığı bir hizmet modelidir. Uygulamada lisans, barındırma, bakım, destek, veri işleme ve kimi zaman uyarlama edimleri aynı metinde birleşir. Bu nedenle her SaaS ilişkisini tek bir sözleşme tipine sokmak yerine, uyuşmazlığa konu edimin niteliği belirlenmelidir. Standart uygulamaya erişim sağlanması ile müşteriye özgü modül geliştirilmesinin hukuki değerlendirmesi aynı olmayabilir.

Taraflar tacirse Türk Ticaret Kanunu’nun basiretli iş insanı ölçüsü, ticari işlere ilişkin bildirim ve delil kuralları önem kazanır. Borcun hiç veya gereği gibi ifa edilmemesi bakımından Türk Borçlar Kanunu uygulanır. Kişisel veri işleniyorsa sözleşme serbestisi, 6698 sayılı Kanun’dan doğan emredici yükümlülükleri bertaraf etmez. Bu çok katmanlı yapı nedeniyle ana sözleşme, SLA, veri işleme eki, bilgi güvenliği eki ve çıkış planı birbiriyle çelişmeyecek biçimde hazırlanmalıdır.

Sözleşmeye aykırılığın genel sonuçları hakkında sözleşmeye aykırılık ve tazminat rehberi, SaaS uyuşmazlığındaki zarar kalemlerini sınıflandırırken tamamlayıcı bir çerçeve sunar.

SLA maddesi nasıl ölçülebilir yazılır?

“Yüksek erişilebilirlik sağlanır” ifadesi uyuşmazlık anında ölçü vermez. SLA; hizmetin hangi bileşenini, hangi zaman diliminde, hangi izleme aracıyla ve hangi formülle ölçtüğünü göstermelidir. Aylık erişilebilirlik hesabında toplam dakika, hariç tutulan süreler ve başarısız istek ölçütü tanımlanmalıdır. Müşterinin yalnız yönetim paneline girememesi ile bütün API’nin cevap vermemesi aynı önemde kabul edilmeyebilir.

Asgari SLA başlıkları

• Üretim, test ve üçüncü taraf entegrasyonlarının kapsamı,
• Kesintinin hangi saatte başlayıp bittiğini belirleyen kayıt kaynağı,
• Kritik, yüksek, orta ve düşük önem seviyelerinin nesnel tanımı,
• İlk cevap, geçici çözüm ve kalıcı giderim hedefleri,
• Planlı bakımın bildirim süresi ve aylık üst sınırı,
• Tekrarlayan kesintilerde artan yaptırım ve fesih eşiği,
• Müşterinin kredi talebi için başvuru usulü,
• Sağlayıcının olay sonrası kök neden raporu verme yükümlülüğü.

Ölçümün yalnız sağlayıcının paneline bırakılması delil dengesini bozar. Müşterinin bağımsız izleme kaydı ile sağlayıcı kaydı farklıysa hangi kaynağın esas alınacağı ve itirazın nasıl çözüleceği önceden yazılmalıdır. Saat dilimi, ayın başlangıcı ve yuvarlama yöntemi gibi küçük görünen ayrıntılar dahi kredi hesabını değiştirebilir.

Planlı bakım, arıza ve mücbir sebep nasıl ayrılır?

Her erişim sorunu SLA ihlali değildir; fakat her sorunu “bakım” veya “mücbir sebep” sayan bir metin de müşteriyi korumaz. Planlı bakımın önceden bildirilmesi, mümkünse düşük kullanım saatlerinde yapılması ve belirlenen aylık sınırı aşmaması gerekir. Acil güvenlik bakımı için daha kısa bildirim öngörülebilir; bu istisnanın rutin güncellemelerin saklandığı bir kapıya dönüşmemesi önemlidir.

Mücbir sebep hükmü, tarafın makul kontrolü dışındaki olayı ve sonuçlarını somutlaştırmalıdır. Sağlayıcının seçtiği alt hizmette kapasite yetersizliği, uzun süredir giderilmeyen yazılım açığı veya yedekleme eksikliği sırf üçüncü kişiden kaynaklandı diye otomatik olarak mücbir sebep sayılmaz. Etkilenen tarafın derhâl bildirim, zararı azaltma, alternatif hizmete geçme ve düzenli durum raporu yükümlülükleri de düzenlenmelidir.

Hizmet kredisi tazminatın yerine geçer mi?

Hizmet kredisi, belirli SLA seviyesinin altında kalındığında gelecek faturadan indirim yapılmasıdır. Hızlı ve hesaplanabilir bir telafi sağlar; ancak birkaç saatlik kesintinin müşteride oluşturduğu gerçek kaybı her zaman karşılamaz. Sözleşmede kredinin “tek ve münhasır çözüm” olduğu açıkça yazılmışsa sağlayıcı diğer talepleri sınırlamaya çalışabilir. Bu hükmün kapsamı ve müzakere edilip edilmediği ayrıca değerlendirilir. Türk Borçlar Kanunu uyarınca ağır kusurdan sorumlu olunmayacağına ilişkin önceden yapılan anlaşma kesin hükümsüzdür; sorumluluk tavanı veya münhasır çözüm maddesi bu emredici sınırı aşamaz.

Dengeli metinde hizmet kredisi, olağan ve düşük etkili SLA ihlallerinin pratik çözümü olabilir. Uzayan kritik kesinti, veri kaybı, gizlilik ihlali, fikrî hak ihlali veya kasıt ve ağır kusur gibi alanlar kredi ve genel sorumluluk tavanının dışında bırakılabilir. Zarar talebinde bulunan müşteri; ihlali, gerçekleşen zararı ve aradaki nedensellik bağını ispatlamak zorundadır. Türk Borçlar Kanunu’nun borca aykırılık sisteminde sağlayıcı ise kendisine hiçbir kusur yüklenemeyeceğini ileri sürüyorsa kusursuzluğunu ispatlamalıdır. Soyut ciro kaybı iddiası yerine iptal edilen sipariş, ek personel, alternatif sistem ve müşteri iadeleri gibi kalemler belgelenmelidir.

Veri güvenliği ve KVKK rolleri nasıl kurulmalı?

SaaS sağlayıcısı çoğu projede müşteri talimatıyla kişisel veri işler; fakat tarafların sözleşmede kullandığı sıfat tek başına gerçek rolü belirlemez. İşleme amaç ve vasıtalarını fiilen kimin belirlediği incelenir. Veri kategorileri, ilgili kişi grupları, saklama süresi, alt işleyenler, erişim yetkileri, şifreleme, günlük kayıtları ve olay bildirimi veri işleme ekinde gösterilmelidir.

Sağlayıcının alt yüklenici kullanması, müşteriye karşı sözleşmesel sorumluluğunu kendiliğinden kaldırmaz. Alt işleyene aynı güvenlik yükümlülüklerinin aktarılması, ülke ve veri merkezi değişikliğinin önceden bildirilmesi ve müşteriye haklı itiraz olanağı tanınması sözleşmesel iyi uygulama olarak düzenlenebilir; bunlar her durumda KVKK’da aynı ifadelerle yazılı bir izin kuralı değildir. Yurt dışına aktarım söz konusuysa 6698 sayılı Kanun’daki güncel aktarım mekanizması ayrıca kurulmalıdır; yalnız “müşteri onaylamıştır” cümlesi yeterli olmayabilir.

Veri iadesi, silme ve çıkış planı neleri içermeli?

Verinin müşteriye ait olduğunu yazmak başlangıçtır, fakat fiilî taşınabilirliği sağlamaz. Sözleşme sona erdiğinde hangi verinin, kaç gün içinde, hangi dosya ve şema formatında verileceği; eklerin, ilişki tablolarının, işlem geçmişinin ve denetim kayıtlarının pakete dâhil olup olmadığı belirtilmelidir. Yalnız PDF raporu verilmesi, yeni sisteme geçiş için yeterli olmayabilir.

Çıkış planı en az şu konuları kapsamalıdır:

1. Sözleşme sürerken periyodik ve makinece okunabilir dışa aktarım,
2. Fesih sonrasında salt okunur erişim dönemi,
3. API, alan sözlüğü ve veri modeline ilişkin teknik belge,
4. Geçiş desteğinin saat, ücret ve personel sınırı,
5. Yedeklerde kalan kopyaların silinme takvimi,
6. Yasal saklama zorunluluğu bulunan verilerin ayrıştırılması,
7. Silme tamamlandığında yetkili kişi imzalı teyit,
8. Uyuşmazlık halinde delil niteliğindeki kayıtların korunması.

Sağlayıcının ödeme ihtilafı nedeniyle bütün müşteri verisini süresiz alıkoyabileceğini belirten hüküm ciddi iş sürekliliği riski doğurur. Tartışmasız borç, tartışmalı borç, erişimin sınırlandırılması ve verinin iadesi birbirinden ayrılmalıdır.

Fesih hakkı ve geçiş dönemi nasıl düzenlenir?

Haklı nedenle derhâl fesih ile sebep göstermeden olağan fesih ayrı hükümlerdir. Tek bir kritik kesinti, belirli dönemde tekrarlanan SLA ihlali, güvenlik açığının giderilmemesi, veri kaybı veya mevzuata aykırı aktarım haklı fesih nedeni olarak somutlaştırılabilir. İhlalin giderilebilir olduğu durumlarda ihtar ve makul düzeltme süresi öngörülmesi, hangi ihlalde süre verilmeyeceğinin belirtilmesi uyuşmazlığı azaltır.

Olağan fesihte yenileme tarihinden önce bildirim süresi, kullanılmamış peşin ücretin iadesi ve minimum taahhüt sonuçları açık olmalıdır. Fesih anında sistemi birden kapatmak yerine, güvenlik riski yoksa sınırlı geçiş dönemi tanınabilir. Sağlayıcının çıkış yardımı bedeli önceden belirlenmeli veya nesnel bir hesap yöntemine bağlanmalıdır; belirsiz “güncel danışmanlık ücreti” ifadesi müşteriyi fiilen kilitleyebilir.

Bildirim, zamanaşımı ve dava öncesi yol

Kesinti yaşandığında destek kaydı açmakla yetinilmemeli; sözleşmedeki bildirim kanalına, süreye ve yetkili kişiye uygun yazılı ihbar yapılmalıdır. Hizmet kredisi için kısa başvuru penceresi öngörülmüş olabilir. Bu süre ile kanuni dava zamanaşımı aynı değildir. Kredi talebinin kaçırılması, somut sözleşmeye göre genel tazminat talebini otomatik olarak düşürmeyebilir.

Sözleşmeye aykırılık taleplerinde özel bir süre yoksa Türk Borçlar Kanunu’ndaki genel on yıllık zamanaşımı gündeme gelebilir; ancak ilişkinin eser, kira, vekâlet veya başka bir tipe yaklaşan edimleri için özel süreler bulunabilir. Dönemsel nitelikteki SaaS abonelik ve ücret alacaklarında beş yıllık özel sürenin uygulanması da somut borcun yapısına göre tartışılabilir; bedelin taksitlere ayrılması tek başına her zaman dönemsel edim oluşturmaz. Bu yüzden yalnız “SaaS sözleşmesidir” denilerek tek süre kabul edilmemelidir. Fesih ve ihbar süreleri ise ayrıca sözleşmeden doğar.

Tarafların ticari işletmesiyle ilgili para alacağı ve tazminat taleplerinde dava açmadan önce arabulucuya başvuru kural olarak dava şartıdır. Veri iadesi, erişim veya tespit gibi para dışı taleplerin yapısı ayrı değerlendirilir. Ticari arabuluculuğun işleyişine ilişkin ayrıntılar için ticari alacak ve zorunlu arabuluculuk rehberi incelenebilir.

Görevli ve yetkili mahkeme nasıl belirlenir?

İki ticari işletme arasındaki SaaS uyuşmazlığı çoğunlukla ticari dava niteliğindedir ve asliye ticaret mahkemesinde görülür. Taraf sıfatı, sözleşmenin amacı ve talebin niteliği görev belirlemesinde birlikte ele alınır. Geçerli tahkim şartı varsa devlet mahkemesi yerine hakem yargılaması gündeme gelebilir.

Yetkide genel kural davalının yerleşim yeridir; sözleşmenin ifa yeri ve geçerli yetki şartı da sonuç doğurabilir. Bulut hizmetinde sunucunun fiziksel konumu tek başına her zaman ifa yeri sayılmaz. Yetki ve uygulanacak hukuk maddesi, özellikle taraflardan biri yurt dışındaysa, kararın icrası ve ihtiyati tedbir ihtiyacı düşünülerek yazılmalıdır.

İspat yükü ve delil dosyası

Talepte bulunan taraf sözleşme ihlalini ve zararını; karşı taraf ise ödeme, ifa, izin verilen kesinti veya sorumsuzluk savunmasının dayanağını ispatlamalıdır. Elektronik kayıtların üretildiği sistem, saat senkronizasyonu ve değişmezliği önemlidir. Tek bir ekran görüntüsü yerine kaynak kayıt, dış izleme, destek yazışması ve finansal etki birlikte sunulmalıdır.

İhtiyati tedbir ve delil tespiti ne zaman gerekir?

Sağlayıcının hesabı kapatacağı, veriyi sileceği veya kısa saklama süresi nedeniyle logların kaybolacağı somut biçimde gösterilebiliyorsa ihtiyati tedbir ya da delil tespiti değerlendirilebilir. Talep; korunacak veri kümesini, hesabı ve süreyi ölçülü biçimde tanımlamalıdır. Bütün altyapının süresiz çalıştırılmasını isteyen belirsiz bir talep yerine, dışa aktarımın korunması veya belirli kayıtların silinmemesi gibi uygulanabilir bir önlem kurulmalıdır.

Mahkeme yaklaşık ispat ve teminat koşullarını dosyaya göre değerlendirir. Tedbir kararı esas davada başarı garantisi değildir. Acil durumda dahi sözleşmedeki yedek alma imkânı kullanılmalı; zarar azaltma yükümlülüğü ihmal edilmemelidir.

Üç uygulama senaryosu

Senaryo 1: Ay sonu üç saatlik ödeme sistemi kesintisi

Perakende şirketinin SaaS ödeme modülü ay sonu üç saat çalışmaz. Sağlayıcı kesintiyi “üçüncü taraf altyapı sorunu” sayarken müşteri yüzlerce başarısız sipariş bildirir. İncelemede SLA’nın üçüncü tarafları bütünüyle hariç tutup tutmadığı, sağlayıcının alternatif yönlendirme yükümlülüğü, dış izleme kayıtları ve gerçekten iptal edilen siparişler karşılaştırılır. Hizmet kredisi hızlıca hesaplanabilir; daha yüksek tazminat için gerçek zarar ve kesinti arasındaki bağ ayrıca kanıtlanır.

Senaryo 2: Fesih sonrası yalnız PDF veri verilmesi

Müşteri yeni sisteme geçmek ister; eski sağlayıcı sözleşmedeki “veri iade edilir” hükmüne dayanarak binlerce kaydı tek PDF olarak gönderir. Oysa ekler, müşteri kimlikleri ve işlem bağlantıları taşınamaz durumdadır. Veri formatı ve şema baştan kararlaştırılmışsa aynen ifa ve geçiş desteği daha açık talep edilebilir. Hüküm belirsizse kullanım amacı, önceki dışa aktarımlar ve teknik olarak makul format değerlendirilir; silinme riski varsa hızla koruma talep edilir.

Senaryo 3: Tekrarlayan kesinti nedeniyle erken fesih

Üç ay içinde dört kritik kesinti yaşayan müşteri taahhüt süresi dolmadan çıkar. Sağlayıcı kalan tüm dönem ücretini ister. Dosyada kritik olay tanımı, tekrar eşiği, verilen düzeltme süresi, müşterinin ihtarları ve sağlayıcının kök neden raporları incelenir. Müşterinin sözleşmeye uygun fesih yapması ile hizmeti yalnız kullanmayı bırakması aynı değildir. Karşılıklı alacaklar, kullanılmamış peşin ücret ve geçiş giderleri ayrı kalemler halinde hesaplanır.

SaaS sözleşmelerinde sık yapılan on hata

1. Yalnız uptime yüzdesi yazmak: Ölçüm kaynağı ve hariç süreler tanımlanmadığında oran denetlenemez.
2. Bütün üçüncü taraf sorunlarını hariç tutmak: Sağlayıcının seçtiği altyapı ve alt yüklenici riski sınırsız biçimde müşteriye aktarılır.
3. Hizmet kredisini otomatik sanmak: Kısa talep süresi veya belirli bildirim kanalı kaçırılabilir.
4. Krediyi her zarar için tek çözüm kabul etmek: Veri kaybı ve ağır kusur gibi yüksek etkili olaylar ayrıca düzenlenmelidir.
5. “Veri müşterinindir” cümlesiyle yetinmek: Format, süre ve teknik destek yoksa veri fiilen taşınamayabilir.
6. Silme takvimini yazmamak: Aktif sistem ve yedeklerdeki kopyaların akıbeti belirsiz kalır.
7. Fesih ile hesabı anında kapatmak: Geçiş süresi olmaması iş sürekliliğini ve delilleri tehlikeye sokar.
8. Sorumluluk tavanını tek cümle kurmak: Tavanın dönemsel mi toplam mı olduğu ve istisnaları açıklanmaz.
9. Alt işleyen listesini güncellememek: Yeni veri merkezi veya sağlayıcı, KVKK ve güvenlik riskini değiştirebilir.
10. Kesinti delilini sonradan toplamaya çalışmak: Kısa süre saklanan loglar ve destek kayıtları kaybolabilir.

Karar, istinaf ve sözleşme yönetişimi

İlk derece kararına karşı istinaf ve sonrasında temyiz imkânı, kararın niteliği ile karar tarihindeki güncel parasal sınırlara bağlıdır. Bu sınırlar değiştiği için sabit bir tutar üzerinden yönlendirme yapılmamalı; kararın kanun yolu bildirimi ve güncel resmî düzenleme kontrol edilmelidir. Tahkim kararı varsa iptal davası ve icra rejimi, mahkeme kararından farklıdır.

Uyuşmazlık çıkmadan önce yapılacak en etkili çalışma, sözleşme yönetişimidir. Aylık SLA raporlarının iki tarafça gözden geçirilmesi, kritik istisnaların kapatılması, alt işleyen değişikliklerinin kaydı ve yılda en az bir veri çıkarma testi, metnin kâğıt üzerinde kalmasını önler.

SaaS dosyası için inceleme paketi

Türkiye’nin her yerinden çevrim içi ön inceleme için ana sözleşme ve bütün ekler, son üç aylık SLA raporları, kesinti zaman çizelgesi, destek kayıtları, olay raporu, faturalar, zarar belgeleri ve örnek veri dışa aktarımı birlikte hazırlanmalıdır. Amaç sonuç vaat etmek değil; uygulanacak hükmü, acil veri koruma ihtiyacını ve talep kalemlerini somut kayıtlardan ayırmaktır. Cari hesap ve fatura tartışması bulunan dosyalarda fatura ve cari hesap alacağı rehberi de delil düzeni bakımından yardımcı olabilir.

SaaS sözleşmesi hakkında sık sorulan sorular

1. Yüzde 99,9 uptime yılda ne kadar kesintiye izin verir?

Hesap dönemi ve istisnalar sözleşmeye bağlıdır. Aylık ölçüm ile yıllık ölçüm farklı sonuç verir; bu nedenle tek başına yüzde üzerinden karar verilmemelidir.

2. Planlı bakım her zaman SLA dışında mıdır?

Hayır. Hariç tutulması için tanım, ön bildirim ve süre sınırına uygun olması aranabilir. Usulsüz veya aşırı bakım kesinti hesabına girebilir.

3. Hizmet kredisi için ayrıca talep gerekir mi?

Sözleşme belirler. Bazı metinler otomatik, bazıları kısa süreli başvuru öngörür. Destek kaydı ile kredi talebinin aynı işlem olduğu varsayılmamalıdır.

4. Hizmet kredisi bütün tazminat haklarını kaldırır mı?

Kendiliğinden kaldırmaz. Münhasır çözüm hükmü, ihlalin türü, kusur derecesi ve emredici sınırlamalar birlikte incelenir.

5. Sağlayıcı ödenmeyen fatura nedeniyle veriyi tutabilir mi?

Askıya alma ve veri iadesi hükümleri incelenir. Tartışmalı borç nedeniyle bütün verinin süresiz alıkonulması her dosyada geçerli kabul edilemez.

6. Sözleşme bitince yedekler hemen silinmeli mi?

Aktif kopya ile yedek farklı takvimlere bağlanabilir. Yasal saklama, felaket kurtarma döngüsü ve silme teyidi açıkça düzenlenmelidir.

7. SaaS verisi için hangi dışa aktarım formatı seçilmelidir?

Kullanım amacına göre CSV, JSON, XML veya veritabanı dökümü düşünülebilir. Asıl ölçüt verinin ilişkileri ve ekleriyle yeniden kullanılabilir olmasıdır.

8. Yurt dışındaki SaaS sağlayıcısına karşı Türkiye’de dava açılır mı?

Yetki, hukuk seçimi, tahkim şartı ve ifa yeri birlikte incelenir. Türkiye’de dava imkânı her sözleşmede aynı değildir.

9. Kesinti ekran görüntüsü tek başına yeterli midir?

Genellikle zayıf kalır. Zaman damgalı izleme, destek kaydı, log, olay raporu ve zarar belgeleriyle birlikte sunulması daha güvenlidir.

10. Ticari SaaS alacağında arabuluculuk zorunlu mudur?

Tarafların ticari işletmesiyle ilgili para alacağı ve tazminat talebinde kural olarak dava şartı arabuluculuk uygulanır. Para dışı talepler ayrıca sınıflandırılır.

11. Kaynak kod emanetine her SaaS sözleşmesinde ihtiyaç var mı?

Hayır. Kritik ve özelleştirilmiş hizmetlerde sağlayıcının iflası veya kalıcı hizmet kesintisi için düşünülebilir; standart çok kiracılı üründe uygun çözüm olmayabilir.

Resmî kaynaklar

• 6098 sayılı Türk Borçlar Kanunu
• 6102 sayılı Türk Ticaret Kanunu
• 6698 sayılı Kişisel Verilerin Korunması Kanunu
• 6100 sayılı Hukuk Muhakemeleri Kanunu
• Kişisel Verileri Koruma Kurumu: Veri güvenliğine ilişkin yükümlülükler

Son kontrol tarihi: 19 Eylül 2026

Yazar: Av. Emirhan Keskin

Bu içerik genel bilgilendirme amacı taşır. SaaS sözleşmesinin metni, taraf sıfatları, veri akışı ve zarar kayıtları her dosyada farklıdır. Somut dosya incelenmeden hukuki sonuç veya başarı garantisi verilemez.